From 3b77fb74cf249011213816403980f3bb909c6f78 Mon Sep 17 00:00:00 2001
From: EntranceJew
Date: Fri, 31 Jul 2015 15:37:25 -0400
Subject: [PATCH] Added libtheora.
---
CMakeLists.txt | 10 +
libs/libtheora-1.1/AUTHORS | 49 +
libs/libtheora-1.1/CHANGES | 243 +
libs/libtheora-1.1/CMakeLists.txt | 48 +
libs/libtheora-1.1/COPYING | 28 +
libs/libtheora-1.1/LICENSE | 18 +
libs/libtheora-1.1/Makefile.am | 35 +
libs/libtheora-1.1/README | 152 +
libs/libtheora-1.1/SConstruct | 225 +
libs/libtheora-1.1/autogen.sh | 130 +
libs/libtheora-1.1/configure.ac | 531 ++
libs/libtheora-1.1/debian/changelog | 15 +
libs/libtheora-1.1/debian/control | 24 +
libs/libtheora-1.1/debian/copyright | 38 +
.../debian/libtheora-dev.install | 5 +
libs/libtheora-1.1/debian/libtheora0.install | 2 +
libs/libtheora-1.1/debian/rules | 3 +
libs/libtheora-1.1/debian/watch | 3 +
libs/libtheora-1.1/doc/Doxyfile.in | 1142 +++
libs/libtheora-1.1/doc/Makefile.am | 72 +
libs/libtheora-1.1/doc/color.html | 602 ++
.../doc/draft-ietf-avt-rtp-theora-00.txt | 1400 +++
.../doc/draft-ietf-avt-rtp-theora-00.xml | 1146 +++
.../doc/draft-kerr-avt-theora-rtp-00.txt | 1512 +++
.../doc/draft-kerr-avt-theora-rtp-00.xml | 1277 +++
libs/libtheora-1.1/doc/spec/Makefile.am | 81 +
libs/libtheora-1.1/doc/spec/fdct.fig | 371 +
libs/libtheora-1.1/doc/spec/hilbert-block.fig | 104 +
libs/libtheora-1.1/doc/spec/hilbert-mb.fig | 32 +
libs/libtheora-1.1/doc/spec/idct.fig | 369 +
libs/libtheora-1.1/doc/spec/lflim.fig | 23 +
libs/libtheora-1.1/doc/spec/ltablex.sty | 237 +
libs/libtheora-1.1/doc/spec/macroblock.fig | 37 +
libs/libtheora-1.1/doc/spec/pic-frame.fig | 75 +
libs/libtheora-1.1/doc/spec/pic_even.fig | 102 +
libs/libtheora-1.1/doc/spec/pic_even_odd.fig | 88 +
libs/libtheora-1.1/doc/spec/pic_odd.fig | 90 +
libs/libtheora-1.1/doc/spec/pic_odd_even.fig | 84 +
libs/libtheora-1.1/doc/spec/pixel420.fig | 56 +
libs/libtheora-1.1/doc/spec/pixel422.fig | 70 +
libs/libtheora-1.1/doc/spec/pixel444.fig | 44 +
libs/libtheora-1.1/doc/spec/raster-block.fig | 91 +
.../doc/spec/reference-frames.fig | 46 +
libs/libtheora-1.1/doc/spec/spec.bib | 120 +
libs/libtheora-1.1/doc/spec/spec.tex | 8194 +++++++++++++++++
libs/libtheora-1.1/doc/spec/superblock.fig | 72 +
libs/libtheora-1.1/doc/spec/vp3huff.c | 918 ++
libs/libtheora-1.1/doc/spec/xifish.fig | 85 +
libs/libtheora-1.1/doc/vp3-format.txt | 1305 +++
libs/libtheora-1.1/examples/Makefile.am | 41 +
libs/libtheora-1.1/examples/README_SPLAYER | 21 +
libs/libtheora-1.1/examples/dump_psnr.c | 1210 +++
libs/libtheora-1.1/examples/dump_video.c | 496 +
libs/libtheora-1.1/examples/encoder_example.c | 1830 ++++
libs/libtheora-1.1/examples/getopt.c | 1055 +++
libs/libtheora-1.1/examples/getopt.h | 180 +
libs/libtheora-1.1/examples/getopt1.c | 188 +
libs/libtheora-1.1/examples/player_example.c | 887 ++
libs/libtheora-1.1/examples/png2theora.c | 942 ++
libs/libtheora-1.1/examples/splayer.c | 1107 +++
libs/libtheora-1.1/include/Makefile.am | 3 +
libs/libtheora-1.1/include/theora/Makefile.am | 7 +
libs/libtheora-1.1/include/theora/codec.h | 591 ++
libs/libtheora-1.1/include/theora/theora.h | 784 ++
libs/libtheora-1.1/include/theora/theoradec.h | 325 +
libs/libtheora-1.1/include/theora/theoraenc.h | 500 +
libs/libtheora-1.1/lib/Makefile.am | 177 +
libs/libtheora-1.1/lib/Version_script | 53 +
libs/libtheora-1.1/lib/Version_script-dec | 82 +
libs/libtheora-1.1/lib/Version_script-enc | 43 +
libs/libtheora-1.1/lib/analyze.c | 2701 ++++++
libs/libtheora-1.1/lib/apiwrapper.c | 166 +
libs/libtheora-1.1/lib/apiwrapper.h | 54 +
libs/libtheora-1.1/lib/bitpack.c | 111 +
libs/libtheora-1.1/lib/bitpack.h | 60 +
libs/libtheora-1.1/lib/cpu.c | 226 +
libs/libtheora-1.1/lib/cpu.h | 34 +
libs/libtheora-1.1/lib/dct.h | 31 +
libs/libtheora-1.1/lib/decapiwrapper.c | 193 +
libs/libtheora-1.1/lib/decinfo.c | 246 +
libs/libtheora-1.1/lib/decint.h | 107 +
libs/libtheora-1.1/lib/decode.c | 2943 ++++++
libs/libtheora-1.1/lib/defexp.awk | 27 +
libs/libtheora-1.1/lib/dequant.c | 182 +
libs/libtheora-1.1/lib/dequant.h | 27 +
libs/libtheora-1.1/lib/encapiwrapper.c | 168 +
libs/libtheora-1.1/lib/encfrag.c | 388 +
libs/libtheora-1.1/lib/encinfo.c | 121 +
libs/libtheora-1.1/lib/encint.h | 490 +
libs/libtheora-1.1/lib/encode.c | 1627 ++++
libs/libtheora-1.1/lib/encoder_disabled.c | 67 +
libs/libtheora-1.1/lib/enquant.c | 274 +
libs/libtheora-1.1/lib/enquant.h | 27 +
libs/libtheora-1.1/lib/fdct.c | 422 +
libs/libtheora-1.1/lib/fragment.c | 87 +
libs/libtheora-1.1/lib/huffdec.c | 489 +
libs/libtheora-1.1/lib/huffdec.h | 92 +
libs/libtheora-1.1/lib/huffenc.c | 910 ++
libs/libtheora-1.1/lib/huffenc.h | 19 +
libs/libtheora-1.1/lib/huffman.h | 70 +
libs/libtheora-1.1/lib/idct.c | 335 +
libs/libtheora-1.1/lib/info.c | 131 +
libs/libtheora-1.1/lib/internal.c | 262 +
libs/libtheora-1.1/lib/internal.h | 509 +
libs/libtheora-1.1/lib/mathops.c | 296 +
libs/libtheora-1.1/lib/mathops.h | 141 +
libs/libtheora-1.1/lib/mcenc.c | 767 ++
libs/libtheora-1.1/lib/modedec.h | 4027 ++++++++
libs/libtheora-1.1/lib/ocintrin.h | 128 +
libs/libtheora-1.1/lib/quant.c | 119 +
libs/libtheora-1.1/lib/quant.h | 33 +
libs/libtheora-1.1/lib/rate.c | 1137 +++
libs/libtheora-1.1/lib/state.c | 1227 +++
libs/libtheora-1.1/lib/theora.def | 56 +
libs/libtheora-1.1/lib/theora.exp | 55 +
libs/libtheora-1.1/lib/theoradec.exp | 43 +
libs/libtheora-1.1/lib/theoraenc.exp | 15 +
libs/libtheora-1.1/lib/tokenize.c | 1072 +++
libs/libtheora-1.1/lib/x86/mmxencfrag.c | 900 ++
libs/libtheora-1.1/lib/x86/mmxfdct.c | 665 ++
libs/libtheora-1.1/lib/x86/mmxfrag.c | 293 +
libs/libtheora-1.1/lib/x86/mmxfrag.h | 64 +
libs/libtheora-1.1/lib/x86/mmxidct.c | 564 ++
libs/libtheora-1.1/lib/x86/mmxloop.h | 215 +
libs/libtheora-1.1/lib/x86/mmxstate.c | 188 +
libs/libtheora-1.1/lib/x86/sse2fdct.c | 523 ++
libs/libtheora-1.1/lib/x86/x86enc.c | 49 +
libs/libtheora-1.1/lib/x86/x86enc.h | 47 +
libs/libtheora-1.1/lib/x86/x86int.h | 42 +
libs/libtheora-1.1/lib/x86/x86state.c | 62 +
libs/libtheora-1.1/lib/x86_vc/mmxencfrag.c | 969 ++
libs/libtheora-1.1/lib/x86_vc/mmxfdct.c | 670 ++
libs/libtheora-1.1/lib/x86_vc/mmxfrag.c | 337 +
libs/libtheora-1.1/lib/x86_vc/mmxfrag.h | 61 +
libs/libtheora-1.1/lib/x86_vc/mmxidct.c | 562 ++
libs/libtheora-1.1/lib/x86_vc/mmxloop.h | 219 +
libs/libtheora-1.1/lib/x86_vc/mmxstate.c | 211 +
libs/libtheora-1.1/lib/x86_vc/x86enc.c | 49 +
libs/libtheora-1.1/lib/x86_vc/x86enc.h | 47 +
libs/libtheora-1.1/lib/x86_vc/x86int.h | 42 +
libs/libtheora-1.1/lib/x86_vc/x86state.c | 62 +
libs/libtheora-1.1/libtheora.spec.in | 82 +
libs/libtheora-1.1/m4/Makefile.am | 6 +
libs/libtheora-1.1/m4/as-ac-expand.m4 | 43 +
libs/libtheora-1.1/m4/ogg.m4 | 116 +
libs/libtheora-1.1/m4/pkg.m4 | 157 +
libs/libtheora-1.1/m4/sdl.m4 | 180 +
libs/libtheora-1.1/m4/vorbis.m4 | 122 +
.../macosx/English.lproj/InfoPlist.strings | Bin 0 -> 142 bytes
libs/libtheora-1.1/macosx/Info.plist | 30 +
.../macosx/Theora.xcodeproj/project.pbxproj | 864 ++
libs/libtheora-1.1/macosx/Theora_Prefix.pch | 5 +
libs/libtheora-1.1/symbian/bld.inf | 35 +
libs/libtheora-1.1/symbian/config.h | 57 +
libs/libtheora-1.1/symbian/theora.mmp | 41 +
libs/libtheora-1.1/tests/Makefile.am | 69 +
libs/libtheora-1.1/tests/comment.c | 91 +
libs/libtheora-1.1/tests/comment_theora.c | 91 +
libs/libtheora-1.1/tests/granulepos.c | 149 +
libs/libtheora-1.1/tests/granulepos_theora.c | 154 +
libs/libtheora-1.1/tests/noop.c | 119 +
libs/libtheora-1.1/tests/noop_theora.c | 88 +
libs/libtheora-1.1/tests/tests.h | 33 +
libs/libtheora-1.1/theora-uninstalled.pc.in | 14 +
libs/libtheora-1.1/theora.pc.in | 14 +
.../libtheora-1.1/theoradec-uninstalled.pc.in | 14 +
libs/libtheora-1.1/theoradec.pc.in | 14 +
.../libtheora-1.1/theoraenc-uninstalled.pc.in | 14 +
libs/libtheora-1.1/theoraenc.pc.in | 14 +
libs/libtheora-1.1/win32/VS2005/README | 22 +
.../dump_video/dump_video_dynamic.vcproj | 108 +
.../dump_video/dump_video_static.vcproj | 108 +
.../encoder_example_dynamic.vcproj | 104 +
.../encoder_example_static.vcproj | 104 +
.../libtheora-1.1/win32/VS2005/libogg.vsprops | 19 +
.../VS2005/libtheora/libtheora_dynamic.vcproj | 688 ++
.../VS2005/libtheora/libtheora_static.vcproj | 690 ++
.../win32/VS2005/libtheora_dynamic.sln | 82 +
.../win32/VS2005/libtheora_static.sln | 82 +
.../win32/VS2005/libvorbis.vsprops | 19 +
libs/libtheora-1.1/win32/VS2008/README | 22 +
.../dump_video/dump_video_dynamic.vcproj | 104 +
.../dump_video/dump_video_static.vcproj | 104 +
.../encoder_example_dynamic.vcproj | 100 +
.../encoder_example_static.vcproj | 100 +
.../libtheora-1.1/win32/VS2008/libogg.vsprops | 19 +
.../VS2008/libtheora/libtheora_dynamic.vcproj | 576 ++
.../VS2008/libtheora/libtheora_static.vcproj | 566 ++
.../win32/VS2008/libtheora_dynamic.sln | 146 +
.../win32/VS2008/libtheora_static.sln | 146 +
.../win32/VS2008/libvorbis.vsprops | 19 +
libs/libtheora-1.1/win32/VS2010/README | 22 +
.../dump_video/dump_video_dynamic.vcxproj | 198 +
.../dump_video/dump_video_static.vcxproj | 198 +
.../encoder_example_dynamic.vcxproj | 204 +
.../encoder_example_static.vcxproj | 204 +
libs/libtheora-1.1/win32/VS2010/libogg.props | 22 +
.../libtheora/libtheora_dynamic.vcxproj | 285 +
.../VS2010/libtheora/libtheora_static.vcxproj | 251 +
.../win32/VS2010/libtheora_dynamic.sln | 46 +
.../win32/VS2010/libtheora_static.sln | 46 +
.../win32/VS2010/libvorbis.props | 22 +
.../win32/build_theora_static.bat | 18 +
.../win32/build_theora_static_debug.bat | 18 +
.../win32/experimental/dumpvid/dumpvid.dsp | 121 +
.../win32/experimental/encoderwin/ReadMe.txt | 13 +
.../experimental/encoderwin/encoderwin.dsp | 121 +
.../experimental/transcoder/avi2vp3/avi2vp3.c | 82 +
.../experimental/transcoder/avi2vp3/avilib.c | 1839 ++++
.../experimental/transcoder/avi2vp3/avilib.h | 309 +
.../transcoder/avi2vp3/outfile.vp3 | Bin 0 -> 233132 bytes
.../experimental/transcoder/avi2vp3/vp31.avi | Bin 0 -> 299724 bytes
.../win32/experimental/transcoder/readme.txt | 17 +
.../experimental/transcoder/transcoder.dsp | 121 +
.../transcoder/transcoder_example.c | 926 ++
.../win32/experimental/wincompat/README.txt | 1 +
.../win32/experimental/wincompat/getopt.c | 122 +
.../win32/experimental/wincompat/getopt.h | 110 +
.../experimental/wincompat/getopt_long.c | 547 ++
.../win32/experimental/wincompat/unistd.h | 0
libs/libtheora-1.1/win32/getopt.c | 1047 +++
libs/libtheora-1.1/win32/getopt1.c | 188 +
libs/libtheora-1.1/win32/getopt_win.h | 169 +
libs/libtheora-1.1/win32/theora_static.dsp | 336 +
libs/libtheora-1.1/win32/xmingw32/Makefile | 393 +
.../win32/xmingw32/libtheoradec-all.def | 58 +
.../win32/xmingw32/libtheoradec-all.rc | 39 +
.../win32/xmingw32/libtheoradec.rc | 3 +
.../win32/xmingw32/libtheoradec70.rc | 3 +
.../win32/xmingw32/libtheoradec70d.rc | 3 +
.../win32/xmingw32/libtheoradec71.rc | 3 +
.../win32/xmingw32/libtheoradec71d.rc | 3 +
.../win32/xmingw32/libtheoradec80.rc | 3 +
.../win32/xmingw32/libtheoradec80d.rc | 3 +
.../win32/xmingw32/libtheoradecd.rc | 3 +
.../win32/xmingw32/libtheoraenc-all.def | 17 +
.../win32/xmingw32/libtheoraenc-all.rc | 39 +
.../win32/xmingw32/libtheoraenc.rc | 3 +
.../win32/xmingw32/libtheoraenc70.rc | 3 +
.../win32/xmingw32/libtheoraenc70d.rc | 3 +
.../win32/xmingw32/libtheoraenc71.rc | 3 +
.../win32/xmingw32/libtheoraenc71d.rc | 3 +
.../win32/xmingw32/libtheoraenc80.rc | 3 +
.../win32/xmingw32/libtheoraenc80d.rc | 3 +
.../win32/xmingw32/libtheoraencd.rc | 3 +
245 files changed, 76220 insertions(+)
create mode 100644 libs/libtheora-1.1/AUTHORS
create mode 100644 libs/libtheora-1.1/CHANGES
create mode 100644 libs/libtheora-1.1/CMakeLists.txt
create mode 100644 libs/libtheora-1.1/COPYING
create mode 100644 libs/libtheora-1.1/LICENSE
create mode 100644 libs/libtheora-1.1/Makefile.am
create mode 100644 libs/libtheora-1.1/README
create mode 100644 libs/libtheora-1.1/SConstruct
create mode 100644 libs/libtheora-1.1/autogen.sh
create mode 100644 libs/libtheora-1.1/configure.ac
create mode 100644 libs/libtheora-1.1/debian/changelog
create mode 100644 libs/libtheora-1.1/debian/control
create mode 100644 libs/libtheora-1.1/debian/copyright
create mode 100644 libs/libtheora-1.1/debian/libtheora-dev.install
create mode 100644 libs/libtheora-1.1/debian/libtheora0.install
create mode 100644 libs/libtheora-1.1/debian/rules
create mode 100644 libs/libtheora-1.1/debian/watch
create mode 100644 libs/libtheora-1.1/doc/Doxyfile.in
create mode 100644 libs/libtheora-1.1/doc/Makefile.am
create mode 100644 libs/libtheora-1.1/doc/color.html
create mode 100644 libs/libtheora-1.1/doc/draft-ietf-avt-rtp-theora-00.txt
create mode 100644 libs/libtheora-1.1/doc/draft-ietf-avt-rtp-theora-00.xml
create mode 100644 libs/libtheora-1.1/doc/draft-kerr-avt-theora-rtp-00.txt
create mode 100644 libs/libtheora-1.1/doc/draft-kerr-avt-theora-rtp-00.xml
create mode 100644 libs/libtheora-1.1/doc/spec/Makefile.am
create mode 100644 libs/libtheora-1.1/doc/spec/fdct.fig
create mode 100644 libs/libtheora-1.1/doc/spec/hilbert-block.fig
create mode 100644 libs/libtheora-1.1/doc/spec/hilbert-mb.fig
create mode 100644 libs/libtheora-1.1/doc/spec/idct.fig
create mode 100644 libs/libtheora-1.1/doc/spec/lflim.fig
create mode 100644 libs/libtheora-1.1/doc/spec/ltablex.sty
create mode 100644 libs/libtheora-1.1/doc/spec/macroblock.fig
create mode 100644 libs/libtheora-1.1/doc/spec/pic-frame.fig
create mode 100644 libs/libtheora-1.1/doc/spec/pic_even.fig
create mode 100644 libs/libtheora-1.1/doc/spec/pic_even_odd.fig
create mode 100644 libs/libtheora-1.1/doc/spec/pic_odd.fig
create mode 100644 libs/libtheora-1.1/doc/spec/pic_odd_even.fig
create mode 100644 libs/libtheora-1.1/doc/spec/pixel420.fig
create mode 100644 libs/libtheora-1.1/doc/spec/pixel422.fig
create mode 100644 libs/libtheora-1.1/doc/spec/pixel444.fig
create mode 100644 libs/libtheora-1.1/doc/spec/raster-block.fig
create mode 100644 libs/libtheora-1.1/doc/spec/reference-frames.fig
create mode 100644 libs/libtheora-1.1/doc/spec/spec.bib
create mode 100644 libs/libtheora-1.1/doc/spec/spec.tex
create mode 100644 libs/libtheora-1.1/doc/spec/superblock.fig
create mode 100644 libs/libtheora-1.1/doc/spec/vp3huff.c
create mode 100644 libs/libtheora-1.1/doc/spec/xifish.fig
create mode 100644 libs/libtheora-1.1/doc/vp3-format.txt
create mode 100644 libs/libtheora-1.1/examples/Makefile.am
create mode 100644 libs/libtheora-1.1/examples/README_SPLAYER
create mode 100644 libs/libtheora-1.1/examples/dump_psnr.c
create mode 100644 libs/libtheora-1.1/examples/dump_video.c
create mode 100644 libs/libtheora-1.1/examples/encoder_example.c
create mode 100644 libs/libtheora-1.1/examples/getopt.c
create mode 100644 libs/libtheora-1.1/examples/getopt.h
create mode 100644 libs/libtheora-1.1/examples/getopt1.c
create mode 100644 libs/libtheora-1.1/examples/player_example.c
create mode 100644 libs/libtheora-1.1/examples/png2theora.c
create mode 100644 libs/libtheora-1.1/examples/splayer.c
create mode 100644 libs/libtheora-1.1/include/Makefile.am
create mode 100644 libs/libtheora-1.1/include/theora/Makefile.am
create mode 100644 libs/libtheora-1.1/include/theora/codec.h
create mode 100644 libs/libtheora-1.1/include/theora/theora.h
create mode 100644 libs/libtheora-1.1/include/theora/theoradec.h
create mode 100644 libs/libtheora-1.1/include/theora/theoraenc.h
create mode 100644 libs/libtheora-1.1/lib/Makefile.am
create mode 100644 libs/libtheora-1.1/lib/Version_script
create mode 100644 libs/libtheora-1.1/lib/Version_script-dec
create mode 100644 libs/libtheora-1.1/lib/Version_script-enc
create mode 100644 libs/libtheora-1.1/lib/analyze.c
create mode 100644 libs/libtheora-1.1/lib/apiwrapper.c
create mode 100644 libs/libtheora-1.1/lib/apiwrapper.h
create mode 100644 libs/libtheora-1.1/lib/bitpack.c
create mode 100644 libs/libtheora-1.1/lib/bitpack.h
create mode 100644 libs/libtheora-1.1/lib/cpu.c
create mode 100644 libs/libtheora-1.1/lib/cpu.h
create mode 100644 libs/libtheora-1.1/lib/dct.h
create mode 100644 libs/libtheora-1.1/lib/decapiwrapper.c
create mode 100644 libs/libtheora-1.1/lib/decinfo.c
create mode 100644 libs/libtheora-1.1/lib/decint.h
create mode 100644 libs/libtheora-1.1/lib/decode.c
create mode 100644 libs/libtheora-1.1/lib/defexp.awk
create mode 100644 libs/libtheora-1.1/lib/dequant.c
create mode 100644 libs/libtheora-1.1/lib/dequant.h
create mode 100644 libs/libtheora-1.1/lib/encapiwrapper.c
create mode 100644 libs/libtheora-1.1/lib/encfrag.c
create mode 100644 libs/libtheora-1.1/lib/encinfo.c
create mode 100644 libs/libtheora-1.1/lib/encint.h
create mode 100644 libs/libtheora-1.1/lib/encode.c
create mode 100644 libs/libtheora-1.1/lib/encoder_disabled.c
create mode 100644 libs/libtheora-1.1/lib/enquant.c
create mode 100644 libs/libtheora-1.1/lib/enquant.h
create mode 100644 libs/libtheora-1.1/lib/fdct.c
create mode 100644 libs/libtheora-1.1/lib/fragment.c
create mode 100644 libs/libtheora-1.1/lib/huffdec.c
create mode 100644 libs/libtheora-1.1/lib/huffdec.h
create mode 100644 libs/libtheora-1.1/lib/huffenc.c
create mode 100644 libs/libtheora-1.1/lib/huffenc.h
create mode 100644 libs/libtheora-1.1/lib/huffman.h
create mode 100644 libs/libtheora-1.1/lib/idct.c
create mode 100644 libs/libtheora-1.1/lib/info.c
create mode 100644 libs/libtheora-1.1/lib/internal.c
create mode 100644 libs/libtheora-1.1/lib/internal.h
create mode 100644 libs/libtheora-1.1/lib/mathops.c
create mode 100644 libs/libtheora-1.1/lib/mathops.h
create mode 100644 libs/libtheora-1.1/lib/mcenc.c
create mode 100644 libs/libtheora-1.1/lib/modedec.h
create mode 100644 libs/libtheora-1.1/lib/ocintrin.h
create mode 100644 libs/libtheora-1.1/lib/quant.c
create mode 100644 libs/libtheora-1.1/lib/quant.h
create mode 100644 libs/libtheora-1.1/lib/rate.c
create mode 100644 libs/libtheora-1.1/lib/state.c
create mode 100644 libs/libtheora-1.1/lib/theora.def
create mode 100644 libs/libtheora-1.1/lib/theora.exp
create mode 100644 libs/libtheora-1.1/lib/theoradec.exp
create mode 100644 libs/libtheora-1.1/lib/theoraenc.exp
create mode 100644 libs/libtheora-1.1/lib/tokenize.c
create mode 100644 libs/libtheora-1.1/lib/x86/mmxencfrag.c
create mode 100644 libs/libtheora-1.1/lib/x86/mmxfdct.c
create mode 100644 libs/libtheora-1.1/lib/x86/mmxfrag.c
create mode 100644 libs/libtheora-1.1/lib/x86/mmxfrag.h
create mode 100644 libs/libtheora-1.1/lib/x86/mmxidct.c
create mode 100644 libs/libtheora-1.1/lib/x86/mmxloop.h
create mode 100644 libs/libtheora-1.1/lib/x86/mmxstate.c
create mode 100644 libs/libtheora-1.1/lib/x86/sse2fdct.c
create mode 100644 libs/libtheora-1.1/lib/x86/x86enc.c
create mode 100644 libs/libtheora-1.1/lib/x86/x86enc.h
create mode 100644 libs/libtheora-1.1/lib/x86/x86int.h
create mode 100644 libs/libtheora-1.1/lib/x86/x86state.c
create mode 100644 libs/libtheora-1.1/lib/x86_vc/mmxencfrag.c
create mode 100644 libs/libtheora-1.1/lib/x86_vc/mmxfdct.c
create mode 100644 libs/libtheora-1.1/lib/x86_vc/mmxfrag.c
create mode 100644 libs/libtheora-1.1/lib/x86_vc/mmxfrag.h
create mode 100644 libs/libtheora-1.1/lib/x86_vc/mmxidct.c
create mode 100644 libs/libtheora-1.1/lib/x86_vc/mmxloop.h
create mode 100644 libs/libtheora-1.1/lib/x86_vc/mmxstate.c
create mode 100644 libs/libtheora-1.1/lib/x86_vc/x86enc.c
create mode 100644 libs/libtheora-1.1/lib/x86_vc/x86enc.h
create mode 100644 libs/libtheora-1.1/lib/x86_vc/x86int.h
create mode 100644 libs/libtheora-1.1/lib/x86_vc/x86state.c
create mode 100644 libs/libtheora-1.1/libtheora.spec.in
create mode 100644 libs/libtheora-1.1/m4/Makefile.am
create mode 100644 libs/libtheora-1.1/m4/as-ac-expand.m4
create mode 100644 libs/libtheora-1.1/m4/ogg.m4
create mode 100644 libs/libtheora-1.1/m4/pkg.m4
create mode 100644 libs/libtheora-1.1/m4/sdl.m4
create mode 100644 libs/libtheora-1.1/m4/vorbis.m4
create mode 100644 libs/libtheora-1.1/macosx/English.lproj/InfoPlist.strings
create mode 100644 libs/libtheora-1.1/macosx/Info.plist
create mode 100644 libs/libtheora-1.1/macosx/Theora.xcodeproj/project.pbxproj
create mode 100644 libs/libtheora-1.1/macosx/Theora_Prefix.pch
create mode 100644 libs/libtheora-1.1/symbian/bld.inf
create mode 100644 libs/libtheora-1.1/symbian/config.h
create mode 100644 libs/libtheora-1.1/symbian/theora.mmp
create mode 100644 libs/libtheora-1.1/tests/Makefile.am
create mode 100644 libs/libtheora-1.1/tests/comment.c
create mode 100644 libs/libtheora-1.1/tests/comment_theora.c
create mode 100644 libs/libtheora-1.1/tests/granulepos.c
create mode 100644 libs/libtheora-1.1/tests/granulepos_theora.c
create mode 100644 libs/libtheora-1.1/tests/noop.c
create mode 100644 libs/libtheora-1.1/tests/noop_theora.c
create mode 100644 libs/libtheora-1.1/tests/tests.h
create mode 100644 libs/libtheora-1.1/theora-uninstalled.pc.in
create mode 100644 libs/libtheora-1.1/theora.pc.in
create mode 100644 libs/libtheora-1.1/theoradec-uninstalled.pc.in
create mode 100644 libs/libtheora-1.1/theoradec.pc.in
create mode 100644 libs/libtheora-1.1/theoraenc-uninstalled.pc.in
create mode 100644 libs/libtheora-1.1/theoraenc.pc.in
create mode 100644 libs/libtheora-1.1/win32/VS2005/README
create mode 100644 libs/libtheora-1.1/win32/VS2005/dump_video/dump_video_dynamic.vcproj
create mode 100644 libs/libtheora-1.1/win32/VS2005/dump_video/dump_video_static.vcproj
create mode 100644 libs/libtheora-1.1/win32/VS2005/encoder_example/encoder_example_dynamic.vcproj
create mode 100644 libs/libtheora-1.1/win32/VS2005/encoder_example/encoder_example_static.vcproj
create mode 100644 libs/libtheora-1.1/win32/VS2005/libogg.vsprops
create mode 100644 libs/libtheora-1.1/win32/VS2005/libtheora/libtheora_dynamic.vcproj
create mode 100644 libs/libtheora-1.1/win32/VS2005/libtheora/libtheora_static.vcproj
create mode 100644 libs/libtheora-1.1/win32/VS2005/libtheora_dynamic.sln
create mode 100644 libs/libtheora-1.1/win32/VS2005/libtheora_static.sln
create mode 100644 libs/libtheora-1.1/win32/VS2005/libvorbis.vsprops
create mode 100644 libs/libtheora-1.1/win32/VS2008/README
create mode 100644 libs/libtheora-1.1/win32/VS2008/dump_video/dump_video_dynamic.vcproj
create mode 100644 libs/libtheora-1.1/win32/VS2008/dump_video/dump_video_static.vcproj
create mode 100644 libs/libtheora-1.1/win32/VS2008/encoder_example/encoder_example_dynamic.vcproj
create mode 100644 libs/libtheora-1.1/win32/VS2008/encoder_example/encoder_example_static.vcproj
create mode 100644 libs/libtheora-1.1/win32/VS2008/libogg.vsprops
create mode 100644 libs/libtheora-1.1/win32/VS2008/libtheora/libtheora_dynamic.vcproj
create mode 100644 libs/libtheora-1.1/win32/VS2008/libtheora/libtheora_static.vcproj
create mode 100644 libs/libtheora-1.1/win32/VS2008/libtheora_dynamic.sln
create mode 100644 libs/libtheora-1.1/win32/VS2008/libtheora_static.sln
create mode 100644 libs/libtheora-1.1/win32/VS2008/libvorbis.vsprops
create mode 100644 libs/libtheora-1.1/win32/VS2010/README
create mode 100644 libs/libtheora-1.1/win32/VS2010/dump_video/dump_video_dynamic.vcxproj
create mode 100644 libs/libtheora-1.1/win32/VS2010/dump_video/dump_video_static.vcxproj
create mode 100644 libs/libtheora-1.1/win32/VS2010/encoder_example/encoder_example_dynamic.vcxproj
create mode 100644 libs/libtheora-1.1/win32/VS2010/encoder_example/encoder_example_static.vcxproj
create mode 100644 libs/libtheora-1.1/win32/VS2010/libogg.props
create mode 100644 libs/libtheora-1.1/win32/VS2010/libtheora/libtheora_dynamic.vcxproj
create mode 100644 libs/libtheora-1.1/win32/VS2010/libtheora/libtheora_static.vcxproj
create mode 100644 libs/libtheora-1.1/win32/VS2010/libtheora_dynamic.sln
create mode 100644 libs/libtheora-1.1/win32/VS2010/libtheora_static.sln
create mode 100644 libs/libtheora-1.1/win32/VS2010/libvorbis.props
create mode 100644 libs/libtheora-1.1/win32/build_theora_static.bat
create mode 100644 libs/libtheora-1.1/win32/build_theora_static_debug.bat
create mode 100644 libs/libtheora-1.1/win32/experimental/dumpvid/dumpvid.dsp
create mode 100644 libs/libtheora-1.1/win32/experimental/encoderwin/ReadMe.txt
create mode 100644 libs/libtheora-1.1/win32/experimental/encoderwin/encoderwin.dsp
create mode 100644 libs/libtheora-1.1/win32/experimental/transcoder/avi2vp3/avi2vp3.c
create mode 100644 libs/libtheora-1.1/win32/experimental/transcoder/avi2vp3/avilib.c
create mode 100644 libs/libtheora-1.1/win32/experimental/transcoder/avi2vp3/avilib.h
create mode 100644 libs/libtheora-1.1/win32/experimental/transcoder/avi2vp3/outfile.vp3
create mode 100644 libs/libtheora-1.1/win32/experimental/transcoder/avi2vp3/vp31.avi
create mode 100644 libs/libtheora-1.1/win32/experimental/transcoder/readme.txt
create mode 100644 libs/libtheora-1.1/win32/experimental/transcoder/transcoder.dsp
create mode 100644 libs/libtheora-1.1/win32/experimental/transcoder/transcoder_example.c
create mode 100644 libs/libtheora-1.1/win32/experimental/wincompat/README.txt
create mode 100644 libs/libtheora-1.1/win32/experimental/wincompat/getopt.c
create mode 100644 libs/libtheora-1.1/win32/experimental/wincompat/getopt.h
create mode 100644 libs/libtheora-1.1/win32/experimental/wincompat/getopt_long.c
create mode 100644 libs/libtheora-1.1/win32/experimental/wincompat/unistd.h
create mode 100644 libs/libtheora-1.1/win32/getopt.c
create mode 100644 libs/libtheora-1.1/win32/getopt1.c
create mode 100644 libs/libtheora-1.1/win32/getopt_win.h
create mode 100644 libs/libtheora-1.1/win32/theora_static.dsp
create mode 100644 libs/libtheora-1.1/win32/xmingw32/Makefile
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoradec-all.def
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoradec-all.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoradec.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoradec70.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoradec70d.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoradec71.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoradec71d.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoradec80.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoradec80d.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoradecd.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoraenc-all.def
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoraenc-all.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoraenc.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoraenc70.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoraenc70d.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoraenc71.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoraenc71d.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoraenc80.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoraenc80d.rc
create mode 100644 libs/libtheora-1.1/win32/xmingw32/libtheoraencd.rc
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c3d4ab95..556a99db 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -126,6 +126,8 @@ elseif(MSVC12)
endif()
endif()
+
+
set(MEGA_ZLIB_VER "1.2.8")
set(MEGA_PHYSFS_VER "2.0.3")
set(MEGA_LUA51_VER "5.1.5")
@@ -134,6 +136,7 @@ set(MEGA_LIBPNG_VER "166")
set(MEGA_JPEG_TURBO_VER "1.3.1")
set(MEGA_LIBOGG_VER "1.3.1")
set(MEGA_LIBVORBIS_VER "1.3.3")
+set(MEGA_LIBTHEORA_VER "1.1")
set(MEGA_MPG123_VER "1.15.3")
set(MEGA_FREETYPE_VER "2.5.0.1")
set(MEGA_SDL2_VER "2.0.3-1c0f6952e65e")
@@ -195,6 +198,12 @@ add_subdirectory("libs/libvorbis-${MEGA_LIBVORBIS_VER}" ${CMAKE_BINARY_DIR}/libv
set(MEGA_LIBVORBIS vorbis-static)
set(MEGA_LIBVORBISFILE vorbisfile-static)
+message(STATUS "-----------------------------------------------------")
+message(STATUS "Configuring: libtheora ${MEGA_LIBTHEORA_VER}")
+message(STATUS "-----------------------------------------------------")
+add_subdirectory("libs/libtheora-${MEGA_LIBTHEORA_VER}" ${CMAKE_BINARY_DIR}/libtheora)
+set(MEGA_LIBTHEORA theora-static)
+
message(STATUS "-----------------------------------------------------")
message(STATUS "Configuring: mpg123 ${MEGA_MPG123_VER}")
message(STATUS "-----------------------------------------------------")
@@ -293,6 +302,7 @@ set(MEGA_3P
${MEGA_LIBOGG}
${MEGA_LIBVORBIS}
${MEGA_LIBVORBISFILE}
+ ${MEGA_LIBTHEORA}
${MEGA_MPEG123}
${MEGA_FREETYPE}
${MEGA_SDL2}
diff --git a/libs/libtheora-1.1/AUTHORS b/libs/libtheora-1.1/AUTHORS
new file mode 100644
index 00000000..c8d0992e
--- /dev/null
+++ b/libs/libtheora-1.1/AUTHORS
@@ -0,0 +1,49 @@
+Monty
+ - Original VP3 port
+
+Ralph Giles
+Timothy B. Terriberry
+Monty
+ - Ongoing development
+
+Dan B. Miller
+ - Pre alpha3 development
+
+Rudolf Marek
+Wim Tayman
+Dan Lenski
+Nils Pipenbrinck
+Monty
+ - MMX optimized functions
+
+Aaron Colwell
+Thomas Vander Stichele
+Jan Gerber
+Conrad Parker
+Cristian Adam
+Sebastian Pippin
+Simon Hosie
+ - Bug fixes, enhancements, build systems.
+
+Mauricio Piacentini
+ - Original win32 projects and example ports
+ - VP3->Theora transcoder
+
+Silvia Pfeiffer
+ - Figures for the spec
+
+Michael Smith
+Andre Pang
+calc
+Chris Cheney
+Brendan Cully
+Edward Hervey
+Adam Moss
+Colin Ward
+Jeremy C. Reed
+Arc Riley
+Rodolphe Ortalo
+ - Bug fixes
+
+
+and other Xiph.org contributors
diff --git a/libs/libtheora-1.1/CHANGES b/libs/libtheora-1.1/CHANGES
new file mode 100644
index 00000000..7bd04a1f
--- /dev/null
+++ b/libs/libtheora-1.1/CHANGES
@@ -0,0 +1,243 @@
+libtheora 1.1.2 (unreleased snapshot)
+
+ - Fix Huffman table decoding with OC_HUFF_SLUSH is set to 0
+ - Fix a frame size bug in player_example
+ - Add support for passing a buffer the size of the picture
+ region, rather than a full padded frame to th_encode_ycbcr_in()
+ as was possible with the legacy pre-1.0 API.
+ - 4:4:4 support in player_example using software yuv->rgb
+ - Better rgb->yuv conversion in png2theora
+ - Clean up warnings and local variables
+ - Build and documentation fixes
+
+libtheora 1.1.1 (2009 October 1)
+
+ - Fix problems with MSVC inline assembly
+ - Add the missing encoder_disabled.c to the distribution
+ - build updates: autogen.sh should work better after switching systems
+ and the MSVC project now defaults to the dynamic runtime library
+ - Namespace some variables to avoid conflicts on wince.
+
+libtheora 1.1.0 (2009 September 24)
+
+ - Fix various small issues with the example and telemetry code
+ - Fix handing a zero-byte packet as the first frame
+ - Documentation cleanup
+ - Two minor build fixes
+
+libtheora 1.1beta3 (2009 August 22)
+
+ - Rate control fixes to smooth quality
+ - MSVC build now exports all of the 1.0 api
+ - Assorted small bug fixes
+
+libtheora 1.1beta2 (2009 August 12)
+
+ - Fix a rate control problem with difficult input
+ - Build fixes for OpenBSD and Apple Xcode
+ - Examples now all use the 1.0 api
+ - TH_ENCCTL_SET_SPLEVEL works again
+ - Various bug fixes and source tree rearrangement
+
+libtheora 1.1beta1 (2009 August 5)
+
+ - Support for two-pass encoding
+ - Performance optimization of both encoder and decoder
+ - Encoder supports dynamic adjustment of quality and
+ bitrate targets
+ - Encoder is generally more configurable, and all
+ rate control modes perform better
+ - Encoder now accepts 4:2:2 and 4:4:4 chroma sampling
+ - Decoder telemetry output shows quantization choice
+ and a breakdown of bitrate usage in the frame
+ - MSVC assembly optimizations up to date and functional
+
+libtheora 1.1alpha2 (2009 May 26)
+
+ - Reduce lambda for small quantizers.
+ - New encoder fDCT does better on smooth gradients
+ - Use SATD for mode decisions (1-2% bitrate reduction)
+ - Assembly rewrite for new features and general speed up
+ - Share code between the encoder and decoder for performance
+ - Fix 4:2:2 decoding and telemetry
+ - MSVC project files updated, but assembly is disabled.
+ - New configure option --disable-spec to work around toolchain
+ detection failures.
+ - Limit symbol exports on MacOS X.
+ - Port remaining unit tests from the 1.0 release.
+
+libtheora 1.1alpha1 (2009 March 27)
+
+ - Encoder rewrite with much improved vbr quality/bitrate and
+ better tracking of the target rate in cbr mode.
+ - MSVC project files do not work in this release.
+
+libtheora 1.0 (2008 November 3)
+
+ - Merge x86 assembly for forward DCT from Thusnelda branch.
+ - Update 32 bit MMX with loop filter fix.
+ - Check for an uninitialized state before dereferencing in propagating
+ decode calls.
+ - Remove all TH_DEBUG statements.
+ - Rename the bitpacker source files copied from libogg to avoid
+ confusing simple build systems using both libraries.
+ - Declare bitfield entries to be explicitly signed for Solaris cc.
+ - Set quantization parameters to default values when an empty buffer is
+ passed with TH_ENCCTL_SET_QUANT_PARAMS.
+ - Split encoder and decoder tests depending on configure settings.
+ - Return lstylex.sty to the distribution.
+ - Disable inline assembly on gcc versions prior to 3.1.
+ - Remove extern references for OC_*_QUANT_MIN.
+ - Make various data tables static const so they can be read-only.
+ - Remove ENCCTL codes from the old encoder API.
+ - Implement TH_ENCCTL_SET_KEYFRAME_FREQUENCY_FORCE ctl.
+ - Fix segfault when exactly one of the width or height is not a multiple
+ of 16, but the other is.
+ - Compute the correct vertical offset for chroma.
+ - cpuid assembly fix for MSVC.
+ - Add VS2008 project files.
+ - Build updates for 64-bit platforms, Mingw32, VS and XCode.
+ - Do not clobber the cropping rectangle.
+ - Declare ourselves 1.0final to pkg-config to sort after beta releases.
+ - Fix the scons build to include asm in libtheoradec/enc.
+
+libtheora 1.0beta3 (2008 April 16)
+
+ - Build new libtheoradec and libtheoraenc libraries
+ supporting the new API from theora-exp. This API should
+ not be considered stable yet.
+ - Change granule_frame() to return an index as documented.
+ This is a change of behaviour from 1.0beta1.
+ - Document that granule_time() returns the end of the
+ presentation interval.
+ - Use a custom copy of the libogg bitpacker in the decoder
+ to avoid function call overhead.
+ - MMX code improved and ported to MSVC.
+ - Fix a problem with the MMX code on SELinux.
+ - Fix a problem with decoder quantizer initialization.
+ - Fix a page queue problem with png2theora.
+ - Improved robustness.
+ - Updated VS2005 project files.
+ - Dropped build support for Microsoft VS2003.
+ - Dropped build support for the unreleased libogg2.
+ - Added the specification to the autotools build.
+ - Specification corrections.
+
+libtheora 1.0beta2 (2007 October 12)
+
+ - Fix a crash bug on char-is-unsigned architectures (PowerPC)
+ - Fix a buffer sizing issue that caused rare encoder crashes
+ - Fix a buffer alignment issue
+ - Build fixes for MingW32, MSVC
+ - Improved format documentation.
+
+libtheora 1.0beta1 (2007 September 22)
+
+ - Granulepos scheme modified to match other codecs. This bumps
+ the bitstream revision to 3.2.1. Bitstreams marked 3.2.0 are
+ handled correctly by this decoder. Older decoders will show
+ a one frame sync error in the less noticeable direction.
+
+libtheora 1.0alpha8 (2007 September 18)
+
+ - Switch to new spec compliant decoder from theora-exp branch.
+ Written by Dr. Timothy Terriberry.
+ - Add support to the encoder for using quantization settings
+ provided by the application.
+ - more assembly optimizations
+
+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/libs/libtheora-1.1/CMakeLists.txt b/libs/libtheora-1.1/CMakeLists.txt
new file mode 100644
index 00000000..21907f26
--- /dev/null
+++ b/libs/libtheora-1.1/CMakeLists.txt
@@ -0,0 +1,48 @@
+cmake_minimum_required(VERSION 2.8)
+
+project(theora)
+
+option(THEORA_BUILD_SHARED "Build shared libtheora" OFF)
+option(THEORA_BUILD_STATIC "Build static libtheora" ON)
+
+set(THEORA_SRC
+ lib/analyze.c
+ lib/apiwrapper.c
+ lib/bitpack.c
+ lib/cpu.c
+ lib/decapiwrapper.c
+ lib/decinfo.c
+ lib/decode.c
+ lib/dequant.c
+ lib/encapiwrapper.c
+ lib/encfrag.c
+ lib/encinfo.c
+ lib/encode.c
+ lib/encoder_disabled.c
+ lib/enquant.c
+ lib/fdct.c
+ lib/fragment.c
+ lib/huffdec.c
+ lib/huffenc.c
+ lib/idct.c
+ lib/info.c
+ lib/internal.c
+ lib/mathops.c
+ lib/mcenc.c
+ lib/quant.c
+ lib/rate.c
+ lib/state.c
+ lib/tokenize.c
+)
+
+if(THEORA_BUILD_STATIC)
+ add_library(theora-static STATIC ${THEORA_SRC})
+ target_include_directories(theora-static PUBLIC include lib)
+ target_link_libraries(theora-static ${OGG_LIBRARY})
+endif()
+
+if(THEORA_BUILD_SHARED)
+ add_library(theora SHARED ${THEORA_SRC} lib/theora.def)
+ target_include_directories(theora PUBLIC include lib)
+ target_link_libraries(theora ${OGG_LIBRARY})
+endif()
diff --git a/libs/libtheora-1.1/COPYING b/libs/libtheora-1.1/COPYING
new file mode 100644
index 00000000..8e334356
--- /dev/null
+++ b/libs/libtheora-1.1/COPYING
@@ -0,0 +1,28 @@
+Copyright (C) 2002-2009 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/libs/libtheora-1.1/LICENSE b/libs/libtheora-1.1/LICENSE
new file mode 100644
index 00000000..530a8e28
--- /dev/null
+++ b/libs/libtheora-1.1/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/libs/libtheora-1.1/Makefile.am b/libs/libtheora-1.1/Makefile.am
new file mode 100644
index 00000000..6c7c2ae6
--- /dev/null
+++ b/libs/libtheora-1.1/Makefile.am
@@ -0,0 +1,35 @@
+## Process this file with automake to produce Makefile.in
+
+AUTOMAKE_OPTIONS = foreign 1.11 dist-zip dist-xz
+
+if THEORA_ENABLE_EXAMPLES
+EXAMPLES_DIR = examples
+else
+EXAMPLES_DIR =
+endif
+
+SUBDIRS = lib include doc tests m4 $(EXAMPLES_DIR)
+
+
+# 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 macosx symbian SConstruct \
+ libtheora.spec libtheora.spec.in \
+ theora-uninstalled.pc.in
+
+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = theora.pc theoradec.pc theoraenc.pc
+
+# Remove the .svn folders included in the tarball
+dist-hook:
+ find $(distdir) -type d -name '.svn' | xargs rm -rf
+
+debug:
+ $(MAKE) all CFLAGS="@DEBUG@"
+
+profile:
+ $(MAKE) all CFLAGS="@PROFILE@"
diff --git a/libs/libtheora-1.1/README b/libs/libtheora-1.1/README
new file mode 100644
index 00000000..8f82b8ab
--- /dev/null
+++ b/libs/libtheora-1.1/README
@@ -0,0 +1,152 @@
+-------------------------------------------------------------------------
+ The Xiph.org Foundation's libtheora 1.1
+-------------------------------------------------------------------------
+
+*** 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, adds new features
+while allow it a longer useful lifetime as an competitive codec.
+
+The 1.0 release decoder supported all the new features, but the
+encoder is nearly identical to the VP3 code.
+
+The 1.1 release features a completely rewritten encoder, offering
+better performance and compression, and making more complete use
+of the format's feature set. Files produced by both encoders can
+be decoded by either release.
+
+*** 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/ for instructions.
+
+-------------------------------------------------------------------------
+Getting started with the code
+-------------------------------------------------------------------------
+
+*** What do I need to build the source?
+
+Requirements summary:
+
+ For libtheora:
+
+ libogg 1.1 or newer.
+
+ For example encoder:
+
+ as above,
+
+ libvorbis and libvorbisenc 1.0.1 or newer.
+
+ For creating a source distribution package:
+
+ as above,
+
+ Doxygen to build the API documentation,
+ pdflatex and fig2dev to build the format specification
+ (transfig package in Ubuntu).
+
+ 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.
+
+Windows build support is included in the win32 directory.
+
+Project files for Apple XCode are included in the macosx directory.
+
+There is also an experimental scons build.
+
+*** 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. The encoder expects audio,
+if any, in a separate wave WAV file. Try 'encoder_example -h' for a
+complete list of options.
+
+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.
+
+There is also a 'png2theora' example which accepts a set of image
+files in that format.
+
+*** 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?
+
+The programs in the examples directory are intended as tutorial source
+for developers using the library. As such they sacrifice features and
+robustness in the interests of comprehension and should not be
+considered serious applications.
+
+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 plugins for major media frameworks.
+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 is needed.
+
+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/libs/libtheora-1.1/SConstruct b/libs/libtheora-1.1/SConstruct
new file mode 100644
index 00000000..01bcfb46
--- /dev/null
+++ b/libs/libtheora-1.1/SConstruct
@@ -0,0 +1,225 @@
+# 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]
+
+encoder_sources = """
+ apiwrapper.c
+ fragment.c
+ idct.c
+ internal.c
+ state.c
+ quant.c
+ analyze.c
+ encfrag.c
+ encapiwrapper.c
+ encinfo.c
+ encode.c
+ enquant.c
+ fdct.c
+ huffenc.c
+ mathops.c
+ mcenc.c
+ rate.c
+ tokenize.c
+"""
+
+decoder_sources = """
+ apiwrapper.c
+ bitpack.c
+ decapiwrapper.c
+ decinfo.c
+ decode.c
+ dequant.c
+ fragment.c
+ huffdec.c
+ idct.c
+ info.c
+ internal.c
+ quant.c
+ state.c
+"""
+
+env = Environment()
+if env['CC'] == 'gcc':
+ env.Append(CCFLAGS=["-g", "-O2", "-Wall", "-Wno-parentheses"])
+
+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 not an x86 host: preprocessor macro __i386__ not defined
+#endif
+ return 0;
+ }
+ """
+def CheckHost_x86_32(context):
+ context.Message('Checking for an x86 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 not an x86_64 host: preprocessor macro __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
+
+if conf.CheckPKG('libpng'):
+ have_libpng=True
+else:
+ have_libpng=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():
+ env.Append(CPPDEFINES='OC_X86_ASM')
+ decoder_sources += """
+ x86/mmxidct.c
+ x86/mmxfrag.c
+ x86/mmxstate.c
+ x86/x86state.c
+ """
+ encoder_sources += """
+ x86/mmxencfrag.c
+ x86/mmxfdct.c
+ x86/x86enc.c
+ x86/mmxfrag.c
+ x86/mmxidct.c
+ x86/mmxstate.c
+ x86/x86state.c
+ """
+elif conf.CheckHost_x86_64():
+ env.Append(CPPDEFINES=['OC_X86_ASM', 'OC_X86_64_ASM'])
+ decoder_sources += """
+ x86/mmxidct.c
+ x86/mmxfrag.c
+ x86/mmxstate.c
+ x86/x86state.c
+ """
+ encoder_sources += """
+ x86/mmxencfrag.c
+ x86/mmxfdct.c
+ x86/x86enc.c
+ x86/sse2fdct.c
+ x86/mmxfrag.c
+ x86/mmxidct.c
+ x86/mmxstate.c
+ x86/x86state.c
+ """
+
+env = conf.Finish()
+
+env.Append(CPPPATH=['include'])
+env.ParseConfig('pkg-config --cflags --libs ogg')
+
+libtheoradec_Sources = Split(decoder_sources)
+libtheoraenc_Sources = Split(encoder_sources)
+
+libtheoradec_a = env.Library('lib/theoradec',
+ path('lib', libtheoradec_Sources))
+libtheoradec_so = env.SharedLibrary('lib/theoradec',
+ path('lib', libtheoradec_Sources))
+
+libtheoraenc_a = env.Library('lib/theoraenc',
+ path('lib', libtheoraenc_Sources))
+libtheoraenc_so = env.SharedLibrary('lib/theoraenc',
+ path('lib', libtheoraenc_Sources) + [libtheoradec_so])
+
+#installing
+prefix='/usr'
+lib_dir = prefix + '/lib'
+env.Alias('install', prefix)
+env.Install(lib_dir, [libtheoradec_a, libtheoradec_so])
+env.Install(lib_dir, [libtheoraenc_a, libtheoraenc_so])
+
+# example programs
+dump_video = env.Clone()
+dump_video_Sources = Split("""dump_video.c ../lib/libtheoradec.a""")
+dump_video.Program('examples/dump_video', path('examples', dump_video_Sources))
+
+dump_psnr = env.Clone()
+dump_psnr.Append(LIBS='m')
+dump_psnr_Sources = Split("""dump_psnr.c ../lib/libtheoradec.a""")
+dump_psnr.Program('examples/dump_psnr', path('examples', dump_psnr_Sources))
+
+if have_vorbis:
+ encex = dump_video.Clone()
+ encex.ParseConfig('pkg-config --cflags --libs vorbisenc vorbis')
+ encex_Sources = Split("""
+ encoder_example.c
+ ../lib/libtheoraenc.a
+ ../lib/libtheoradec.a
+ """)
+ encex.Program('examples/encoder_example', path('examples', encex_Sources))
+
+ if build_player_example:
+ plyex = encex.Clone()
+ plyex_Sources = Split("""
+ player_example.c
+ ../lib/libtheoradec.a
+ """)
+ plyex.ParseConfig('sdl-config --cflags --libs')
+ plyex.Program('examples/player_example', path('examples', plyex_Sources))
+
+png2theora = env.Clone()
+png2theora_Sources = Split("""png2theora.c
+ ../lib/libtheoraenc.a
+ ../lib/libtheoradec.a
+""")
+png2theora.ParseConfig('pkg-config --cflags --libs libpng')
+png2theora.Program('examples/png2theora', path('examples', png2theora_Sources))
diff --git a/libs/libtheora-1.1/autogen.sh b/libs/libtheora-1.1/autogen.sh
new file mode 100644
index 00000000..2700868c
--- /dev/null
+++ b/libs/libtheora-1.1/autogen.sh
@@ -0,0 +1,130 @@
+#!/bin/sh
+# Run this to set up the build system: configure, makefiles, etc.
+# (based on the version in enlightenment's cvs)
+
+package="theora"
+
+ACLOCAL_FLAGS="-I m4"
+
+olddir=`pwd`
+srcdir=`dirname $0`
+test -z "$srcdir" && srcdir=.
+
+cd "$srcdir"
+DIE=0
+
+/bin/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]*\.[0-9][0-9]*\).*/\1/"
+VERSIONMKMAJ="sed -e s/\([0-9][0-9]*\)[^0-9].*/\\1/"
+VERSIONMKMIN="sed -e s/.*[0-9][0-9]*\.//"
+
+# 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
+ /bin/echo -n "checking for automake... "
+ AUTOMAKE=automake
+ ACLOCAL=aclocal
+ if ($AUTOMAKE --version < /dev/null > /dev/null 2>&1); then
+ /bin/echo "yes"
+ else
+ /bin/echo "no"
+ AUTOMAKE=
+ fi
+ else
+ /bin/echo -n "checking for automake $AM_NEEDED or later... "
+ majneeded=`echo $AM_NEEDED | $VERSIONMKMAJ`
+ minneeded=`echo $AM_NEEDED | $VERSIONMKMIN`
+ for am in automake-$AM_NEEDED automake$AM_NEEDED \
+ automake automake-1.7 automake-1.8 automake-1.9 \
+ automake-1.10 automake-1.11; do
+ ($am --version < /dev/null > /dev/null 2>&1) || continue
+ ver=`$am --version < /dev/null | head -n 1 | $VERSIONGREP`
+ maj=`echo $ver | $VERSIONMKMAJ`
+ min=`echo $ver | $VERSIONMKMIN`
+ if test $maj -eq $majneeded -a $min -ge $minneeded; then
+ AUTOMAKE=$am
+ /bin/echo $AUTOMAKE
+ break
+ fi
+ done
+ test -z $AUTOMAKE && /bin/echo "no"
+ /bin/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 aclocal-1.10 aclocal-1.11; do
+ ($ac --version < /dev/null > /dev/null 2>&1) || continue
+ ver=`$ac --version < /dev/null | head -n 1 | $VERSIONGREP`
+ maj=`echo $ver | $VERSIONMKMAJ`
+ min=`echo $ver | $VERSIONMKMIN`
+ if test $maj -eq $majneeded -a $min -ge $minneeded; then
+ ACLOCAL=$ac
+ /bin/echo $ACLOCAL
+ break
+ fi
+ done
+ test -z $ACLOCAL && /bin/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
+
+/bin/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
+ /bin/echo "nope."
+ LIBTOOLIZE=libtoolize
+else
+ /bin/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
+
+/bin/echo "Generating configuration files for $package, please wait...."
+
+/bin/echo " $ACLOCAL $ACLOCAL_FLAGS"
+$ACLOCAL $ACLOCAL_FLAGS || exit 1
+/bin/echo " $LIBTOOLIZE --automake --force"
+$LIBTOOLIZE --automake --force || exit 1
+/bin/echo " autoheader"
+autoheader || exit 1
+/bin/echo " $AUTOMAKE --add-missing $AUTOMAKE_FLAGS"
+$AUTOMAKE --add-missing $AUTOMAKE_FLAGS || exit 1
+/bin/echo " autoconf"
+autoconf || exit 1
+
+cd $olddir
+$srcdir/configure --enable-maintainer-mode "$@" && /bin/echo
diff --git a/libs/libtheora-1.1/configure.ac b/libs/libtheora-1.1/configure.ac
new file mode 100644
index 00000000..b2118944
--- /dev/null
+++ b/libs/libtheora-1.1/configure.ac
@@ -0,0 +1,531 @@
+dnl Process this file with autoconf to produce a configure script
+
+dnl ------------------------------------------------
+dnl Initialization and Versioning
+dnl ------------------------------------------------
+
+AC_INIT(libtheora,[1.1.1+svn])
+
+AC_CANONICAL_HOST
+AC_CANONICAL_TARGET
+
+AM_CONFIG_HEADER([config.h])
+AC_CONFIG_SRCDIR([lib/fdct.c])
+AM_INIT_AUTOMAKE
+AM_MAINTAINER_MODE
+
+m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
+
+dnl Library versioning
+dnl CURRENT, REVISION, AGE
+dnl - library source changed -> increment REVISION
+dnl - interfaces added/removed/changed -> increment CURRENT, REVISION = 0
+dnl - interfaces added -> increment AGE
+dnl - interfaces removed -> AGE = 0
+
+TH_LIB_CURRENT=3
+TH_LIB_REVISION=10
+TH_LIB_AGE=3
+AC_SUBST(TH_LIB_CURRENT)
+AC_SUBST(TH_LIB_REVISION)
+AC_SUBST(TH_LIB_AGE)
+
+THDEC_LIB_CURRENT=2
+THDEC_LIB_REVISION=4
+THDEC_LIB_AGE=1
+AC_SUBST(THDEC_LIB_CURRENT)
+AC_SUBST(THDEC_LIB_REVISION)
+AC_SUBST(THDEC_LIB_AGE)
+
+THENC_LIB_CURRENT=2
+THENC_LIB_REVISION=2
+THENC_LIB_AGE=1
+AC_SUBST(THENC_LIB_CURRENT)
+AC_SUBST(THENC_LIB_REVISION)
+AC_SUBST(THENC_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_CC_C_O
+AC_LIBTOOL_WIN32_DLL
+AM_PROG_LIBTOOL
+
+dnl Add parameters for aclocal
+AC_SUBST(ACLOCAL_AMFLAGS, "-I m4")
+
+dnl Check for doxygen
+AC_ARG_ENABLE([doc],
+ AS_HELP_STRING([--enable-doc], [Build API documentation]),
+ [ac_enable_doc=$enableval], [ac_enable_doc=auto])
+
+if test "x$ac_enable_doc" != "xno"; then
+ AC_CHECK_PROG(HAVE_DOXYGEN, doxygen, true, false)
+
+ if test "x$HAVE_DOXYGEN" = "xfalse" -a "x$ac_enable_doc" = "xyes"; then
+ AC_MSG_ERROR([*** API documentation explicitly requested but Doxygen not found])
+ fi
+else
+ HAVE_DOXYGEN=false
+fi
+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 tools used to build the format specification
+BUILD_SPEC="false"
+ac_build_spec=no
+AC_ARG_ENABLE(spec,
+ AS_HELP_STRING([--enable-spec], [(re)build the specification document]),
+ [
+ if test "x$enableval" = "xyes"; then
+ ac_build_spec=$enableval
+ fi
+ ], [
+ ac_build_spec=no
+ ] )
+if test "x$ac_build_spec" = "xyes"; then
+ AC_CHECK_PROG(HAVE_PDFLATEX, pdflatex, yes)
+ AC_CHECK_PROG(HAVE_BIBTEX, bibtex, yes)
+ AC_CHECK_PROG(HAVE_TRANSFIG, fig2dev, yes)
+ if test -r doc/spec/spec.tex; then
+ if test "x$HAVE_PDFLATEX" = "xyes"; then
+ if test "x$HAVE_BIBTEX" = "xyes"; then
+ if test "x$HAVE_TRANSFIG" = "xyes"; then
+ tex_pkg_list=`fgrep usepackage doc/spec/spec.tex | grep \{ | grep -v ltablex`
+ tex_pkg_ok="yes"
+ for pkg_line in $tex_pkg_list; do
+ pkg_name=`echo $pkg_line | sed -e 's/.*{\(.*\)}.*/\1/'`
+ AC_MSG_CHECKING([for Tex package $pkg_name])
+ cat >conftest.tex <<_ACEOF
+\\documentclass{book}
+$pkg_line
+\\begin{document}
+Hello World.
+\\end{document}
+_ACEOF
+ if pdflatex -interaction batchmode -halt-on-error conftest < /dev/null > /dev/null 2>&1; then
+ AC_MSG_RESULT([ok])
+ else
+ tex_pkg_ok="no"
+ AC_MSG_RESULT([no])
+ fi
+ done
+ if test -w conftest.tex; then rm conftest.tex; fi
+ if test -w conftest.tex; then rm conftest.aux; fi
+ if test -w conftest.pdf; then rm conftest.pdf; fi
+ if test "x$tex_pkg_ok" = "xyes"; then
+ BUILD_SPEC="true"
+ fi
+ fi
+ fi
+ fi
+ fi
+fi
+AM_CONDITIONAL(BUILD_SPEC, $BUILD_SPEC)
+if test $BUILD_SPEC = "false"; then
+ AC_MSG_WARN([*** Format Specification will not built.])
+fi
+
+dnl Check for valgrind
+VALGRIND_ENVIRONMENT=""
+ac_enable_valgrind=no
+AC_ARG_ENABLE(valgrind-testing,
+ AS_HELP_STRING([--enable-valgrind-testing], [Enable running of tests inside Valgrind]),
+ [ ac_enable_valgrind=$enableval ], [ 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 -Wno-parentheses -DDEBUG -D__NO_MATH_INLINES"
+ CFLAGS="-Wall -Wno-parentheses -O3 -fforce-addr -fomit-frame-pointer -finline-functions -funroll-loops"
+ PROFILE="-Wall -Wno-parentheses -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,
+ AS_HELP_STRING([--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([OC_X86_ASM], [], [make use of x86 asm optimization])
+ if test "x$target_vendor" = "xapple"; then
+ THEORA_LDFLAGS="$THEORA_LDFLAGS -Wl,-read_only_relocs,suppress"
+ fi
+ ;;
+ x86_64)
+ cpu_x86_64=yes
+ cpu_optimization="64 bit x86"
+ AC_DEFINE([OC_X86_ASM], [], [make use of x86 asm optimization])
+ AC_DEFINE([OC_X86_64_ASM], [], [make use of x86_64 asm optimization])
+ ;;
+ 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
+AC_MSG_CHECKING([how to control symbol export])
+
+THDEC_VERSION_ARG=""
+THENC_VERSION_ARG=""
+TH_VERSION_ARG=""
+if test "x$lt_cv_prog_gnu_ld" = "xyes"; then
+ case "$target_os" in
+ *mingw*)
+ THEORA_LDFLAGS="$THEORA_LDFLAGS -no-undefined"
+ THDEC_VERSION_ARG="-export-symbols \$(top_srcdir)/win32/xmingw32/libtheoradec-all.def"
+ THENC_VERSION_ARG="-export-symbols \$(top_srcdir)/win32/xmingw32/libtheoraenc-all.def"
+ THENC_VERSION_ARG="$THENC_VERSION_ARG -ltheoradec"
+ THC_VERSION_ARG="-export-symbols \$(top_srcdir)/win32/libtheora.def"
+ AC_MSG_RESULT([-export-symbols])
+ ;;
+ linux* | solaris* | gnu* | k*bsd*-gnu)
+ THDEC_VERSION_ARG='-Wl,--version-script=$(srcdir)/Version_script-dec'
+ THENC_VERSION_ARG='-Wl,--version-script=$(srcdir)/Version_script-enc'
+ TH_VERSION_ARG='-Wl,--version-script=$(srcdir)/Version_script'
+ AC_MSG_RESULT([--version-script])
+ ;;
+ *)
+ # build without versioning
+ AC_MSG_RESULT([no])
+ ;;
+ esac
+else
+ case "$target_os" in
+ darwin*)
+ THDEC_VERSION_ARG='-Wl,-exported_symbols_list,$(srcdir)/theoradec.exp'
+ THENC_VERSION_ARG='-Wl,-exported_symbols_list,$(srcdir)/theoraenc.exp'
+ TH_VERSION_ARG='-Wl,-exported_symbols_list,$(srcdir)/theora.exp'
+ AC_MSG_RESULT([-exported_symbols_list])
+ ;;
+ *)
+ # build without versioning
+ AC_MSG_RESULT([no])
+ ;;
+ esac
+fi
+
+THEORADEC_LDFLAGS="$THEORA_LDFLAGS $THDEC_VERSION_ARG"
+THEORAENC_LDFLAGS="$THEORA_LDFLAGS $THENC_VERSION_ARG"
+THEORA_LDFLAGS="$THEORA_LDFLAGS $TH_VERSION_ARG"
+AC_SUBST(THEORADEC_LDFLAGS)
+AC_SUBST(THEORAENC_LDFLAGS)
+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 OpenBSD needs -lossaudio to use the oss interface
+OSS_LIBS=
+case "$target_os" in
+ openbsd*)
+ OSS_LIBS='-lossaudio'
+ ;;
+esac
+AC_SUBST(OSS_LIBS)
+
+dnl check for libpng
+HAVE_PNG=no
+if test "x$HAVE_PKG_CONFIG" = "xyes"
+then
+ PKG_CHECK_MODULES(PNG, libpng, HAVE_PNG=yes, HAVE_PNG=no)
+fi
+AC_SUBST(PNG_CFLAGS)
+AC_SUBST(PNG_LIBS)
+
+dnl check for libcairo
+HAVE_CAIRO=no
+AC_ARG_ENABLE(telemetry,
+ AS_HELP_STRING([--enable-telemetry], [Enable debugging output controls]),
+ [ ac_enable_telemetry=$enableval ], [ ac_enable_telemetry=no] )
+
+if test "x${ac_enable_telemetry}" = xyes; then
+ if test "x$HAVE_PKG_CONFIG" = "xyes"
+ then
+ PKG_CHECK_MODULES(CAIRO, cairo, HAVE_CAIRO=yes, HAVE_CAIRO=no)
+ AC_DEFINE([HAVE_CAIRO], [], [libcairo is available for visual debugging output])
+ fi
+ if test x$HAVE_CAIRO != xyes; then
+ AC_MSG_WARN([libcairo not found -- not compiling telemetry output support ])
+ fi
+ AC_SUBST(CAIRO_CFLAGS)
+ AC_SUBST(CAIRO_LIBS)
+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,
+ AS_HELP_STRING([--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,
+ AS_HELP_STRING([--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 Configuration option for examples
+
+ac_enable_examples=yes
+AC_ARG_ENABLE(examples,
+ AS_HELP_STRING([--disable-examples], [Disable examples]),
+ [ ac_enable_examples=$enableval ], [ ac_enable_examples=yes] )
+AM_CONDITIONAL(THEORA_ENABLE_EXAMPLES, [test "x${ac_enable_examples}" != xno])
+
+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 OpenBSD needs -lcompat for ftime() used by dump_video.c
+AC_SEARCH_LIBS([ftime], [compat])
+
+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\$(EXEEXT)"
+fi
+if test x$HAVE_PNG = xyes; then
+ BUILDABLE_EXAMPLES="$BUILDABLE_EXAMPLES png2theora\$(EXEEXT)"
+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 doc/spec/Makefile
+ tests/Makefile
+ m4/Makefile
+ libtheora.spec
+ theora.pc
+ theora-uninstalled.pc
+ theoradec.pc
+ theoradec-uninstalled.pc
+ theoraenc.pc
+ theoraenc-uninstalled.pc
+])
+
+AS_AC_EXPAND(LIBDIR, ${libdir})
+AS_AC_EXPAND(INCLUDEDIR, ${includedir})
+AS_AC_EXPAND(BINDIR, ${bindir})
+AS_AC_EXPAND(DOCDIR, ${docdir})
+
+if test $HAVE_DOXYGEN = "false"; then
+ doc_build="no"
+else
+ doc_build="yes"
+fi
+if test $BUILD_SPEC = "false"; then
+ spec_build="no"
+else
+ spec_build="yes"
+fi
+
+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}
+ Debugging telemetry: ........ ${ac_enable_telemetry}
+ Build example code: ......... ${ac_enable_examples}
+ API Documentation: .......... ${doc_build}
+ Format Documentation: ....... ${spec_build}
+
+ Installation paths:
+
+ libtheora: ................... ${LIBDIR}
+ C header files: .............. ${INCLUDEDIR}/theora
+ Documentation: ............... ${DOCDIR}
+
+ 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/libs/libtheora-1.1/debian/changelog b/libs/libtheora-1.1/debian/changelog
new file mode 100644
index 00000000..bfcd6440
--- /dev/null
+++ b/libs/libtheora-1.1/debian/changelog
@@ -0,0 +1,15 @@
+libtheora (0.0.0.alpha3-1) unstable; urgency=low
+
+ * Initial upload to Debian.
+
+ -- Christopher L Cheney Tue, 29 Jun 2004 22:00:00 -0500
+
+libtheora (0.0.0-0) unstable; urgency=low
+
+ * Initial Release.
+
+ -- Christopher L Cheney Wed, 25 Sep 2002 21:00:00 -0500
+
+Local variables:
+mode: debian-changelog
+End:
diff --git a/libs/libtheora-1.1/debian/control b/libs/libtheora-1.1/debian/control
new file mode 100644
index 00000000..28921c31
--- /dev/null
+++ b/libs/libtheora-1.1/debian/control
@@ -0,0 +1,24 @@
+Source: libtheora
+Section: libs
+Priority: optional
+Maintainer: Christopher L Cheney
+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/libs/libtheora-1.1/debian/copyright b/libs/libtheora-1.1/debian/copyright
new file mode 100644
index 00000000..5eb0d7b0
--- /dev/null
+++ b/libs/libtheora-1.1/debian/copyright
@@ -0,0 +1,38 @@
+This package was debianized by Christopher L Cheney 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-2009 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/libs/libtheora-1.1/debian/libtheora-dev.install b/libs/libtheora-1.1/debian/libtheora-dev.install
new file mode 100644
index 00000000..adab6bc8
--- /dev/null
+++ b/libs/libtheora-1.1/debian/libtheora-dev.install
@@ -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/libs/libtheora-1.1/debian/libtheora0.install b/libs/libtheora-1.1/debian/libtheora0.install
new file mode 100644
index 00000000..cac5198b
--- /dev/null
+++ b/libs/libtheora-1.1/debian/libtheora0.install
@@ -0,0 +1,2 @@
+debian/tmp/usr/lib/libtheora.so.0
+debian/tmp/usr/lib/libtheora.so.0.0.0
diff --git a/libs/libtheora-1.1/debian/rules b/libs/libtheora-1.1/debian/rules
new file mode 100644
index 00000000..4b0564ec
--- /dev/null
+++ b/libs/libtheora-1.1/debian/rules
@@ -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/libs/libtheora-1.1/debian/watch b/libs/libtheora-1.1/debian/watch
new file mode 100644
index 00000000..033083d2
--- /dev/null
+++ b/libs/libtheora-1.1/debian/watch
@@ -0,0 +1,3 @@
+version=2
+
+http://downloads.xiph.org/releases/theora/libtheora-(.*)\.tar\.gz debian uupdate
diff --git a/libs/libtheora-1.1/doc/Doxyfile.in b/libs/libtheora-1.1/doc/Doxyfile.in
new file mode 100644
index 00000000..ea155730
--- /dev/null
+++ b/libs/libtheora-1.1/doc/Doxyfile.in
@@ -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).
+#This tag is now obsolete, according to doxygen 1.5.2
+#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 = YES
+
+# 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 , where
+# is the value of the INPUT_FILTER tag, and 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.
+#This tag is now obsolete, according to doxygen 1.5.2
+#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.
+#This tag is now obsolete, according to doxygen 1.5.2
+#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.
+#This tag is now obsolete, according to doxygen 1.5.2
+#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/libs/libtheora-1.1/doc/Makefile.am b/libs/libtheora-1.1/doc/Makefile.am
new file mode 100644
index 00000000..783bd015
--- /dev/null
+++ b/libs/libtheora-1.1/doc/Makefile.am
@@ -0,0 +1,72 @@
+## Process this file with automake to produce Makefile.in
+
+SUBDIRS = spec
+
+static_docs = vp3-format.txt color.html \
+ draft-ietf-avt-rtp-theora-00.xml \
+ draft-ietf-avt-rtp-theora-00.txt
+
+doc_DATA = $(static_docs) doxygen-build.stamp
+
+EXTRA_DIST = $(static_docs) Doxyfile.in
+
+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/libs/libtheora-1.1/doc/color.html b/libs/libtheora-1.1/doc/color.html
new file mode 100644
index 00000000..ad7d90cd
--- /dev/null
+++ b/libs/libtheora-1.1/doc/color.html
@@ -0,0 +1,602 @@
+
+xiph.org: Ogg Theora documentation
+
+
+Ogg Theora I specification: color space conventions
+
+
Overview
+
+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.
+
+
+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'CbCr 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.
+
+
color space parameters
+
+The parameters which describe each color space are listed below.
+These are the parameters needed to map colors from the encoded
+ Y'CbCr representation to the device-independent color
+ space CIE XYZ (1931).
+
+
+
Y'CbCr to Y'PbPr
+
+
+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 Pb
+ and Pr.
+Because some values may fall outside the offset and excursion defined for each
+ channel in the Y'CbCr space, the results may fall
+ outside these ranges in Y'PbPr space.
+No clamping should be done at this stage.
+
+
+Parameters: OffsetY,Cb,Cr,
+ ExcursionY,Cb,Cr,
+
+
+
+
Y'out
+
=
+
+(Y'in-OffsetY)/
+ ExcursionY
+
+
+
+
Pb
+
=
+
+(Cb-OffsetCb)/
+ ExcursionCb
+
+
+
+
Pr
+
=
+
+(Cr-OffsetCr)/
+ ExcursionCr
+
+
+
+
+
Y'PbPr to R'G'B'
+
+
+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.
+
+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
+ not that used by the input device.
+Because a dim viewing environment is assumed in most television standards, the
+ overall gamma between the input and output devices is usually around 1.1 to
+ 1.2, and not a strict 1.0.
+
+
+For calibration with actual output devices, the model
+
+
+
L
+
=
+
(E'+Δ)γ
+
+
+should be used, with Δ the free parameter and γ held
+ fixed to the value specified in this document.
+The conversion function presented here is an idealized version with Δ=0.
+
+
+Parameters: γ
+
+
+
+
R
+
=
+
R'γ
+
+
+
G
+
=
+
G'γ
+
+
+
B
+
=
+
B'γ
+
+
+
+
RGB to R'G'B' (Input device gamma correction)
+
+
+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.
+
+
+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.
+
+
+Parameters: β, α, δ,
+ ε
+
+
+
+
R'
+
=
+
+(1+ε)Rβ-ε
+
+
for δ ≤ R ≤ 1
+
+
+
R'
+
=
+
αR
+
for 0 ≤ R < δ
+
+
+
G'
+
=
+
+(1+ε)Gβ-ε
+
+
for δ ≤ G ≤ 1
+
+
+
G'
+
=
+
αG
+
for 0 ≤ G < δ
+
+
+
B'
+
=
+
+(1+ε)Bβ-ε
+
+
for δ ≤ B ≤ 1
+
+
+
B'
+
=
+
αB
+
for 0 ≤ B < δ
+
+
+
+
RGB to CIE XYZ (1931)
+
+
+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.
+
+
+Parameters: xr,g,b,w, yr,g,b,w
+
+
+
+
F
+
=
+
+
(
+
+
+
xr/yr
+
xg/yg
+
xb/yb
+
+
+
1
+
1
+
1
+
+
+
+(1-xr-yr)/yr
+
+
+(1-xg-yg)/yg
+
+
+(1-xb-yb)/yb
+
+
+
+
)
+
+
+
+
+
(
+
+
sr
+
sg
+
sb
+
+
)
+
+
=
+
+
F-1(
+
+
xw/yw
+
1
+
+(1-xw-yw)/yw
+
+
+
)
+
+
+
+
+
(
+
+
X
+
Y
+
Z
+
+
)
+
+
=
+
+
F(
+
+
srR
+
sgG
+
sbB
+
+
)
+
+
+
+
+
+
available color spaces
+
+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.
+
Rec 470M (Rec. ITU-R BT.470-6 System M/NTSC with Rec. ITU-R BT.601-5)
+
+This color space is used by broadcast television and DVDs in much of the
+ Americas, Japan, Korea, and the Union of Myanmar
+ [Rec470].
+This color space may also be used for System M/PAL (Brazil), with an
+ appropriate conversion supplied by the encoder to compensate for the
+ different gamma value.
+See the Rec 470BG section for an appropriate gamma value to assume for M/PAL
+ input.
+
+
+In the US, studio monitors are adjusted to a D65 white point
+ (xw,yw=0.313,0.329).
+In Japan, studio monitors are adjusted to a D white of 9300K
+ (xw,yw=0.285,0.293).
+
+
+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 [Rec601].
+
+
+
+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)
+ [SMPTE170M].
+
+
parameters
+
+
+
OffsetY,Cb,Cr
+
=
+
(16,128,128)
+
+
+
+ExcursionY,Cb,Cr
+
+
=
+
(219,224,224)
+
+
+
Kb
+
=
+
0.114
+
+
+
Kr
+
=
+
0.299
+
+
+
γ
+
=
+
2.2
+
+
+
β
+
=
+
0.45
+
+
+
α
+
=
+
4.5
+
+
+
δ
+
=
+
0.018
+
+
+
ε
+
=
+
0.099
+
+
+
xr,yr
+
=
+
0.67,
+
0.33
+
+
+
xg,yg
+
=
+
0.21,
+
0.71
+
+
+
xb,yb
+
=
+
0.14,
+
0.08
+
+
+
+(Illuminant C) xw,yw
+
+
=
+
0.310,
+
0.316
+
+
+
+Rec 470BG (Rec. ITU-R BT.470-6 Systems B and G with Rec. ITU-R BT.601-5)
+
+
+This color space is used by the PAL and SECAM systems in much of the rest of
+ the world [Rec470].
+This can be used directly by systems (B, B1, D, D1, G, H, I, K, N)/PAL and (B,
+ D, G, H, K, K1, L)/SECAM.
+
+
+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.
+
+
+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.
+
+
+The official Rec 470BG specifies a gamma value of γ=2.8.
+However, in practice this value is unrealistically high
+ [Poy97].
+Rec 470BG states that the overall system gamma should be approximately
+ γ/β=1.2.
+However, most cameras pre-correct with a gamma value of β=0.45,
+ which suggests an output device gamma of approximately γ=2.67.
+This is the value recommended for use with PAL systems in Ogg Theora.
+
+
+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 [Rec601].
+
+
+Rec 470 does not specify an input gamma function.
+For Ogg Theora, the Rec 709 input function is used.
+
+Recommendation ITU-R BT.601-5, Studio Encoding Parameters of
+ Digital Television for Standard 4:3 and Wide-Screen 16:9 Aspect Ratios
+ (1982, revised 1995). International Telecommunications Union, 1211 Geneva 20,
+ Switzerland.
+
+Recommendation ITU-R BT.709-5, Parameter values for the
+ HDTV standards for production and international programme exchange
+ (1990, revised 2002). International Telecommunications Union, 1211 Geneva 20,
+ Switzerland.
+
+Society of Motion Picture and Television Engineers, Television —
+ Signal Parameters — 1125-Line High-Definition Production.
+ SMPTE-240M, 1999.
+
+
+
+
diff --git a/libs/libtheora-1.1/doc/draft-ietf-avt-rtp-theora-00.txt b/libs/libtheora-1.1/doc/draft-ietf-avt-rtp-theora-00.txt
new file mode 100644
index 00000000..f759aef6
--- /dev/null
+++ b/libs/libtheora-1.1/doc/draft-ietf-avt-rtp-theora-00.txt
@@ -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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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:
+ IETF Audio/Video Transport Working Group
+
+
+
+
+
+Barbato Expires January 22, 2007 [Page 12]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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:
+ 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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
diff --git a/libs/libtheora-1.1/doc/draft-ietf-avt-rtp-theora-00.xml b/libs/libtheora-1.1/doc/draft-ietf-avt-rtp-theora-00.xml
new file mode 100644
index 00000000..2f8af399
--- /dev/null
+++ b/libs/libtheora-1.1/doc/draft-ietf-avt-rtp-theora-00.xml
@@ -0,0 +1,1146 @@
+
+
+
+
+
+
+
+
+draft-ietf-avt-rtp-theora-00
+
+
+Xiph.Org
+
+lu_zero@gentoo.org
+http://www.xiph.org/
+
+
+
+
+General
+AVT Working Group
+I-D
+
+Internet-Draft
+Theora
+RTP
+
+
+
+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).
+
+
+
+
+
+
+All references to RFC XXXX are to be replaced by references to the RFC number of this memo, when published.
+
+
+
+
+
+
+
+
+
+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 or RTP/AVP .
+
+
+
+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 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.
+
+
+
+
+
+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 .
+
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+The format of the RTP header is specified in and shown in Figure 1. This payload format uses the fields of the header in a manner consistent with that specification.
+
+
+
+
+
+
+
+The RTP header begins with an octet of fields (V, P, X, and CC) to support specialized RTP uses (see and 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 .
+
+
+
+Extension (X): 1 bit
+The Extension bit is used in accordance with .
+
+
+
+CSRC count (CC): 4 bits
+The CSRC count is used in accordance with .
+
+
+
+Marker (M): 1 bit
+The Marker bit is used in accordance with .
+
+
+
+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 .
+
+
+
+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 .
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+Here is an example RTP packet containing two Theora packets.
+
+
+RTP Packet Header:
+
+
+
+
+
+
+
+
+Payload Data:
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+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 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 Packed Configuration in the SDP as explained in the IANA considerations
+
+
+
+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.
+
+
+
+
+
+
+The Packed Configuration 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.
+
+
+
+
+
+A Theora Packed Configuration is identified by a payload type field of 1. Of the three headers, defined in the Theora I specification, 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.
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+The key difference from the in-band format is that there is no need for the payload header octet.
+
+
+
+
+
+The following IANA considerations MUST only be applied to the packed headers.
+
+
+
+
+
+ video
+
+
+
+ theora-config
+
+
+
+
+
+None
+
+
+
+
+
+
+None
+
+
+
+
+
+
+This media type contains binary data.
+
+
+
+
+
+
+See Section 6 of RFC XXXX.
+
+
+
+
+
+
+None
+
+
+
+
+
+
+RFC XXXX [RFC Editor: please replace by the RFC number of this memo,
+ when published]
+
+
+
+
+
+
+Theora encoded video, configuration data.
+
+
+
+
+
+
+None
+
+
+
+
+
+
+Luca Barbato: <lu_zero@gentoo.org>
+
+IETF Audio/Video Transport Working Group
+
+
+
+
+
+COMMON
+
+
+
+
+
+
+This media type does not depend on the transport.
+
+
+
+
+
+
+Luca Barbato
+
+
+
+
+
+IETF AVT Working Group
+
+
+
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+The 2 byte length field is necessary since this Theora packet could be fragmented.
+
+
+
+
+
+
+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 and .
+
+
+
+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.
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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, , 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 Configuration Headers section.
+
+
+
+
+
+
+
+
+
+
+ video
+
+
+
+ theora
+
+
+
+
+
+
+
+
+
+ Determines the chroma subsampling format.
+
+
+
+
+ Determines the number of pixels per line. This is an integer between 1 and 1048561 and MUST be in multiples of 16.
+
+
+
+
+Determines the number of lines per frame encoded. This is an integer between 1 and 1048561 and MUST be in multiples of 16.
+
+
+
+
+ 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.
+
+
+
+
+ the base16 (hexadecimal) representation of the Packed Headers.
+
+
+
+
+
+
+
+
+
+
+
+ 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 or bzip2 and an sha1 checksum MAY be provided in the form of "protocol://path/to/resource/aggregated.bz2!sha1hash"
+
+
+
+
+
+
+
+This media type is framed and contains binary data.
+
+
+
+
+
+
+See Section 6 of RFC XXXX.
+
+
+
+
+
+None
+
+
+
+
+
+
+
+ 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
+
+
+
+
+
+
+
+Video streaming and conferencing tools
+
+
+
+
+
+None
+
+
+
+
+
+
+
+Luca Barbato: <lu_zero@gentoo.org>
+IETF Audio/Video Transport Working Group
+
+
+
+
+
+
+
+COMMON
+
+
+
+
+
+This media type depends on RTP framing, and hence is only defined for transfer via RTP
+
+
+
+
+Luca Barbato
+
+
+
+ IETF AVT Working Group
+
+
+
+
+
+
+
+
+The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) , which is commonly used to describe RTP sessions. When SDP is used to specify sessions the mapping are as follows:
+
+
+
+
+
+The MIME type ("video") goes in SDP "m=" as the media name.
+
+
+The MIME subtype ("theora") goes in SDP "a=rtpmap" as the encoding name.
+
+
+The clock rate in the "a=rtpmap" line MUST be 90000
+
+
+The mandated parameters "delivery-method" and "configuration" MUST be included in the SDP "a=fmpt" attribute.
+
+
+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.
+
+
+
+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 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;
+
+
+
+
+
+
+
+
+The offer, as described in An Offer/Answer Model Session Description Protocol, 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.
+
+
+
+
+
+
+
+
+
+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.
+
+
+
+
+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, 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.
+
+
+
+
+
+
+
+RTP packets using this payload format are subject to the security considerations discussed in the RTP specification . 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.
+
+
+
+
+
+
+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)³/IMG Group in particular Federico Ridolfo, Francesco Varano, Giampaolo Mancini, Juan Carlos De Martin.
+
+
+
+
+
+
+
+
+
+
+
+
+The Ogg Encapsulation Format Version 0
+
+
+
+
+
+
+
+Key words for use in RFCs to Indicate Requirement Levels
+
+
+
+
+
+
+
+RTP: A Transport Protocol for real-time applications
+
+
+
+
+
+
+
+
+
+
+RTP Profile for video and Video Conferences with Minimal Control.
+
+
+
+
+
+
+
+
+
+An Offer/Answer Model with Session Description Protocol (SDP)
+
+
+
+
+
+
+
+
+SDP: Session Description Protocol
+
+
+
+
+
+
+
+
+Path MTU Discovery
+
+
+
+
+
+
+
+Path MTU Discovery for IP version 6
+
+
+
+
+
+
+
+Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)
+
+
+
+
+
+
+
+
+
+
+
+RTP Payload Format for Vorbis Encoded Audio - draft-ietf-avt-vorbis-rtp-00
+
+
+
+
+
+
+
+The Base16, Base32, and Base64 Data Encodings
+
+
+
+
+
+
+
+GZIP file format specification version 4.3
+
+
+
+
+
+
+
+Secure Hash Standard
+
+National Institute of Standards and Technology
+
+
+
+
+
+
+
+libbz2 and bzip2
+
+
+
+
+
+
+
+
+
+libTheora: Available from the Xiph website, http://www.xiph.org
+
+
+
+
+
+Theora I specification: Codec setup and packet decode. http://www.xiph.org/theora/doc/Theora_I_spec.pdf
+
+
+
+
+
+
+RTP Control Protocol Extended Reports (RTCP XR)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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
+
+
+
+
+
+
+ISO 3309, October 1984, 3rd Edition. Information Processing Systems--Data Communication High-Level Data Link Control Procedure--Frame Structure. International Organization for Standardization.
+
+
+
+
+
+
diff --git a/libs/libtheora-1.1/doc/draft-kerr-avt-theora-rtp-00.txt b/libs/libtheora-1.1/doc/draft-kerr-avt-theora-rtp-00.txt
new file mode 100644
index 00000000..51261521
--- /dev/null
+++ b/libs/libtheora-1.1/doc/draft-kerr-avt-theora-rtp-00.txt
@@ -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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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:
+
+ 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]
+
+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]
+
+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:
+
+ 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=
+
+
+
+
+
+Kerr Expires August 1, 2005 [Page 24]
+
+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]
+
+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]
+
+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]
+
diff --git a/libs/libtheora-1.1/doc/draft-kerr-avt-theora-rtp-00.xml b/libs/libtheora-1.1/doc/draft-kerr-avt-theora-rtp-00.xml
new file mode 100644
index 00000000..dff7a265
--- /dev/null
+++ b/libs/libtheora-1.1/doc/draft-kerr-avt-theora-rtp-00.xml
@@ -0,0 +1,1277 @@
+
+
+
+
+
+
+
+
+draft-kerr-avt-theora-rtp-00
+
+
+Xiph.Org
+
+phil@plus24.com
+http://www.xiph.org/
+
+
+
+
+
+General
+AVT Working Group
+I-D
+
+Internet-Draft
+Theora
+RTP
+
+
+
+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).
+
+
+
+
+
+
+All references to RFC XXXX are to be replaced by references to the RFC number of this memo, when published.
+
+
+
+
+
+
+
+
+
+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 . or RTP/AVP .
+
+
+
+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 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.
+
+
+
+
+
+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 .
+
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+The format of the RTP header is specified in and shown in Figure 1. This payload format uses
+the fields of the header in a manner consistent with that specification.
+
+
+
+
+
+
+
+The RTP header begins with an octet of fields (V, P, X, and CC) to support specialized RTP uses (see
+ and 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 .
+
+
+
+Extension (X): 1 bit
+The Extension bit is used in accordance with .
+
+
+
+CSRC count (CC): 4 bits
+The CSRC count is used in accordance with .
+
+
+
+Marker (M): 1 bit
+The Marker bit is used in accordance with .
+
+
+
+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 .
+
+
+
+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
+.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+Here is an example RTP packet containing two Theora packets.
+
+
+RTP Packet Header:
+
+
+
+
+
+
+
+
+Payload Data:
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+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).
+
+
+
+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 and .
+
+
+
+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.
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+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,
+, in the event of packet loss from a large number of participants.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+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.
+
+
+
+
+
+The Identification Header is a short header with only a few fields used to declare the stream definitively as Theora and provide detailed information about the format of the fully decoded video data.
+
+
+
+
+
+
+The fields listed above have the following meanings:
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+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.
+
+
+= 0; loop--) {
+ mask = -(crc & 1);
+ crc = (crc >> 1) ^ (0xEDB88320 & mask);
+ }
+ index++;
+ }
+ return ~crc;
+}
+]]>
+
+
+
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+The alignment of the packed Identification Header is slightly different from the RTP payload type as the payload header is not
+used.
+
+
+
+
+
+
+
+The packed Comment Header also as a slightly different structure to that of the RTP payload type with the payload header not being
+used.
+
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+The following IANA considerations MUST only be applied to the packed headers.
+
+
+
+MIME media type name: video
+
+
+MIME subtype: theora-config
+
+
+
+Required Parameters:
+None.
+
+
+
+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
+
+
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+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.
+
+
+
+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.
+
+
+
+
+
+
+
+
+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 for details.
+
+
+Applications which use this media type:
+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
+
+
+
+
+The information carried in the MIME media type specification has a specific mapping to fields in the Session Description
+Protocol (SDP) , which is commonly used to describe RTP sessions. When SDP is used to specify
+sessions the mapping are as follows:
+
+
+
+
+
+The MIME type ("video") goes in SDP "m=" as the media name.
+
+
+The MIME subtype ("THEORA") goes in SDP "a=rtpmap" as the encoding name.
+
+
+The parameter "rate" also goes in "a=rtpmap" as clock rate.
+
+
+The parameter "channels" also goes in "a=rtpmap" as channel count.
+
+
+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>
+
+
+
+
+
+
+
+
+
+
+RTP packets using this payload format are subject to the security considerations discussed in the RTP specification
+. 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.
+
+
+
+
+
+
+
+Thanks to the AVT, Ogg Theora Communities / Xiph.org, Fluendo, Ralph Giles.
+
+
+
+
+
+
+
+
+
+
+
+
+The Ogg Encapsulation Format Version 0
+
+
+
+
+
+
+
+Key words for use in RFCs to Indicate Requirement Levels
+
+
+
+
+
+
+
+RTP: A Transport Protocol for real-time applications
+
+
+
+
+
+
+
+
+
+
+RTP Profile for video and Video Conferences with Minimal Control.
+
+
+
+
+
+
+
+
+
+SDP: Session Description Protocol
+
+
+
+
+
+
+
+
+Path MTU Discovery
+
+
+
+
+
+
+
+Path MTU Discovery for IP version 6
+
+
+
+
+
+
+
+Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)
+
+
+
+
+
+
+
+
+
+
+
+RTP Payload Format for Vorbis Encoded Audio - draft-ietf-avt-vorbis-rtp-00
+
+
+
+
+
+
+
+
+
+
+
+libTheora: Available from the Xiph website, http://www.xiph.org
+
+
+
+
+
+Ogg Theora I spec: Codec setup and packet decode. http://www.xiph.org/ogg/Theora/doc/Theora-spec-ref.html
+
+
+
+
+
+
+
diff --git a/libs/libtheora-1.1/doc/spec/Makefile.am b/libs/libtheora-1.1/doc/spec/Makefile.am
new file mode 100644
index 00000000..ee1fb902
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/Makefile.am
@@ -0,0 +1,81 @@
+## Process this file with automake to produce Makefile.in
+
+# makefile to generate the spec document from sources
+# requires transfig and pdflatex
+
+built_docs = Theora.pdf
+
+if BUILD_SPEC
+doc_DATA = $(built_docs)
+endif
+
+SPEC_SRCS = spec.tex spec.bib
+
+FIG_SRCS = pic-frame.fig hilbert-mb.fig hilbert-block.fig xifish.fig \
+ superblock.fig macroblock.fig raster-block.fig reference-frames.fig \
+ pixel444.fig pixel422.fig pixel420.fig idct.fig fdct.fig \
+ pic_even.fig pic_even_odd.fig pic_odd.fig pic_odd_even.fig \
+ lflim.fig
+
+FIG_TEXS = $(FIG_SRCS:.fig=.tex)
+FIG_AUXS = $(FIG_SRCS:.fig=.aux)
+FIG_PDFS = $(FIG_SRCS:.fig=.pdf)
+
+# add any native-pdf figures here
+FIG_OBJS = $(FIG_PDFS)
+
+EXTRA_DIST = $(built_docs) $(SPEC_SRCS) $(FIG_SRCS) ltablex.sty
+
+if BUILD_SPEC
+# latex three times is the charm with references
+# long tables require the .aux file to start from scratch
+Theora.pdf : $(SPEC_SRCS) $(FIG_OBJS) vp3huff.tex
+ -$(RM) spec.aux
+ pdflatex -interaction nonstopmode spec.tex
+ bibtex spec.aux
+ pdflatex -interaction nonstopmode spec.tex
+ pdflatex -interaction nonstopmode spec.tex
+ mv spec.pdf $@
+else
+Theora.pdf :
+ echo "*** Warning: Missing tools; $@ will not be built."
+endif
+
+vp3huff.tex : vp3huff
+ ./vp3huff > $@
+
+noinst_PROGRAMS = vp3huff
+vp3huff_SOURCES = vp3huff.c
+
+figures : $(FIG_OBJS)
+
+# rules to generate latex and pdf versions of the xfig figures
+.fig.tex:
+ fig2dev -L latex $< $@
+
+.fig.pdf:
+ fig2dev -L pdf -p 0 $< $@
+
+SUFFIXES = .fig .tex .pdf
+
+# clean targets
+clean-local:
+ -$(RM) $(FIG_TEXS)
+ -$(RM) $(FIG_AUXS)
+ -$(RM) $(FIG_PDFS)
+ -$(RM) vp3huff
+ -$(RM) vp3huff.tex
+ -$(RM) vp3huff.aux
+ -$(RM) spec.aux
+ -$(RM) spec.log
+ -$(RM) spec.lof
+ -$(RM) spec.lot
+ -$(RM) spec.out
+ -$(RM) spec.bbl
+ -$(RM) spec.blg
+ -$(RM) spec.toc
+
+maintainer-clean-local:
+ -$(RM) $(built_docs)
+
+maintainerclean: maintainer-clean
diff --git a/libs/libtheora-1.1/doc/spec/fdct.fig b/libs/libtheora-1.1/doc/spec/fdct.fig
new file mode 100644
index 00000000..e35c758c
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/fdct.fig
@@ -0,0 +1,371 @@
+#FIG 3.2
+Landscape
+Center
+Inches
+Letter
+100.00
+Single
+-2
+1200 2
+6 1350 4650 1650 4950
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 1500 4800 75 75 1500 4800 1500 4725
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 1450 4800 1550 4800
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 1500 4850 1500 4750
+-6
+6 1350 450 1650 750
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 1500 600 75 75 1500 600 1500 525
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 1450 600 1550 600
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 1500 650 1500 550
+-6
+6 1950 1050 2250 1350
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 2100 1200 75 75 2100 1200 2100 1125
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2050 1200 2150 1200
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2100 1250 2100 1150
+-6
+6 3150 2850 3450 3150
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 3300 3000 75 75 3300 3000 3300 2925
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 3250 3000 3350 3000
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 3300 3050 3300 2950
+-6
+6 3150 2250 3450 2550
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 3300 2400 75 75 3300 2400 3300 2325
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 3250 2400 3350 2400
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 3300 2450 3300 2350
+-6
+6 2550 3450 2850 3750
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 2700 3600 75 75 2700 3600 2700 3525
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2650 3600 2750 3600
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2700 3650 2700 3550
+-6
+6 2550 1650 2850 1950
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 2700 1800 75 75 2700 1800 2700 1725
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2650 1800 2750 1800
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2700 1850 2700 1750
+-6
+6 1950 4050 2250 4350
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 2100 4200 75 75 2100 4200 2100 4125
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2050 4200 2150 4200
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2100 4250 2100 4150
+-6
+6 2250 3600 2550 3900
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 2400 3750 75 75 2400 3750 2400 3675
+4 1 0 40 -1 0 12 0.0000 4 15 60 2400 3800 -\001
+-6
+6 1650 4200 1950 4500
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 1800 4350 75 75 1800 4350 1800 4275
+4 1 0 40 -1 0 12 0.0000 4 15 60 1800 4400 -\001
+-6
+6 1050 4800 1350 5100
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 1200 4950 75 75 1200 4950 1200 4875
+4 1 0 40 -1 0 12 0.0000 4 15 60 1200 5000 -\001
+-6
+6 2850 3000 3150 3300
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 3000 3150 75 75 3000 3150 3000 3075
+4 1 0 40 -1 0 12 0.0000 4 15 60 3000 3200 -\001
+-6
+6 4350 4050 4650 4350
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 4500 4200 75 75 4500 4200 4500 4125
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 4450 4200 4550 4200
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 4500 4250 4500 4150
+-6
+6 4350 3450 4650 3750
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 4500 3600 75 75 4500 3600 4500 3525
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 4450 3600 4550 3600
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 4500 3650 4500 3550
+-6
+6 4050 3300 4350 3600
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 4200 3450 75 75 4200 3450 4200 3375
+4 1 0 40 -1 0 12 0.0000 4 15 60 4200 3500 -\001
+-6
+6 4350 2250 4650 2550
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 4500 2400 75 75 4500 2400 4500 2325
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 4450 2400 4550 2400
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 4500 2450 4500 2350
+-6
+6 4350 450 4650 750
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 4500 600 75 75 4500 600 4500 525
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 4450 600 4550 600
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 4500 650 4500 550
+-6
+6 4050 2400 4350 2700
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 4200 2550 75 75 4200 2550 4200 2475
+4 1 0 40 -1 0 12 0.0000 4 15 60 4200 2600 -\001
+-6
+6 4950 1050 5250 1350
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 5100 1200 75 75 5100 1200 5100 1125
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 5050 1200 5150 1200
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 5100 1250 5100 1150
+-6
+6 4950 1650 5250 1950
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 5100 1800 75 75 5100 1800 5100 1725
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 5050 1800 5150 1800
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 5100 1850 5100 1750
+-6
+6 4650 1800 4950 2100
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 4800 1950 75 75 4800 1950 4800 1875
+4 1 0 40 -1 0 12 0.0000 4 15 60 4800 2000 -\001
+-6
+6 4725 3525 4875 4275
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 4800 4200 25 25 4800 4200 4800 4175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 4800 3600 25 25 4800 3600 4800 3575
+-6
+6 6150 4650 6450 4950
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6300 4800 75 75 6300 4800 6300 4725
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6250 4800 6350 4800
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6300 4850 6300 4750
+-6
+6 6150 4050 6450 4350
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6300 4200 75 75 6300 4200 6300 4125
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6250 4200 6350 4200
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6300 4250 6300 4150
+-6
+6 5850 3900 6150 4200
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6000 4050 75 75 6000 4050 6000 3975
+4 1 0 40 -1 0 12 0.0000 4 15 60 6000 4100 -\001
+-6
+6 6150 2850 6450 3150
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6300 3000 75 75 6300 3000 6300 2925
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6250 3000 6350 3000
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6300 3050 6300 2950
+-6
+6 6150 3450 6450 3750
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6300 3600 75 75 6300 3600 6300 3525
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6250 3600 6350 3600
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6300 3650 6300 3550
+-6
+6 5850 3600 6150 3900
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6000 3750 75 75 6000 3750 6000 3675
+4 1 0 40 -1 0 12 0.0000 4 15 60 6000 3800 -\001
+-6
+6 6150 1050 6450 1350
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6300 1200 75 75 6300 1200 6300 1125
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6250 1200 6350 1200
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6300 1250 6300 1150
+-6
+6 6150 450 6450 750
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6300 600 75 75 6300 600 6300 525
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6250 600 6350 600
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6300 650 6300 550
+-6
+6 6150 2250 6450 2550
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6300 2400 75 75 6300 2400 6300 2325
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6250 2400 6350 2400
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6300 2450 6300 2350
+-6
+6 6150 1650 6450 1950
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6300 1800 75 75 6300 1800 6300 1725
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6250 1800 6350 1800
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6300 1850 6300 1750
+-6
+6 5850 1200 6150 1500
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6000 1350 75 75 6000 1350 6000 1275
+4 1 0 40 -1 0 12 0.0000 4 15 60 6000 1400 -\001
+-6
+6 7350 4650 7650 4950
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 7500 4800 75 75 7500 4800 7500 4725
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 7450 4800 7550 4800
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 7500 4850 7500 4750
+-6
+6 7350 2850 7650 3150
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 7500 3000 75 75 7500 3000 7500 2925
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 7450 3000 7550 3000
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 7500 3050 7500 2950
+-6
+6 7950 4050 8250 4350
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 8100 4200 75 75 8100 4200 8100 4125
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 8050 4200 8150 4200
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 8100 4250 8100 4150
+-6
+6 7950 3450 8250 3750
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 8100 3600 75 75 8100 3600 8100 3525
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 8050 3600 8150 3600
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 8100 3650 8100 3550
+-6
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 900 4800 25 25 900 4800 900 4775
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 900 600 25 25 900 600 900 575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 1500 1200 25 25 1500 1200 1500 1175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 2700 3000 25 25 2700 3000 2700 2975
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 2700 2400 25 25 2700 2400 2700 2375
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 2100 3600 25 25 2100 3600 2100 3575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 1500 4200 25 25 1500 4200 1500 4175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 3900 4200 25 25 3900 4200 3900 4175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 3900 3600 25 25 3900 3600 3900 3575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 3900 2400 25 25 3900 2400 3900 2375
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 3900 600 25 25 3900 600 3900 575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 4500 1200 25 25 4500 1200 4500 1175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 4500 1800 25 25 4500 1800 4500 1775
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 5700 4800 25 25 5700 4800 5700 4775
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 5700 4200 25 25 5700 4200 5700 4175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 5700 3600 25 25 5700 3600 5700 3575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 5700 3000 25 25 5700 3000 5700 2975
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 5700 1200 25 25 5700 1200 5700 1175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 5700 600 25 25 5700 600 5700 575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 5700 2400 25 25 5700 2400 5700 2375
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 5725 1800 25 25 5725 1800 5725 1775
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 6900 4800 25 25 6900 4800 6900 4775
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 6900 3000 25 25 6900 3000 6900 2975
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 7500 4200 25 25 7500 4200 7500 4175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 7500 3600 25 25 7500 3600 7500 3575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 7500 1200 25 25 7500 1200 7500 1175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 7500 600 25 25 7500 600 7500 575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 2100 1800 25 25 2100 1800 2100 1775
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 600 8400 600
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 2400 8400 2400
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 3000 8400 3000
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 4800 8400 4800
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 1200 8400 1200
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 3600 8400 3600
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 1800 8400 1800
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 4200 8400 4200
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 900 4800 1500 600
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 900 600 1500 4800
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 1500 1200 2100 4275
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 1500 4200 2100 1200
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 2100 3600 2700 1800
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 2700 2400 3300 3000
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 2100 1800 2700 3600
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 2700 3000 3300 2400
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 3900 3600 4500 4200
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 3900 4200 4500 3600
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 3900 600 4500 2400
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 3900 2400 4500 600
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 4500 1800 5100 1200
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 4500 1200 5100 1800
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 5700 4200 6300 4800
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 5700 3600 6300 3000
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 5700 3000 6300 3600
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 5700 4800 6300 4200
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5700 1200 6300 600
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5700 600 6300 1200
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5700 1800 6300 2400
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 5700 2400 6300 1800
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 6900 3000 7500 4800
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 6900 4800 7500 3000
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 7500 4200 8100 3600
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 7500 3600 8100 4200
+4 1 0 40 -1 0 12 0.0000 4 135 210 4800 4125 C4\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 4800 3525 C4\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 6000 2350 C6\001
+4 1 0 40 -1 0 12 0.0000 4 135 255 6300 2275 -S6\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 6000 1750 C6\001
+4 1 0 40 -1 0 12 0.0000 4 135 195 6300 2050 S6\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 7200 2950 C7\001
+4 1 0 40 -1 0 12 0.0000 4 135 195 7500 3375 S7\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 7200 4750 C7\001
+4 1 0 40 -1 0 12 0.0000 4 135 255 7500 4575 -S7\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 7800 4150 C3\001
+4 1 0 40 -1 0 12 0.0000 4 135 255 8100 4075 -S3\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 7800 3550 C3\001
+4 1 0 40 -1 0 12 0.0000 4 135 195 8100 3850 S3\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 7500 1125 C4\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 7500 525 C4\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 8700 675 0\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 8700 1275 4\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 8700 1875 2\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 8700 2475 6\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 8700 3675 5\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 8700 4275 3\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 8700 4875 7\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 8700 3075 1\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 300 675 0\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 300 1275 1\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 300 1875 2\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 300 2475 3\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 300 3075 4\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 300 3675 5\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 300 4275 6\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 300 4875 7\001
diff --git a/libs/libtheora-1.1/doc/spec/hilbert-block.fig b/libs/libtheora-1.1/doc/spec/hilbert-block.fig
new file mode 100644
index 00000000..8316c5d1
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/hilbert-block.fig
@@ -0,0 +1,104 @@
+#FIG 3.2 Produced by xfig version 3.2.5-alpha4
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+6 675 645 3825 3795
+4 1 0 50 0 1 12 0.0000 0 150 105 900 3660 0\001
+4 1 0 50 0 1 12 0.0000 0 150 105 1800 3660 1\001
+4 1 0 50 0 1 12 0.0000 0 150 105 1800 2760 2\001
+4 1 0 50 0 1 12 0.0000 0 150 105 900 2760 3\001
+4 1 0 50 0 1 12 0.0000 0 150 105 900 1860 4\001
+4 1 0 50 0 1 12 0.0000 0 150 105 900 960 5\001
+4 1 0 50 0 1 12 0.0000 0 150 105 1800 960 6\001
+4 1 0 50 0 1 12 0.0000 0 150 105 1800 1860 7\001
+4 1 0 50 0 1 12 0.0000 0 150 105 2700 1860 8\001
+4 1 0 50 0 1 12 0.0000 0 150 105 2700 960 9\001
+4 1 0 50 0 1 12 0.0000 0 150 210 3600 960 10\001
+4 1 0 50 0 1 12 0.0000 0 150 210 3600 1860 11\001
+4 1 0 50 0 1 12 0.0000 0 150 210 3600 2760 12\001
+4 1 0 50 0 1 12 0.0000 0 150 210 2700 2760 13\001
+4 1 0 50 0 1 12 0.0000 0 150 210 2700 3660 14\001
+4 1 0 50 0 1 12 0.0000 0 150 210 3600 3660 15\001
+-6
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 1125 3600 1575 3600
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 1800 3375 1800 2925
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 1575 2700 1125 2700
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 900 2475 900 2025
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 900 1575 900 1125
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 1125 900 1575 900
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 1800 1125 1800 1575
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 2025 1800 2475 1800
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 2700 1575 2700 1125
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 2925 900 3375 900
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 3600 1125 3600 1575
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 3600 2025 3600 2475
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 3375 2700 2925 2700
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 2700 2925 2700 3375
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 2925 3600 3375 3600
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 450 450 1350 450 1350 1350 450 1350 450 450
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1350 450 2250 450 2250 1350 1350 1350 1350 450
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2250 450 3150 450 3150 1350 2250 1350 2250 450
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3150 450 4050 450 4050 1350 3150 1350 3150 450
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 450 1350 1350 1350 1350 2250 450 2250 450 1350
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1350 1350 2250 1350 2250 2250 1350 2250 1350 1350
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2250 1350 3150 1350 3150 2250 2250 2250 2250 1350
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3150 1350 4050 1350 4050 2250 3150 2250 3150 1350
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 450 2250 1350 2250 1350 3150 450 3150 450 2250
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1350 2250 2250 2250 2250 3150 1350 3150 1350 2250
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2250 2250 3150 2250 3150 3150 2250 3150 2250 2250
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3150 2250 4050 2250 4050 3150 3150 3150 3150 2250
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 450 3150 1350 3150 1350 4050 450 4050 450 3150
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1350 3150 2250 3150 2250 4050 1350 4050 1350 3150
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2250 3150 3150 3150 3150 4050 2250 4050 2250 3150
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3150 3150 4050 3150 4050 4050 3150 4050 3150 3150
diff --git a/libs/libtheora-1.1/doc/spec/hilbert-mb.fig b/libs/libtheora-1.1/doc/spec/hilbert-mb.fig
new file mode 100644
index 00000000..0ed12a76
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/hilbert-mb.fig
@@ -0,0 +1,32 @@
+#FIG 3.2 Produced by xfig version 3.2.5-alpha4
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+6 810 810 1890 1890
+4 1 0 50 0 1 12 0.0000 0 150 105 900 1860 0\001
+4 1 0 50 0 1 12 0.0000 0 150 105 900 960 1\001
+4 1 0 50 0 1 12 0.0000 0 150 105 1800 960 2\001
+4 1 0 50 0 1 12 0.0000 0 150 105 1800 1860 3\001
+-6
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 900 1575 900 1125
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 1125 900 1575 900
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 1800 1125 1800 1575
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 450 450 1350 450 1350 1350 450 1350 450 450
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1350 450 2250 450 2250 1350 1350 1350 1350 450
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 450 1350 1350 1350 1350 2250 450 2250 450 1350
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1350 1350 2250 1350 2250 2250 1350 2250 1350 1350
diff --git a/libs/libtheora-1.1/doc/spec/idct.fig b/libs/libtheora-1.1/doc/spec/idct.fig
new file mode 100644
index 00000000..2d4388c4
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/idct.fig
@@ -0,0 +1,369 @@
+#FIG 3.2
+Landscape
+Center
+Inches
+Letter
+100.00
+Single
+-2
+1200 2
+6 3150 4650 3450 4950
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 3300 4800 75 75 3300 4800 3300 4725
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 3250 4800 3350 4800
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 3300 4850 3300 4750
+-6
+6 3150 4050 3450 4350
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 3300 4200 75 75 3300 4200 3300 4125
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 3250 4200 3350 4200
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 3300 4250 3300 4150
+-6
+6 2850 3900 3150 4200
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 3000 4050 75 75 3000 4050 3000 3975
+4 1 0 40 -1 0 12 0.0000 4 15 60 3000 4100 -\001
+-6
+6 3150 2850 3450 3150
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 3300 3000 75 75 3300 3000 3300 2925
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 3250 3000 3350 3000
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 3300 3050 3300 2950
+-6
+6 3150 3450 3450 3750
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 3300 3600 75 75 3300 3600 3300 3525
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 3250 3600 3350 3600
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 3300 3650 3300 3550
+-6
+6 2850 3600 3150 3900
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 3000 3750 75 75 3000 3750 3000 3675
+4 1 0 40 -1 0 12 0.0000 4 15 60 3000 3800 -\001
+-6
+6 1950 1050 2250 1350
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 2100 1200 75 75 2100 1200 2100 1125
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2050 1200 2150 1200
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2100 1250 2100 1150
+-6
+6 1950 450 2250 750
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 2100 600 75 75 2100 600 2100 525
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2050 600 2150 600
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2100 650 2100 550
+-6
+6 1950 2250 2250 2550
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 2100 2400 75 75 2100 2400 2100 2325
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2050 2400 2150 2400
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2100 2450 2100 2350
+-6
+6 1950 1650 2250 1950
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 2100 1800 75 75 2100 1800 2100 1725
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2050 1800 2150 1800
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2100 1850 2100 1750
+-6
+6 1650 1200 1950 1500
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 1800 1350 75 75 1800 1350 1800 1275
+4 1 0 40 -1 0 12 0.0000 4 15 60 1800 1400 -\001
+-6
+6 6150 4650 6450 4950
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6300 4800 75 75 6300 4800 6300 4725
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6250 4800 6350 4800
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6300 4850 6300 4750
+-6
+6 6150 450 6450 750
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6300 600 75 75 6300 600 6300 525
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6250 600 6350 600
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6300 650 6300 550
+-6
+6 6750 1050 7050 1350
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6900 1200 75 75 6900 1200 6900 1125
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6850 1200 6950 1200
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6900 1250 6900 1150
+-6
+6 7950 2850 8250 3150
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 8100 3000 75 75 8100 3000 8100 2925
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 8050 3000 8150 3000
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 8100 3050 8100 2950
+-6
+6 7950 2250 8250 2550
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 8100 2400 75 75 8100 2400 8100 2325
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 8050 2400 8150 2400
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 8100 2450 8100 2350
+-6
+6 7350 3450 7650 3750
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 7500 3600 75 75 7500 3600 7500 3525
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 7450 3600 7550 3600
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 7500 3650 7500 3550
+-6
+6 7350 1650 7650 1950
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 7500 1800 75 75 7500 1800 7500 1725
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 7450 1800 7550 1800
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 7500 1850 7500 1750
+-6
+6 6750 4050 7050 4350
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6900 4200 75 75 6900 4200 6900 4125
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6850 4200 6950 4200
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 6900 4250 6900 4150
+-6
+6 7050 3600 7350 3900
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 7200 3750 75 75 7200 3750 7200 3675
+4 1 0 40 -1 0 12 0.0000 4 15 60 7200 3800 -\001
+-6
+6 6450 4200 6750 4500
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6600 4350 75 75 6600 4350 6600 4275
+4 1 0 40 -1 0 12 0.0000 4 15 60 6600 4400 -\001
+-6
+6 5850 4800 6150 5100
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 6000 4950 75 75 6000 4950 6000 4875
+4 1 0 40 -1 0 12 0.0000 4 15 60 6000 5000 -\001
+-6
+6 7650 3000 7950 3300
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 7800 3150 75 75 7800 3150 7800 3075
+4 1 0 40 -1 0 12 0.0000 4 15 60 7800 3200 -\001
+-6
+6 4950 4050 5250 4350
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 5100 4200 75 75 5100 4200 5100 4125
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 5050 4200 5150 4200
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 5100 4250 5100 4150
+-6
+6 4950 3450 5250 3750
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 5100 3600 75 75 5100 3600 5100 3525
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 5050 3600 5150 3600
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 5100 3650 5100 3550
+-6
+6 4650 3300 4950 3600
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 4800 3450 75 75 4800 3450 4800 3375
+4 1 0 40 -1 0 12 0.0000 4 15 60 4800 3500 -\001
+-6
+6 4350 2250 4650 2550
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 4500 2400 75 75 4500 2400 4500 2325
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 4450 2400 4550 2400
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 4500 2450 4500 2350
+-6
+6 4350 450 4650 750
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 4500 600 75 75 4500 600 4500 525
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 4450 600 4550 600
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 4500 650 4500 550
+-6
+6 4050 2400 4350 2700
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 4200 2550 75 75 4200 2550 4200 2475
+4 1 0 40 -1 0 12 0.0000 4 15 60 4200 2600 -\001
+-6
+6 4950 1050 5250 1350
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 5100 1200 75 75 5100 1200 5100 1125
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 5050 1200 5150 1200
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 5100 1250 5100 1150
+-6
+6 4950 1650 5250 1950
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 5100 1800 75 75 5100 1800 5100 1725
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 5050 1800 5150 1800
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 5100 1850 5100 1750
+-6
+6 1950 4050 2250 4350
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 2100 4200 75 75 2100 4200 2100 4125
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2050 4200 2150 4200
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2100 4250 2100 4150
+-6
+6 1950 3450 2250 3750
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 2100 3600 75 75 2100 3600 2100 3525
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2050 3600 2150 3600
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 2100 3650 2100 3550
+-6
+6 1350 4650 1650 4950
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 1500 4800 75 75 1500 4800 1500 4725
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 1450 4800 1550 4800
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 1500 4850 1500 4750
+-6
+6 1350 2850 1650 3150
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 1500 3000 75 75 1500 3000 1500 2925
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 1450 3000 1550 3000
+2 1 0 1 0 7 40 -1 20 4.000 0 0 7 0 0 2
+ 1500 3050 1500 2950
+-6
+6 4650 1800 4950 2100
+1 3 0 1 0 7 40 -1 20 4.000 1 0.0000 4800 1950 75 75 4800 1950 4800 1875
+4 1 0 40 -1 0 12 0.0000 4 15 60 4800 2000 -\001
+-6
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 2700 4800 25 25 2700 4800 2700 4775
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 2700 4200 25 25 2700 4200 2700 4175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 2700 3600 25 25 2700 3600 2700 3575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 2700 3000 25 25 2700 3000 2700 2975
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 1500 1200 25 25 1500 1200 1500 1175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 1500 600 25 25 1500 600 1500 575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 1500 2400 25 25 1500 2400 1500 2375
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 1525 1800 25 25 1525 1800 1525 1775
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 3000 1200 25 25 3000 1200 3000 1175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 3000 600 25 25 3000 600 3000 575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 5700 4800 25 25 5700 4800 5700 4775
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 5700 600 25 25 5700 600 5700 575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 6300 1200 25 25 6300 1200 6300 1175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 7500 3000 25 25 7500 3000 7500 2975
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 7500 2400 25 25 7500 2400 7500 2375
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 6900 3600 25 25 6900 3600 6900 3575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 6300 4200 25 25 6300 4200 6300 4175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 4500 4200 25 25 4500 4200 4500 4175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 4500 3600 25 25 4500 3600 4500 3575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 4200 4200 25 25 4200 4200 4200 4175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 4200 3600 25 25 4200 3600 4200 3575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 6900 1800 25 25 6900 1800 6900 1775
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 3900 2400 25 25 3900 2400 3900 2375
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 3900 600 25 25 3900 600 3900 575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 1500 4200 25 25 1500 4200 1500 4175
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 1500 3600 25 25 1500 3600 1500 3575
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 900 4800 25 25 900 4800 900 4775
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 900 3000 25 25 900 3000 900 2975
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 4500 1800 25 25 4500 1800 4500 1775
+1 3 0 1 0 0 40 -1 20 4.000 1 0.0000 4500 1200 25 25 4500 1200 4500 1175
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 600 8400 600
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 2400 8400 2400
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 3000 8400 3000
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 4800 8400 4800
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 1200 8400 1200
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 2700 4200 3300 4800
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 2700 3600 3300 3000
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 2700 3000 3300 3600
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 3600 8400 3600
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 2700 4800 3300 4200
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 1800 8400 1800
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 4200 8400 4200
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1500 1200 2100 600
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1500 600 2100 1200
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1500 1800 2100 2400
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2
+ 1500 2400 2100 1800
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 5700 4800 6300 600
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 5700 600 6300 4800
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 6300 1200 6900 4275
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 6300 4200 6900 1200
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 6900 3600 7500 1800
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 7500 2400 8100 3000
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 6900 1800 7500 3600
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 7500 3000 8100 2400
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 4500 3600 5100 4200
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 4500 4200 5100 3600
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 3900 2400 4500 600
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 3900 600 4500 2400
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 4500 1800 5100 1200
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 4500 1200 5100 1800
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 1500 4200 2100 3600
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 1500 3600 2100 4200
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 900 4800 1500 3000
+2 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
+ 900 3000 1500 4800
+4 1 0 40 -1 0 12 0.0000 4 135 90 300 675 0\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 300 1275 4\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 300 1875 2\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 300 2475 6\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 300 3675 5\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 300 4275 3\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 300 4875 7\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 300 3075 1\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 1800 2350 C6\001
+4 1 0 40 -1 0 12 0.0000 4 135 195 2100 2275 S6\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 1800 1750 C6\001
+4 1 0 40 -1 0 12 0.0000 4 135 255 2100 2050 -S6\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 3000 1125 C4\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 3000 525 C4\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 8700 675 0\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 8700 1275 1\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 8700 1875 2\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 8700 2475 3\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 8700 3075 4\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 8700 3675 5\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 8700 4275 6\001
+4 1 0 40 -1 0 12 0.0000 4 135 90 8700 4875 7\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 4200 4125 C4\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 4200 3525 C4\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 1800 4150 C3\001
+4 1 0 40 -1 0 12 0.0000 4 135 195 2100 4075 S3\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 1800 3550 C3\001
+4 1 0 40 -1 0 12 0.0000 4 135 255 2100 3850 -S3\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 1200 2950 C7\001
+4 1 0 40 -1 0 12 0.0000 4 135 255 1500 3375 -S7\001
+4 1 0 40 -1 0 12 0.0000 4 135 210 1200 4750 C7\001
+4 1 0 40 -1 0 12 0.0000 4 135 195 1500 4575 S7\001
diff --git a/libs/libtheora-1.1/doc/spec/lflim.fig b/libs/libtheora-1.1/doc/spec/lflim.fig
new file mode 100644
index 00000000..c71dc7fe
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/lflim.fig
@@ -0,0 +1,23 @@
+#FIG 3.2 Produced by xfig version 3.2.5
+Landscape
+Center
+Inches
+Letter
+100.00
+Single
+-2
+1200 2
+2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 600 2400 5400 2400
+2 1 2 1 0 7 50 -1 -1 3.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 3000 4200 3000 600
+2 1 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 6
+ 600 2400 1200 2400 2100 3300 3900 1500 4800 2400 5400 2400
+4 1 0 50 -1 1 12 0.0000 0 195 615 1200 2325 (-2L,0)\001
+4 1 0 50 -1 1 12 0.0000 0 195 600 2100 3525 (-L,-L)\001
+4 0 0 50 -1 1 12 0.0000 0 150 360 3075 825 lflim\001
+4 1 0 50 -1 1 12 0.0000 0 195 480 3900 1425 (L,L)\001
+4 1 0 50 -1 1 12 0.0000 0 195 555 4800 2625 (2L,0)\001
+4 0 0 50 -1 1 12 0.0000 0 150 135 5250 2625 R\001
diff --git a/libs/libtheora-1.1/doc/spec/ltablex.sty b/libs/libtheora-1.1/doc/spec/ltablex.sty
new file mode 100644
index 00000000..31a08479
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/ltablex.sty
@@ -0,0 +1,237 @@
+%%
+%% This is file ltablex.sty (v1.0, November 1995)
+%%
+%%
+%% Author: Anil K. Goel (akgoel@uwaterloo.ca)
+%%
+%%
+%% Copyright (C) QNX Software Systems Ltd. 1995
+%% All rights reserved.
+%% Please send any comments/suggetions to: latex@qnx.com
+%%
+%% This system is distributed in the hope that it will be useful
+%% to others, but WITHOUT ANY WARRANTY; without even the implied
+%% warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+%%
+%%
+%% The file modifies the tabularx environment to
+%% combine the features of the tabularx package
+%% (auto-sized columns in a fixed width table)
+%% with those of the longtable package
+%% (multi-page tables).
+%%
+%% The tables are typeset using the tabularx environment
+%% and the longtable environment is used internally to
+%% handle multi-page tables. The \setlongtables feature
+%% is used, and, therefore, the document should be
+%% run through latex twice.
+%%
+%% Another feature that has been added is to treat the X
+%% columns like 'l' columns if the table contents would allow
+%% that to happen without exceeding the specified width of
+%% the table. In other words, the specified width is
+%% treated as the maximum allowed and not the exact width
+%% of the table. This feature is the default but can be
+%% disabled (or enabled) with \keepXColumns (or \convertXColumns).
+%%
+%% Caveats:
+%% . The document needs to be latexed a couple times in general.
+%% . In general, it is necessary to remove the .aux file before
+%% the first latex run on the document.
+%% . The table should not be larger than TeX's memory capacity
+%%
+%%
+%% Here is a a simple usage example:
+%%
+%%
+%% \documentclass{article}
+%%
+%% \usepackage{ltablex}
+%%
+%% \textheight=4in
+%%
+%% \begin{document}
+%%
+%% % we want a table that is \textwidth long, has 4 columns, columns 1
+%% % and 3 are auto sized with the 3rd columns being 3 times wider than
+%% % the first column.
+%% %
+%%
+%%
+%% \begin{tabularx}{\linewidth}%
+%% {|>{\setlength{\hsize}{.5\hsize}\raggedright\arraybackslash}X| % col 1; auto-sized ragged right
+%% c| % col 2; default centered
+%% >{\setlength{\hsize}{1.5\hsize}\raggedleft\arraybackslash}X|% col 3; auto-sized ragged left
+%% l|} % col 4; default left-justified
+%%
+%% \caption*{The Table Caption}\\
+%% \hline
+%% F-Head1 & F-Head2 & F-Head3 & F-Head4\\
+%% \hline
+%% \hline
+%% \endfirsthead
+%% \hline
+%% Head1 & Head2 & Head3 & Head4\\
+%% \hline
+%% \hline
+%% \endhead
+%%
+%% \hline
+%% \hline
+%% Foot1 & Foot2 & Foot3 & Foot4\\
+%% \hline
+%% \endfoot
+%%
+%%
+%% \hline
+%% \hline
+%% L-Foot1 & L-Foot2 & L-Foot3 & L-Foot4\\
+%% \hline
+%% \endlastfoot
+%%
+%% This is a very long sentence not likely to fit&
+%% not too long&
+%% This is another very long sentence not likely to fit&
+%% not long\\
+%%
+%% \hline
+%% filler & filler & filler & filler\\
+%%
+%% \hline
+%% This is a very long sentence not likely to fit&
+%% not too long&
+%% This is another very long sentence not likely to fit&
+%% not long\\
+%%
+%% \hline
+%% This is a very long sentence not likely to fit&
+%% not too long&
+%% This is another very long sentence not likely to fit&
+%% not long\\
+%%
+%% \hline
+%% This is a very long sentence not likely to fit&
+%% not too long&
+%% This is another very long sentence not likely to fit&
+%% not long\\
+%%
+%% \end{tabularx}
+%%
+%% \begin{tabularx}{\linewidth}{|c|X|c|}
+%% \hline
+%% a &convert X to l & b\\
+%% \hline
+%% \end{tabularx}
+%%
+%% \keepXColumns
+%% \begin{tabularx}{\linewidth}{|c|X|c|}
+%% \hline
+%% a &retain X & b\\
+%% \hline
+%% \end{tabularx}
+%%
+%% \convertXColumns
+%% \begin{tabularx}{\linewidth}{|c|X|c|}
+%% \hline
+%% a &convert X to l & b\\
+%% \hline
+%% \end{tabularx}
+%%
+%%
+%% \end{document}
+
+\NeedsTeXFormat{LaTeX2e}
+\ProvidesPackage{ltablex}[1995/11/06 v1.0 Modified tabularx]
+
+\RequirePackage{longtable}[1994/12/08]
+\RequirePackage{tabularx}[1994/02/03]
+
+\newif\ifTX@convertX@
+\TX@convertX@true
+
+\newcommand\keepXColumns{
+ \TX@convertX@false
+}
+
+\newcommand\convertXColumns{
+ \TX@convertX@true
+}
+
+\renewcommand\TX@endtabularx{%
+ \expandafter\TX@newcol\expandafter{\tabularxcolumn{\TX@col@width}}%
+ \let\verb\TX@verb
+ \def\@elt##1{\global\value{##1}\the\value{##1}\relax}%
+ \edef\TX@ckpt{\cl@@ckpt}%
+ \let\@elt\relax
+ \TX@old@table=\maxdimen
+ \TX@col@width=\TX@target
+ \global\TX@cols=\@ne
+ \TX@typeout@
+ {\@spaces Table Width\@spaces Column Width\@spaces X Columns}%
+
+ %
+ % define \endhead, etc. to be \\ so that in this part
+ % of the process they are just rows
+ %
+ \let\savecaption\caption
+ \def\caption{\\}
+ \let\saveendhead\endhead
+ \def\endhead{\\}
+ \let\saveendfirsthead\endfirsthead
+ \def\endfirsthead{\\}
+ \let\saveendfoot\endfoot
+ \def\endfoot{\\}
+ \let\saveendlastfoot\endlastfoot
+ \def\endlastfoot{\\}
+ %
+ %
+ \ifTX@convertX@
+ \TX@trial{\def\NC@rewrite@X{\NC@find l}}
+ \ifdim\wd\@tempboxa<\TX@target
+ \TX@newcol{l}
+ \else
+ \TX@convertX@false
+ \fi
+ \fi
+
+ \ifTX@convertX@
+ \relax
+ \else
+ \TX@trial{\def\NC@rewrite@X{%
+ \global\advance\TX@cols\@ne\NC@find p{\TX@col@width}}}%
+ \loop
+ \TX@arith
+ \ifTX@
+ \TX@trial{}%
+ \repeat
+ \fi
+ {\let\@footnotetext\TX@ftntext\let\@xfootnotenext\TX@xftntext
+ % we may as well set \LTchunksize to be \maxdimen as the whole
+ % thing is already in memory anyway so we may as well do it in one
+ % chunk. if it is too big for one chunk we are already dead..
+ \LTchunksize\maxdimen
+ %
+ % restore \endhead, etc.
+ %
+ \let\caption\savecaption
+ \let\endhead\saveendhead
+ \let\endfirsthead\saveendfirsthead
+ \let\endfoot\saveendfoot
+ \let\endlastfoot\saveendlastfoot
+ %
+ \expandafter\longtable
+ \the\toks@
+ \endlongtable
+ }%
+ \global\TX@ftn\expandafter{\expandafter}\the\TX@ftn
+ \ifnum0=`{\fi}%
+ \end{tabularx}
+}
+
+
+%
+% activate column width reading from the .aux file
+%
+
+
+\setlongtables
diff --git a/libs/libtheora-1.1/doc/spec/macroblock.fig b/libs/libtheora-1.1/doc/spec/macroblock.fig
new file mode 100644
index 00000000..3e20d932
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/macroblock.fig
@@ -0,0 +1,37 @@
+#FIG 3.2 Produced by xfig version 3.2.5-alpha4
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 702 1540 4867 1540 4867 4828 702 4828 702 1540
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 710 4828 928 4828 928 4610 710 4610 710 4828
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 914 4610 1133 4610 1133 4391 914 4391 914 4610
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 723 4385 1133 4385 1133 4828 723 4828 723 4385
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 710 4610 928 4610 928 4391 710 4391 710 4610
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 914 4828 1133 4828 1133 4610 914 4610 914 4828
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 2068 857 6233 857 6233 4145 2068 4145 2068 857
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 1385 1198 5550 1198 5550 4487 1385 4487 1385 1198
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2089 3702 2499 3702 2499 4145 2089 4145 2089 3702
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1406 4043 1816 4043 1816 4487 1406 4487 1406 4043
+4 0 0 50 -1 0 5 0.0000 4 79 182 613 4943 (0,0)\001
+4 0 0 50 -1 0 5 0.0000 4 80 785 2055 833 Frame: chroma plane\001
+4 0 0 50 -1 0 5 0.0000 4 57 467 894 4009 Macroblock\001
+4 0 0 50 -1 0 5 0.0000 4 57 228 450 4521 Block\001
+4 0 0 50 -1 0 5 0.0000 4 57 228 450 4760 Block\001
+4 0 0 50 -1 0 5 0.0000 4 57 148 450 4863 8x8\001
+4 0 0 50 -1 0 5 0.0000 4 80 785 1235 1175 Frame: chroma plane\001
+4 0 0 50 -1 0 5 0.0000 4 80 694 621 1516 Frame: luma plane\001
diff --git a/libs/libtheora-1.1/doc/spec/pic-frame.fig b/libs/libtheora-1.1/doc/spec/pic-frame.fig
new file mode 100644
index 00000000..d99ec7e1
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/pic-frame.fig
@@ -0,0 +1,75 @@
+#FIG 3.2
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+0 32 #7f7f7f
+6 250 236 5737 4724
+6 659 4520 1068 4724
+4 1 0 50 0 0 7 0.0000 0 75 450 864 4724 X Offset\001
+4 1 0 50 0 0 7 0.0000 0 90 375 864 4596 Picture\001
+-6
+6 250 3880 454 4290
+4 1 0 50 0 0 7 1.5708 0 90 375 327 4086 Picture\001
+4 1 0 50 0 0 7 1.5708 0 75 450 454 4086 Y Offset\001
+-6
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 2
+ 608 301 608 454
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 2
+ 5466 301 5466 454
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 1 2
+ 1 1 1.00 34.09 68.18
+ 1 1 1.00 34.09 68.18
+ 608 378 5466 378
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 2
+ 608 4392 608 4546
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 2
+ 1119 4392 1119 4546
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 1 2
+ 1 1 1.00 34.09 68.18
+ 1 1 1.00 34.09 68.18
+ 608 4468 1119 4468
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 1 2
+ 1 1 1.00 34.09 68.18
+ 1 1 1.00 34.09 68.18
+ 1119 4468 5211 4468
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 2
+ 5211 4392 5211 4546
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 2
+ 404 4340 557 4340
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 2
+ 404 3830 557 3830
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 2
+ 404 761 557 761
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 1 2
+ 1 1 1.00 34.09 68.18
+ 1 1 1.00 34.09 68.18
+ 480 3830 480 761
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 2
+ 5517 4340 5671 4340
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 0 0 2
+ 5517 506 5671 506
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 1 2
+ 1 1 1.00 34.09 68.18
+ 1 1 1.00 34.09 68.18
+ 5594 4340 5594 506
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 1 2
+ 1 1 1.00 34.09 68.18
+ 1 1 1.00 34.09 68.18
+ 480 4340 480 3830
+2 2 0 1 0 7 50 0 -1 0.000 0 0 7 0 0 5
+ 608 506 5466 506 5466 4340 608 4340 608 506
+2 2 0 1 0 7 50 0 -1 0.000 0 0 7 0 0 5
+ 1119 761 5211 761 5211 3830 1119 3830 1119 761
+4 1 0 50 0 0 7 0.0000 0 90 720 3165 4596 Picture Width\001
+4 1 0 50 0 0 7 1.5708 0 105 690 5722 1912 Frame Height\001
+4 1 0 50 0 0 7 0.0000 0 90 660 2782 326 Frame Width\001
+4 1 0 50 0 0 7 1.5708 0 105 750 454 2295 Picture Height\001
+4 1 0 50 0 0 7 0.0000 0 75 315 2782 685 Frame\001
+4 1 0 50 0 0 7 0.0000 0 90 375 3165 2295 Picture\001
+4 0 0 50 0 0 7 0.0000 0 105 240 659 4290 (0,0)\001
+-6
diff --git a/libs/libtheora-1.1/doc/spec/pic_even.fig b/libs/libtheora-1.1/doc/spec/pic_even.fig
new file mode 100644
index 00000000..041a43a1
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/pic_even.fig
@@ -0,0 +1,102 @@
+#FIG 3.2
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+6 724 2025 945 2475
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 732 2244 945 2244 945 2025 732 2025 732 2244
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 732 2475 945 2475 945 2256 732 2256 732 2475
+-6
+6 1665 2070 1888 2475
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1673 2267 1888 2267 1888 2070 1673 2070 1673 2267
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1673 2475 1888 2475 1888 2278 1673 2278 1673 2475
+-6
+6 724 900 945 1350
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 732 1119 945 1119 945 900 732 900 732 1119
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 732 1350 945 1350 945 1131 732 1131 732 1350
+-6
+6 6300 2070 6795 2520
+6 6300 2070 6570 2295
+6 6300 2070 6570 2295
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 6335 2295 6553 2295 6553 2076 6335 2076 6335 2295
+-6
+-6
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 6335 2520 6553 2520 6553 2301 6335 2301 6335 2520
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 6560 2295 6778 2295 6778 2076 6560 2076 6560 2295
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 6560 2520 6778 2520 6778 2301 6560 2301 6560 2520
+-6
+6 4455 2070 4950 2520
+6 4455 2070 4725 2295
+6 4455 2070 4725 2295
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4490 2295 4708 2295 4708 2076 4490 2076 4490 2295
+-6
+-6
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4490 2520 4708 2520 4708 2301 4490 2301 4490 2520
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4715 2295 4933 2295 4933 2076 4715 2076 4715 2295
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4715 2520 4933 2520 4933 2301 4715 2301 4715 2520
+-6
+6 4455 945 4950 1395
+6 4455 945 4725 1170
+6 4455 945 4725 1170
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4490 1170 4708 1170 4708 951 4490 951 4490 1170
+-6
+-6
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4490 1395 4708 1395 4708 1176 4490 1176 4490 1395
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4715 1170 4933 1170 4933 951 4715 951 4715 1170
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4715 1395 4933 1395 4933 1176 4715 1176 4715 1395
+-6
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 2249 1800 3736 1800 3736 2947 2249 2947 2249 1800
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2385 1935 3600 1935 3600 2745 2385 2745 2385 1935
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2397 2745 2610 2745 2610 2526 2397 2526 2397 2745
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3375 2745 3590 2745 3590 2548 3375 2548 3375 2745
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 724 900 1888 900 1888 2475 724 2475 724 900
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 473 675 2003 675 2003 2925 473 2925 473 675
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2397 2154 2610 2154 2610 1935 2397 1935 2397 2154
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4500 945 6795 945 6795 2520 4500 2520 4500 945
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4500 945 6795 945 6795 2520 4500 2520 4500 945
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 4005 720 7020 720 7020 2970 4005 2970 4005 720
+4 0 0 50 -1 0 24 0.0000 4 30 270 2835 2655 ...\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 1080 2295 ...\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 765 1665 ...\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 2430 2385 ...\001
+4 0 0 50 -1 0 7 0.0000 4 90 210 450 3060 (0,0)\001
+4 0 0 50 -1 0 7 0.0000 4 90 210 2205 3060 (0,0)\001
+4 0 0 50 -1 0 7 0.0000 4 90 210 3943 3098 (0,0)\001
+4 0 0 50 -1 0 7 0.0000 4 75 285 4545 2655 Pixels\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 5220 2295 ...\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 4680 1755 ...\001
+4 0 0 50 -1 0 9 0.0000 4 105 1335 2205 1665 Frame: chroma (4:2:0 case)\001
+4 0 0 50 -1 0 9 0.0000 4 105 1335 450 585 Frame: chroma (4:2:2 case)\001
+4 0 0 50 -1 0 9 0.0000 4 75 615 4005 630 Frame: luma\001
diff --git a/libs/libtheora-1.1/doc/spec/pic_even_odd.fig b/libs/libtheora-1.1/doc/spec/pic_even_odd.fig
new file mode 100644
index 00000000..4b513b7f
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/pic_even_odd.fig
@@ -0,0 +1,88 @@
+#FIG 3.2
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+6 724 2025 945 2475
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 732 2244 945 2244 945 2025 732 2025 732 2244
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 732 2475 945 2475 945 2256 732 2256 732 2475
+-6
+6 1665 2070 1888 2475
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1673 2267 1888 2267 1888 2070 1673 2070 1673 2267
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1673 2475 1888 2475 1888 2278 1673 2278 1673 2475
+-6
+6 4455 2070 4950 2520
+6 4455 2070 4725 2295
+6 4455 2070 4725 2295
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4490 2295 4708 2295 4708 2076 4490 2076 4490 2295
+-6
+-6
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4490 2520 4708 2520 4708 2301 4490 2301 4490 2520
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4715 2295 4933 2295 4933 2076 4715 2076 4715 2295
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4715 2520 4933 2520 4933 2301 4715 2301 4715 2520
+-6
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 2249 1800 3736 1800 3736 2947 2249 2947 2249 1800
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2385 1935 3600 1935 3600 2745 2385 2745 2385 1935
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2397 2745 2610 2745 2610 2526 2397 2526 2397 2745
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3375 2745 3590 2745 3590 2548 3375 2548 3375 2745
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 724 900 1888 900 1888 2475 724 2475 724 900
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 473 675 2003 675 2003 2925 473 2925 473 675
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2397 2154 2610 2154 2610 1935 2397 1935 2397 2154
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4500 945 6795 945 6795 2520 4500 2520 4500 945
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 4005 720 7020 720 7020 2970 4005 2970 4005 720
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4500 945 6795 945 6795 2520 4500 2520 4500 945
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4490 1170 4708 1170 4708 951 4490 951 4490 1170
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4715 1170 4933 1170 4933 951 4715 951 4715 1170
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 6560 2520 6778 2520 6778 2301 6560 2301 6560 2520
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 6560 2295 6778 2295 6778 2076 6560 2076 6560 2295
+2 2 0 1 0 11 50 -1 43 0.000 0 0 -1 0 0 5
+ 4715 945 4933 945 4933 726 4715 726 4715 945
+2 2 0 1 0 11 50 -1 43 0.000 0 0 -1 0 0 5
+ 4490 945 4708 945 4708 726 4490 726 4490 945
+2 2 0 1 0 11 50 -1 43 0.000 0 0 -1 0 0 5
+ 6785 2295 7003 2295 7003 2076 6785 2076 6785 2295
+2 2 0 1 0 11 50 -1 43 0.000 0 0 -1 0 0 5
+ 6785 2520 7003 2520 7003 2301 6785 2301 6785 2520
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 732 1125 945 1125 945 906 732 906 732 1125
+2 2 0 1 0 11 50 -1 43 0.000 0 0 -1 0 0 5
+ 732 894 945 894 945 675 732 675 732 894
+4 0 0 50 -1 0 24 0.0000 4 30 270 2835 2655 ...\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 1080 2295 ...\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 765 1665 ...\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 2430 2385 ...\001
+4 0 0 50 -1 0 7 0.0000 4 90 210 450 3060 (0,0)\001
+4 0 0 50 -1 0 7 0.0000 4 90 210 2205 3060 (0,0)\001
+4 0 0 50 -1 0 7 0.0000 4 90 210 3943 3098 (0,0)\001
+4 0 0 50 -1 0 7 0.0000 4 75 285 4545 2655 Pixels\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 5220 2295 ...\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 4680 1755 ...\001
+4 0 0 50 -1 0 9 0.0000 4 105 1335 2205 1665 Frame: chroma (4:2:0 case)\001
+4 0 0 50 -1 0 9 0.0000 4 105 1335 450 585 Frame: chroma (4:2:2 case)\001
+4 0 0 50 -1 0 9 0.0000 4 75 615 4005 630 Frame: luma\001
diff --git a/libs/libtheora-1.1/doc/spec/pic_odd.fig b/libs/libtheora-1.1/doc/spec/pic_odd.fig
new file mode 100644
index 00000000..da126010
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/pic_odd.fig
@@ -0,0 +1,90 @@
+#FIG 3.2
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+6 724 2025 945 2475
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 732 2244 945 2244 945 2025 732 2025 732 2244
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 732 2475 945 2475 945 2256 732 2256 732 2475
+-6
+6 1665 2070 1888 2475
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1673 2267 1888 2267 1888 2070 1673 2070 1673 2267
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1673 2475 1888 2475 1888 2278 1673 2278 1673 2475
+-6
+6 724 900 945 1350
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 732 1119 945 1119 945 900 732 900 732 1119
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 732 1350 945 1350 945 1131 732 1131 732 1350
+-6
+6 6300 2070 6795 2520
+6 6300 2070 6570 2295
+6 6300 2070 6570 2295
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 6335 2295 6553 2295 6553 2076 6335 2076 6335 2295
+-6
+-6
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 6335 2520 6553 2520 6553 2301 6335 2301 6335 2520
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 6560 2295 6778 2295 6778 2076 6560 2076 6560 2295
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 6560 2520 6778 2520 6778 2301 6560 2301 6560 2520
+-6
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 2249 1800 3736 1800 3736 2947 2249 2947 2249 1800
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2385 1935 3600 1935 3600 2745 2385 2745 2385 1935
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2397 2745 2610 2745 2610 2526 2397 2526 2397 2745
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3375 2745 3590 2745 3590 2548 3375 2548 3375 2745
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 724 900 1888 900 1888 2475 724 2475 724 900
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 473 675 2003 675 2003 2925 473 2925 473 675
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2397 2154 2610 2154 2610 1935 2397 1935 2397 2154
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4500 945 6795 945 6795 2520 4500 2520 4500 945
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4500 945 6795 945 6795 2520 4500 2520 4500 945
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 4005 720 7020 720 7020 2970 4005 2970 4005 720
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4490 2295 4708 2295 4708 2076 4490 2076 4490 2295
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4490 2520 4708 2520 4708 2301 4490 2301 4490 2520
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4490 1170 4708 1170 4708 951 4490 951 4490 1170
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4490 1395 4708 1395 4708 1176 4490 1176 4490 1395
+2 2 0 1 0 11 50 -1 43 0.000 0 0 -1 0 0 5
+ 4265 1170 4483 1170 4483 951 4265 951 4265 1170
+2 2 0 1 0 11 50 -1 43 0.000 0 0 -1 0 0 5
+ 4265 1395 4483 1395 4483 1176 4265 1176 4265 1395
+2 2 0 1 0 11 50 -1 43 0.000 0 0 -1 0 0 5
+ 4265 2295 4483 2295 4483 2076 4265 2076 4265 2295
+2 2 0 1 0 11 50 -1 43 0.000 0 0 -1 0 0 5
+ 4265 2520 4483 2520 4483 2301 4265 2301 4265 2520
+4 0 0 50 -1 0 24 0.0000 4 30 270 2835 2655 ...\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 1080 2295 ...\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 765 1665 ...\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 2430 2385 ...\001
+4 0 0 50 -1 0 7 0.0000 4 90 210 450 3060 (0,0)\001
+4 0 0 50 -1 0 7 0.0000 4 90 210 2205 3060 (0,0)\001
+4 0 0 50 -1 0 7 0.0000 4 90 210 3943 3098 (0,0)\001
+4 0 0 50 -1 0 7 0.0000 4 75 285 4545 2655 Pixels\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 5220 2295 ...\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 4680 1755 ...\001
+4 0 0 50 -1 0 9 0.0000 4 105 1335 2205 1665 Frame: chroma (4:2:0 case)\001
+4 0 0 50 -1 0 9 0.0000 4 105 1335 450 585 Frame: chroma (4:2:2 case)\001
+4 0 0 50 -1 0 9 0.0000 4 75 615 4005 630 Frame: luma\001
diff --git a/libs/libtheora-1.1/doc/spec/pic_odd_even.fig b/libs/libtheora-1.1/doc/spec/pic_odd_even.fig
new file mode 100644
index 00000000..f1312952
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/pic_odd_even.fig
@@ -0,0 +1,84 @@
+#FIG 3.2
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+6 724 2025 945 2475
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 732 2244 945 2244 945 2025 732 2025 732 2244
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 732 2475 945 2475 945 2256 732 2256 732 2475
+-6
+6 1665 2070 1888 2475
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1673 2267 1888 2267 1888 2070 1673 2070 1673 2267
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1673 2475 1888 2475 1888 2278 1673 2278 1673 2475
+-6
+6 724 900 945 1350
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 732 1119 945 1119 945 900 732 900 732 1119
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 732 1350 945 1350 945 1131 732 1131 732 1350
+-6
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 2249 1800 3736 1800 3736 2947 2249 2947 2249 1800
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2385 1935 3600 1935 3600 2745 2385 2745 2385 1935
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2397 2745 2610 2745 2610 2526 2397 2526 2397 2745
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3375 2745 3590 2745 3590 2548 3375 2548 3375 2745
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 724 900 1888 900 1888 2475 724 2475 724 900
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 473 675 2003 675 2003 2925 473 2925 473 675
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2397 2154 2610 2154 2610 1935 2397 1935 2397 2154
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4500 945 6795 945 6795 2520 4500 2520 4500 945
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 4005 720 7020 720 7020 2970 4005 2970 4005 720
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4490 2295 4708 2295 4708 2076 4490 2076 4490 2295
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4490 2520 4708 2520 4708 2301 4490 2301 4490 2520
+2 2 0 1 0 11 50 -1 43 0.000 0 0 -1 0 0 5
+ 4265 2295 4483 2295 4483 2076 4265 2076 4265 2295
+2 2 0 1 0 11 50 -1 43 0.000 0 0 -1 0 0 5
+ 4265 2520 4483 2520 4483 2301 4265 2301 4265 2520
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4500 945 6795 945 6795 2520 4500 2520 4500 945
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 6560 2520 6778 2520 6778 2301 6560 2301 6560 2520
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 6560 2295 6778 2295 6778 2076 6560 2076 6560 2295
+2 2 0 1 0 11 50 -1 43 0.000 0 0 -1 0 0 5
+ 6785 2295 7003 2295 7003 2076 6785 2076 6785 2295
+2 2 0 1 0 11 50 -1 43 0.000 0 0 -1 0 0 5
+ 6785 2520 7003 2520 7003 2301 6785 2301 6785 2520
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4490 1170 4708 1170 4708 951 4490 951 4490 1170
+2 2 0 1 0 11 50 -1 43 0.000 0 0 -1 0 0 5
+ 4265 945 4483 945 4483 726 4265 726 4265 945
+2 2 0 1 0 11 50 -1 43 0.000 0 0 -1 0 0 5
+ 4265 1170 4483 1170 4483 951 4265 951 4265 1170
+2 2 0 1 0 11 50 -1 43 0.000 0 0 -1 0 0 5
+ 4490 945 4708 945 4708 726 4490 726 4490 945
+4 0 0 50 -1 0 24 0.0000 4 30 270 2835 2655 ...\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 1080 2295 ...\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 765 1665 ...\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 2430 2385 ...\001
+4 0 0 50 -1 0 7 0.0000 4 90 210 450 3060 (0,0)\001
+4 0 0 50 -1 0 7 0.0000 4 90 210 2205 3060 (0,0)\001
+4 0 0 50 -1 0 7 0.0000 4 90 210 3943 3098 (0,0)\001
+4 0 0 50 -1 0 7 0.0000 4 75 285 4545 2655 Pixels\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 5220 2295 ...\001
+4 0 0 50 -1 0 24 0.0000 4 30 270 4680 1755 ...\001
+4 0 0 50 -1 0 9 0.0000 4 105 1335 2205 1665 Frame: chroma (4:2:0 case)\001
+4 0 0 50 -1 0 9 0.0000 4 105 1335 450 585 Frame: chroma (4:2:2 case)\001
+4 0 0 50 -1 0 9 0.0000 4 75 615 4005 630 Frame: luma\001
diff --git a/libs/libtheora-1.1/doc/spec/pixel420.fig b/libs/libtheora-1.1/doc/spec/pixel420.fig
new file mode 100644
index 00000000..56e91912
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/pixel420.fig
@@ -0,0 +1,56 @@
+#FIG 3.2
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+6 675 4365 1170 4815
+6 675 4365 945 4590
+6 675 4365 945 4590
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 710 4590 928 4590 928 4371 710 4371 710 4590
+-6
+-6
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 710 4815 928 4815 928 4596 710 4596 710 4815
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 935 4590 1153 4590 1153 4371 935 4371 935 4590
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 935 4815 1153 4815 1153 4596 935 4596 935 4815
+-6
+6 1125 4365 1646 4815
+6 1125 4365 1420 4590
+6 1125 4365 1420 4590
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1163 4590 1401 4590 1401 4371 1163 4371 1163 4590
+-6
+-6
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1163 4815 1401 4815 1401 4596 1163 4596 1163 4815
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1409 4590 1646 4590 1646 4371 1409 4371 1409 4590
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1409 4815 1646 4815 1646 4596 1409 4596 1409 4815
+-6
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 1665 1350 4788 1350 4788 4153 1665 4153 1665 1350
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 2700 900 5823 900 5823 3703 2700 3703 2700 900
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 702 2025 3825 2025 3825 4828 702 4828 702 2025
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1800 4005 2018 4005 2018 3786 1800 3786 1800 4005
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2160 4005 2378 4005 2378 3786 2160 3786 2160 4005
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2835 3555 3053 3555 3053 3336 2835 3336 2835 3555
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3195 3555 3413 3555 3413 3336 3195 3336 3195 3555
+4 0 0 50 -1 0 8 0.0000 4 105 1215 1485 1305 Frame: chroma plane Cb\001
+4 0 0 50 -1 0 8 0.0000 4 105 1200 2565 855 Frame: chroma plane Cr\001
+4 0 0 50 -1 0 8 0.0000 4 105 1035 540 1980 Frame: luma planeY'\001
+4 0 0 50 -1 0 7 0.0000 4 75 285 765 4320 Pixels\001
+4 0 0 50 -1 0 7 0.0000 4 90 210 613 4943 (0,0)\001
diff --git a/libs/libtheora-1.1/doc/spec/pixel422.fig b/libs/libtheora-1.1/doc/spec/pixel422.fig
new file mode 100644
index 00000000..dbe008a3
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/pixel422.fig
@@ -0,0 +1,70 @@
+#FIG 3.2
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+6 675 4365 1170 4815
+6 675 4365 945 4590
+6 675 4365 945 4590
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 710 4590 928 4590 928 4371 710 4371 710 4590
+-6
+-6
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 710 4815 928 4815 928 4596 710 4596 710 4815
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 935 4590 1153 4590 1153 4371 935 4371 935 4590
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 935 4815 1153 4815 1153 4596 935 4596 935 4815
+-6
+6 1125 4365 1646 4815
+6 1125 4365 1420 4590
+6 1125 4365 1420 4590
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1163 4590 1401 4590 1401 4371 1163 4371 1163 4590
+-6
+-6
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1163 4815 1401 4815 1401 4596 1163 4596 1163 4815
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1409 4590 1646 4590 1646 4371 1409 4371 1409 4590
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1409 4815 1646 4815 1646 4596 1409 4596 1409 4815
+-6
+6 1800 3690 2025 4140
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1807 3909 2025 3909 2025 3690 1807 3690 1807 3909
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1807 4140 2025 4140 2025 3921 1807 3921 1807 4140
+-6
+6 2160 3690 2385 4140
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2167 3909 2385 3909 2385 3690 2167 3690 2167 3909
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2167 4140 2385 4140 2385 3921 2167 3921 2167 4140
+-6
+6 3195 3240 3420 3690
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3202 3459 3420 3459 3420 3240 3202 3240 3202 3459
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3202 3690 3420 3690 3420 3471 3202 3471 3202 3690
+-6
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 1665 1350 4788 1350 4788 4153 1665 4153 1665 1350
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2842 3459 3060 3459 3060 3240 2842 3240 2842 3459
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 2700 900 5823 900 5823 3703 2700 3703 2700 900
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2842 3690 3060 3690 3060 3471 2842 3471 2842 3690
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 702 2025 3825 2025 3825 4828 702 4828 702 2025
+4 0 0 50 -1 0 8 0.0000 4 105 1215 1485 1305 Frame: chroma plane Cb\001
+4 0 0 50 -1 0 8 0.0000 4 105 1200 2565 855 Frame: chroma plane Cr\001
+4 0 0 50 -1 0 8 0.0000 4 105 1035 540 1980 Frame: luma planeY'\001
+4 0 0 50 -1 0 7 0.0000 4 75 285 765 4320 Pixels\001
+4 0 0 50 -1 0 7 0.0000 4 90 210 613 4943 (0,0)\001
diff --git a/libs/libtheora-1.1/doc/spec/pixel444.fig b/libs/libtheora-1.1/doc/spec/pixel444.fig
new file mode 100644
index 00000000..75655e8a
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/pixel444.fig
@@ -0,0 +1,44 @@
+#FIG 3.2
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 702 2025 3825 2025 3825 4828 702 4828 702 2025
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 1665 1350 4788 1350 4788 4153 1665 4153 1665 1350
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 2700 900 5823 900 5823 3703 2700 3703 2700 900
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 710 4590 928 4590 928 4371 710 4371 710 4590
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 935 4590 1153 4590 1153 4371 935 4371 935 4590
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 935 4815 1153 4815 1153 4596 935 4596 935 4815
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 710 4815 928 4815 928 4596 710 4596 710 4815
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1700 3915 1918 3915 1918 3696 1700 3696 1700 3915
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1925 3915 2143 3915 2143 3696 1925 3696 1925 3915
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1925 4140 2143 4140 2143 3921 1925 3921 1925 4140
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1700 4140 1918 4140 1918 3921 1700 3921 1700 4140
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2735 3465 2953 3465 2953 3246 2735 3246 2735 3465
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2960 3465 3178 3465 3178 3246 2960 3246 2960 3465
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2960 3690 3178 3690 3178 3471 2960 3471 2960 3690
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2735 3690 2953 3690 2953 3471 2735 3471 2735 3690
+4 0 0 50 -1 0 8 0.0000 4 105 1215 1485 1305 Frame: chroma plane Cb\001
+4 0 0 50 -1 0 8 0.0000 4 105 1200 2565 855 Frame: chroma plane Cr\001
+4 0 0 50 -1 0 8 0.0000 4 105 1035 540 1980 Frame: luma planeY'\001
+4 0 0 50 -1 0 7 0.0000 4 75 285 765 4320 Pixels\001
+4 0 0 50 -1 0 7 0.0000 4 90 210 613 4943 (0,0)\001
diff --git a/libs/libtheora-1.1/doc/spec/raster-block.fig b/libs/libtheora-1.1/doc/spec/raster-block.fig
new file mode 100644
index 00000000..cebaf02b
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/raster-block.fig
@@ -0,0 +1,91 @@
+#FIG 3.2 Produced by xfig version 3.2.5-alpha4
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 1125 900 1575 900
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 450 450 1350 450 1350 1350 450 1350 450 450
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1350 450 2250 450 2250 1350 1350 1350 1350 450
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2250 450 3150 450 3150 1350 2250 1350 2250 450
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3150 450 4050 450 4050 1350 3150 1350 3150 450
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 450 1350 1350 1350 1350 2250 450 2250 450 1350
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1350 1350 2250 1350 2250 2250 1350 2250 1350 1350
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2250 1350 3150 1350 3150 2250 2250 2250 2250 1350
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3150 1350 4050 1350 4050 2250 3150 2250 3150 1350
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 450 2250 1350 2250 1350 3150 450 3150 450 2250
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1350 2250 2250 2250 2250 3150 1350 3150 1350 2250
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2250 2250 3150 2250 3150 3150 2250 3150 2250 2250
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3150 2250 4050 2250 4050 3150 3150 3150 3150 2250
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 450 3150 1350 3150 1350 4050 450 4050 450 3150
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1350 3150 2250 3150 2250 4050 1350 4050 1350 3150
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2250 3150 3150 3150 3150 4050 2250 4050 2250 3150
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 3150 3150 4050 3150 4050 4050 3150 4050 3150 3150
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4050 450 4950 450 4950 1350 4050 1350 4050 450
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4050 1350 4950 1350 4950 2250 4050 2250 4050 1350
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4050 2250 4950 2250 4950 3150 4050 3150 4050 2250
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4050 3150 4950 3150 4950 4050 4050 4050 4050 3150
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4950 3150 5850 3150 5850 4050 4950 4050 4950 3150
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4950 2250 5850 2250 5850 3150 4950 3150 4950 2250
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4950 1350 5850 1350 5850 2250 4950 2250 4950 1350
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 4950 450 5850 450 5850 1350 4950 1350 4950 450
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 1125 3600 1575 3600
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 2925 3600 3375 3600
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 2025 3600 2475 3600
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 1125 2655 1575 2655
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 4770 3600 5220 3600
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 5445 3510 900 2880
+2 1 0 1 0 7 50 0 -1 0.000 0 0 -1 1 0 2
+ 1 1 1.00 60.00 120.00
+ 5400 1800 855 1170
+4 1 0 50 0 1 12 0.0000 0 150 105 900 3660 0\001
+4 1 0 50 0 1 12 0.0000 0 150 105 1800 3660 1\001
+4 1 0 50 0 1 12 0.0000 0 150 105 2700 3660 2\001
+4 0 0 50 -1 0 20 0.0000 4 30 225 3555 3645 ...\001
+4 0 0 50 -1 0 20 0.0000 4 30 225 945 1845 ...\001
+4 0 0 50 -1 0 12 0.0000 4 150 330 5310 3645 m-1\001
+4 0 0 50 -1 0 12 0.0000 4 150 435 5175 2655 2m-1\001
+4 1 0 50 0 1 12 0.0000 0 105 165 900 2760 m\001
+4 1 0 50 0 1 12 0.0000 0 195 690 855 1035 (n-1)*m\001
+4 0 0 50 -1 0 12 0.0000 4 150 540 5085 900 n*m-1\001
diff --git a/libs/libtheora-1.1/doc/spec/reference-frames.fig b/libs/libtheora-1.1/doc/spec/reference-frames.fig
new file mode 100644
index 00000000..8026e56e
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/reference-frames.fig
@@ -0,0 +1,46 @@
+#FIG 3.2 Produced by xfig version 3.2.5-alpha4
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+2 2 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 5
+ 1980 450 2430 450 2430 900 1980 900 1980 450
+2 2 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 5
+ 2520 450 2970 450 2970 900 2520 900 2520 450
+2 2 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 5
+ 4140 450 4590 450 4590 900 4140 900 4140 450
+2 2 1 2 0 7 50 -1 -1 4.000 0 0 -1 0 0 5
+ 1440 450 1890 450 1890 900 1440 900 1440 450
+2 2 1 2 0 7 50 -1 15 4.000 0 0 -1 0 0 5
+ 3600 450 4050 450 4050 900 3600 900 3600 450
+2 2 1 2 0 7 50 -1 41 4.000 0 0 -1 0 0 5
+ 3060 450 3510 450 3510 900 3060 900 3060 450
+2 2 0 2 0 7 50 -1 41 0.000 0 0 -1 0 0 5
+ 900 450 1350 450 1350 900 900 900 900 450
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
+ 0 0 1.00 60.00 120.00
+ 3780 990 3780 1395
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
+ 0 0 1.00 60.00 120.00
+ 3240 990 3240 1395
+2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
+ 0 0 1.00 60.00 120.00
+ 1125 990 1125 1395
+4 0 0 50 -1 0 20 0.0000 4 30 225 4770 675 ...\001
+4 0 0 50 -1 0 12 0.0000 4 150 420 900 405 Intra\001
+4 0 0 50 -1 0 12 0.0000 4 150 420 1440 405 Inter\001
+4 0 0 50 -1 0 12 0.0000 4 150 420 1980 405 Inter\001
+4 0 0 50 -1 0 12 0.0000 4 150 420 2520 405 Inter\001
+4 0 0 50 -1 0 12 0.0000 4 150 420 3060 405 Inter\001
+4 0 0 50 -1 0 12 0.0000 4 150 420 3600 405 Inter\001
+4 0 0 50 -1 0 12 0.0000 4 150 420 4140 405 Inter\001
+4 0 0 50 -1 0 12 0.0000 4 120 630 3690 1575 current\001
+4 0 0 50 -1 0 12 0.0000 4 150 840 2745 1575 reference\001
+4 0 0 50 -1 0 12 0.0000 4 150 510 2925 1755 frame\001
+4 0 0 50 -1 0 12 0.0000 4 150 510 3690 1755 frame\001
+4 0 0 50 -1 0 12 0.0000 4 195 570 855 1575 golden\001
+4 0 0 50 -1 0 12 0.0000 4 150 510 900 1800 frame\001
diff --git a/libs/libtheora-1.1/doc/spec/spec.bib b/libs/libtheora-1.1/doc/spec/spec.bib
new file mode 100644
index 00000000..cf62cebf
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/spec.bib
@@ -0,0 +1,120 @@
+@MANUAL{rfc2044,
+ author="Francois Yergeau",
+ title="{RFC} 2044: {UTF}-8, a transformation format of Unicode and {ISO}
+ 10646",
+ month=oct,
+ year=1996,
+ note="\url{http://www.ietf.org/rfc/rfc2044.txt}"
+}
+
+@ARTICLE{CSF77,
+ author="Wen-Hsiung Chen and C. Harrison Smith and S. C. Fralick",
+ title="A Fast Computational Algorithm for the Discrete Cosine Transform",
+ journal="{IEEE} Transactions on Communications",
+ volume="COM-25",
+ number=9,
+ pages="1004--1011",
+ month=sep,
+ year=1977
+}
+
+@MISC{Mel04,
+ author="Mike Melanson",
+ title="{VP3} Bitstream Format and Decoding Process",
+ howpublished="\url{http://www.multimedia.cx/vp3-format.txt}",
+ month=mar,
+ year=2004
+}
+
+@MISC{Poyn97,
+ author="Charles Poynton",
+ title="Frequently-Asked Questions about Gamma",
+ howpublished="\url{http://www.poynton.com/GammaFAQ.html}",
+ month=feb,
+ year=1997
+}
+
+@MANUAL{rec470,
+ key="ITU470",
+ title="Reccomendation {ITU-R} {BT}.470-6: Conventional Television Systems",
+ edition="1970, revised",
+ organization="International Telecommunications Union",
+ address="1211 Geneva 20, Switzerland",
+ year=1998
+}
+
+@MANUAL{rec601,
+ key="ITU601",
+ title="Reccomendation {ITU-R} {BT}.601-5: Studio Encoding Parameters of
+ Digital Television for Standard 4:3 and Wide-Screen 16:9 Aspect Ratios",
+ edition="1982, revised",
+ organization="International Telecommunications Union",
+ address="1211 Geneva 20, Switzerland",
+ year=1995
+}
+
+@MANUAL{rec709,
+ key="ITU709",
+ title="Recommendation {ITU-R} {BT}.709-5: Parameter values for the {HDTV}
+ standards for production and international programme exchange",
+ edition="1990, revised",
+ organization="International Telecommunications Union",
+ address="1211 Geneva 20, Switzerland",
+ year=2002
+}
+
+@MANUAL{smpte170m,
+ key="SMPTE170M",
+ title="{SMPTE-170M}: Television --- Composite Analog Video Signal --- {NTSC}
+ for Studio Applications",
+ organization="Society of Motion Pciture and Television Engineers",
+ year=1994
+}
+
+@MANUAL{smpte240m,
+ key="SMPTE240M",
+ title="{SMPTE-240M}: Television --- Signal Parameters --- 1125-Line
+ High-Definition Production",
+ organization="Society of Motion Pciture and Television Engineers",
+ year=1999
+}
+
+@MANUAL{vorbis,
+ title="{Vorbis~I} specification",
+ organization="{Xiph.Org Foundation}",
+ year=2002,
+ note="\url{http://www.xiph.org/ogg/vorbis/doc/}"
+}
+
+@MANUAL{rfc2119,
+ author="Scott Bradner",
+ title="{RFC} 2119: Key words for use in {RFC}s to Indicate Requirement
+ Levels",
+ month=mar,
+ year=1997,
+ note="\url{http://www.ietf.org/rfc/rfc2119.txt}"
+}
+
+@MANUAL{rfc3533,
+ author="Silvia Pfeiffer",
+ title="{RFC} 3533: The {Ogg} Encapsulation Format Version 0",
+ month=may,
+ year=2003,
+ note="\url{http://www.ietf.org/rfc/rfc3533.txt}"
+}
+
+@MANUAL{rfc3534,
+ author="Linus Walleij",
+ title="{RFC} 3534: The {application/ogg} Media Type",
+ month=may,
+ year=2003,
+ note="\url{http://www.ietf.org/rfc/rfc3534.txt}"
+}
+
+@MANUAL{rfc3550,
+ author="H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson",
+ title="RTP: A Transport Protocol for Real-Time Applications",
+ month=jul,
+ year=2003,
+ note="\url{http://www.ietf.org/rfc/rfc3550.txt}"
+}
diff --git a/libs/libtheora-1.1/doc/spec/spec.tex b/libs/libtheora-1.1/doc/spec/spec.tex
new file mode 100644
index 00000000..da29ed58
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/spec.tex
@@ -0,0 +1,8194 @@
+\documentclass[9pt,letterpaper]{book}
+
+\usepackage{latexsym}
+\usepackage{amssymb}
+\usepackage{amsmath}
+\usepackage{bm}
+\usepackage{textcomp}
+\usepackage{graphicx}
+\usepackage{booktabs}
+\usepackage{tabularx}
+\usepackage{longtable}
+\usepackage{ltablex}
+\usepackage{wrapfig}
+\usepackage[pdfpagemode=None,pdfstartview=FitH,pdfview=FitH,colorlinks=true]%
+ {hyperref}
+
+\newtheorem{theorem}{Theorem}[section]
+\newcommand{\idx}[1]{{\ensuremath{\mathit{#1}}}}
+\newcommand{\qti}{\idx{qti}}
+\newcommand{\qtj}{\idx{qtj}}
+\newcommand{\pli}{\idx{pli}}
+\newcommand{\plj}{\idx{plj}}
+\newcommand{\qi}{\idx{qi}}
+\newcommand{\ci}{\idx{ci}}
+\newcommand{\bmi}{\idx{bmi}}
+\newcommand{\bmj}{\idx{bmj}}
+\newcommand{\qri}{\idx{qri}}
+\newcommand{\qrj}{\idx{qrj}}
+\newcommand{\hti}{\idx{hti}}
+\newcommand{\sbi}{\idx{sbi}}
+\newcommand{\bi}{\idx{bi}}
+\newcommand{\bj}{\idx{bj}}
+\newcommand{\mbi}{\idx{mbi}}
+\newcommand{\mbj}{\idx{mbj}}
+\newcommand{\mi}{\idx{mi}}
+\newcommand{\cbi}{\idx{cbi}}
+\newcommand{\qii}{\idx{qii}}
+\newcommand{\ti}{\idx{ti}}
+\newcommand{\tj}{\idx{tj}}
+\newcommand{\rfi}{\idx{rfi}}
+\newcommand{\zzi}{\idx{zzi}}
+\newcommand{\ri}{\idx{ri}}
+%This somewhat odd construct ensures that \bitvar{\qi}, etc., will set the
+% qi in bold face, even though it is in a \mathit font, yet \bitvar{VAR} will
+% set VAR in a bold, roman font.
+\newcommand{\bitvar}[1]{\ensuremath{\mathbf{\bm{#1}}}}
+\newcommand{\locvar}[1]{\ensuremath{\mathrm{#1}}}
+\newcommand{\term}[1]{{\em #1}}
+\newcommand{\bin}[1]{\ensuremath{\mathtt{b#1}}}
+\newcommand{\hex}[1]{\ensuremath{\mathtt{0x#1}}}
+\newcommand{\ilog}{\ensuremath{\mathop{\mathrm{ilog}}\nolimits}}
+\newcommand{\round}{\ensuremath{\mathop{\mathrm{round}}\nolimits}}
+\newcommand{\sign}{\ensuremath{\mathop{\mathrm{sign}}\nolimits}}
+\newcommand{\lflim}{\ensuremath{\mathop{\mathrm{lflim}}\nolimits}}
+
+%Section-based table, figure, and equation numbering.
+\numberwithin{equation}{chapter}
+\numberwithin{figure}{chapter}
+\numberwithin{table}{chapter}
+
+%Provide section numbering for \paragraph.
+\makeatletter
+\renewcommand{\paragraph}{\@startsection{paragraph}{4}{0ex}%
+ {-3.25ex plus -1ex minus -0.2ex}%
+ {1.5ex plus 0.2ex}%
+ {\normalfont\normalsize\bfseries}}
+\makeatother
+\stepcounter{secnumdepth}
+\stepcounter{tocdepth}
+
+\keepXColumns
+
+\pagestyle{headings}
+\bibliographystyle{alpha}
+
+\title{Theora Specification}
+\author{Xiph.Org Foundation}
+\date{\today}
+
+
+\begin{document}
+
+\frontmatter
+
+\begin{titlepage}
+\maketitle
+\end{titlepage}
+\thispagestyle{empty}
+\cleardoublepage
+
+\pagenumbering{roman}
+
+\thispagestyle{plain}
+\tableofcontents
+\cleardoublepage
+
+\thispagestyle{plain}
+\listoffigures
+\cleardoublepage
+
+\thispagestyle{plain}
+\listoftables
+\cleardoublepage
+
+\thispagestyle{plain}
+\markboth{{\sc Notation and Conventions}}{{\sc Notation and Conventions}}
+\chapter*{Notation and Conventions}
+
+All parameters either passed in or out of a decoding procedure are given in
+ \bitvar{bold\ face}.
+
+The prefix \bin{} indicates that the following value is to be interpreted as a
+ binary number (base 2).
+\begin{verse}
+{\bf Example:} The value \bin{1110100} is equal to the decimal value 116.
+\end{verse}
+
+The prefix \hex{} indicates the following value is to be interpreted as a
+ hexadecimal number (base 16).
+\begin{verse}
+{\bf Example:} The value \hex{74} is equal to the decimal value 116.
+\end{verse}
+
+All arithmetic defined by this specification is exact.
+However, any real numbers that do arise will always be converted back to
+ integers again in short order.
+The entire specification can be implemented using only normal integer
+ operations.
+All operations are to be implemented with sufficiently large integers so that
+ overflow cannot occur.
+Where the result of a computation is to be truncated to a fixed-sized binary
+ representation, this will be explicitly noted.
+The size given for all variables is the maximum number of bits needed to store
+ any value in that variable.
+Intermediate computations involving that variable may require more bits.
+
+The following operators are defined:
+
+\begin{description}
+\item[$|a|$]
+The absolute value of a number $a$.
+\begin{align*}
+|a| & = \left\{\begin{array}{ll}
+-a, & a < 0 \\
+a, & a \ge 0
+\end{array}\right.
+\end{align*}
+
+\item[$a*b$]
+Multiplication of a number $a$ by a number $b$.
+\item[$\frac{a}{b}$]
+Exact division of a number $a$ by a number $b$, producing a potentially
+ non-integer result.
+
+\item[$\left\lfloor a\right\rfloor$]
+The largest integer less than or equal to a real number $a$.
+
+\item[$\left\lceil a\right\rceil$]
+The smallest integer greater than or equal to a real number $a$.
+
+\item[$a//b$]
+Integer division of $a$ by $b$.
+\begin{align*}
+a//b & = \left\{\begin{array}{ll}
+\left\lceil\frac{a}{b}\right\rceil, & a < 0 \\
+\left\lfloor\frac{a}{b}\right\rfloor, & a \ge 0
+\end{array}\right.
+\end{align*}
+
+\item[$a\%b$]
+The remainder from the integer division of $a$ by $b$.
+\begin{align*}
+a\%b & = a-|b|*\left\lfloor\frac{a}{|b|}\right\rfloor
+\end{align*}
+Note that with this definition, the result is always non-negative and less than
+ $|b|$.
+
+\item[$a<>b$]
+The value obtained by right-shifting the two's complement integer $a$ by $b$
+ bits, filling in the leftmost bits of the new value with $0$ if $a$ is
+ non-negative and $1$ if $a$ is negative.
+This is {\em not} equivalent to integer division of $a$ by $2^b$.
+Instead,
+\begin{align*}
+a>>b & = \left\lfloor\frac{a}{2^b}\right\rfloor.
+\end{align*}
+
+\item[$\round(a)$]
+Rounds a number $a$ to the nearest integer, with ties rounded away from $0$.
+\begin{align*}
+\round(a) = \left\{\begin{array}{ll}
+\lceil a-\frac{1}{2}\rceil & a \le 0 \\
+\lfloor a+\frac{1}{2}\rfloor & a > 0
+\end{array}\right.
+\end{align*}
+
+\item[$\sign(a)$]
+Returns the sign of a given number.
+\begin{align*}
+\sign(a) = \left\{\begin{array}{ll}
+-1 & a < 0 \\
+0 & a = 0 \\
+1 & a > 0
+\end{array}\right.
+\end{align*}
+
+\item[$\ilog(a)$]
+The minimum number of bits required to store a positive integer $a$ in
+ two's complement notation, or $0$ for a non-positive integer $a$.
+\begin{align*}
+\ilog(a) = \left\{\begin{array}{ll}
+0, & a \le 0 \\
+\left\lfloor\log_2{a}\right\rfloor+1, & a > 0
+\end{array}\right.
+\end{align*}
+
+\begin{verse}
+{\bf Examples:}
+\begin{itemize}
+\item $\ilog(-1)=0$
+\item $\ilog(0)=0$
+\item $\ilog(1)=1$
+\item $\ilog(2)=2$
+\item $\ilog(3)=2$
+\item $\ilog(4)=3$
+\item $\ilog(7)=3$
+\end{itemize}
+\end{verse}
+
+\item[$\min(a,b)$]
+The minimum of two numbers $a$ and $b$.
+
+\item[$\max(a,b)$]
+The maximum of two numbers $a$ and $b$.
+
+\end{description}
+\cleardoublepage
+
+
+\thispagestyle{plain}
+\markboth{{\sc Key words}}{{\sc Key words}}
+\chapter*{Key words}
+
+%We can't rewrite this, because this is text required by RFC 2119, so we use
+% some emergency stretching to get it typeset properly.
+\setlength{\emergencystretch}{2em}
+The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL NOT'',
+ ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and ``OPTIONAL'' in this
+ document are to be intrepreted as described in RFC 2119 \cite{rfc2119}.\par
+\setlength{\emergencystretch}{0em}
+
+Where such assertions are placed on the contents of a Theora bitstream itself,
+ implementations should be prepared to encounter bitstreams that do not follow
+ these requirements.
+An application's behavior in the presecence of such non-conforming bitstreams
+ is not defined by this specification, but any reasonable method of handling
+ them MAY be used.
+By way of example, applications MAY discard the current frame, retain the
+ current output thus far, or attempt to continue on by assuming some default
+ values for the erroneous bits.
+When such an error occurs in the bitstream headers, an application MAY refuse
+ to decode the entire stream.
+An application SHOULD NOT allow such non-conformant bitstreams to overflow
+ buffers and potentially execute arbitrary code, as this represents a serious
+ security risk.
+
+An application MUST, however, ensure any bits marked as reserved have the value
+ zero, and refuse to decode the stream if they do not.
+These are used as place holders for future bitstream features with which the
+ current bitstream is forward-compatible.
+Such features may not increment the bitstream version number, and can only be
+ recognized by checking the value of these reserved bits.
+
+\cleardoublepage
+
+
+
+\mainmatter
+
+\pagenumbering{arabic}
+\setcounter{page}{1}
+
+\chapter{Introduction}
+
+Theora is a general purpose, lossy video codec.
+It is based on the VP3 video codec produced by On2 Technologies
+ (\url{http://www.on2.com/}).
+On2 donated the VP3.1 source code to the Xiph.Org Foundation and released it
+ under a BSD-like license.
+On2 also made an irrevocable, royalty-free license grant for any patent claims
+ it might have over the software and any derivatives.
+No formal specification exists for the VP3 format beyond this source code,
+ however Mike Melanson maintains a detailed description \cite{Mel04}.
+Portions of this specification were adopted from that text with permission.
+
+\section{VP3 and Theora}
+
+Theora contains a superset of the features that were available in the original
+ VP3 codec.
+Content encoded with VP3.1 can be losslessly transcoded into the Theora format.
+Theora content cannot, in general, be losslessly transcoded into the VP3
+ format.
+If a feature is not available in the original VP3 format, this is mentioned
+ when that feature is defined.
+A complete list of these features appears in Appendix~\ref{app:vp3-compat}.
+%TODO: VP3 - theora comparison in appendix
+
+\section{Video Formats}
+
+Theora currently supports progressive video data of arbitrary dimensions at a
+ constant frame rate in one of several $Y'C_bC_r$ color spaces.
+The precise definition the supported color spaces appears in
+ Section~\ref{sec:colorspaces}.
+Three different chroma subsampling formats are supported: 4:2:0, 4:2:2,
+ and 4:4:4.
+The precise details of each of these formats and their sampling locations are
+ described in Section~\ref{sec:pixfmts}.
+
+The Theora format does not support interlaced material, variable frame rates,
+ bit-depths larger than 8 bits per component, nor alternate color spaces such
+ as RGB or arbitrary multi-channel spaces.
+Black and white content can be efficiently encoded, however, because the
+ uniform chroma planes compress well.
+Support for interlaced material is planned for a future version.
+\begin{verse}
+{\bf Note:} Infrequently changing frame rates---as when film and video
+ sequences are cut together---can be supported in the Ogg container format by
+ chaining several Theora streams together.
+\end{verse}
+Support for increased bit depths or additional color spaces is not planned.
+
+\section{Classification}
+
+Theora is a block-based lossy transform codec that utilizes an
+ $8\times 8$ Type-II Discrete Cosine Transform and block-based motion
+ compensation.
+This places it in the same class of codecs as MPEG-1, -2, -4, and H.263.
+The details of how individual blocks are organized and how DCT coefficients are
+ stored in the bitstream differ substantially from these codecs, however.
+Theora supports only intra frames (I frames in MPEG) and inter frames (P frames
+ in MPEG).
+There is no equivalent to the bi-predictive frames (B frames) found in MPEG
+ codecs.
+
+\section{Assumptions}
+
+The Theora codec design assumes a complex, psychovisually-aware encoder and a
+ simple, low-complexity decoder.
+%TODO: Talk more about implementation complexity.
+
+Theora provides none of its own framing, synchronization, or protection against
+ transmission errors.
+An encoder is solely a method of accepting input video frames and
+ compressing these frames into raw, unformatted `packets'.
+The decoder then accepts these raw packets in sequence, decodes them, and
+ synthesizes a fascimile of the original video frames.
+Theora is a free-form variable bit rate (VBR) codec, and packets have no
+ minimum size, maximum size, or fixed/expected size.
+
+Theora packets are thus intended to be used with a transport mechanism that
+ provides free-form framing, synchronization, positioning, and error correction
+ in accordance with these design assumptions, such as Ogg (for file transport)
+ or RTP (for network multicast).
+For the purposes of a few examples in this document, we will assume that Theora
+ is embedded in an Ogg stream specifically, although this is by no means a
+ requirement or fundamental assumption in the Theora design.
+
+The specification for embedding Theora into an Ogg transport stream is given in
+ Appendix~\ref{app:oggencapsulation}.
+
+\section{Codec Setup and Probability Model}
+
+Theora's heritage is the proprietary commerical codec VP3, and it retains a
+ fair amount of inflexibility when compared to Vorbis \cite{vorbis}, the first
+ Xiph.Org codec, which began as a research codec.
+However, to provide additional scope for encoder improvement, Theora adopts
+ some of the configurable aspects of decoder setup that are present in Vorbis.
+This configuration data is not available in VP3, which uses hardcoded values
+ instead.
+
+Theora makes the same controversial design decision that Vorbis made to include
+ the entire probability model for the DCT coefficients and all the quantization
+ parameters in the bitstream headers.
+This is often several hundred fields.
+It is therefore impossible to decode any frame in the stream without
+ having previously fetched the codec info and codec setup headers.
+
+\begin{verse}
+{\bf Note:} Theora {\em can} initiate decode at an arbitrary intra-frame packet
+ within a bitstream so long as the codec has been initialized with the setup
+ headers.
+\end{verse}
+
+Thus, Theora headers are both required for decode to begin and relatively large
+ as bitstream headers go.
+The header size is unbounded, although as a rule-of-thumb less than 16kB is
+ recommended, and Xiph.Org's reference encoder follows this suggestion.
+%TODO: Is 8kB enough? My setup header is 7.4kB, that doesn't leave much room
+% for comments.
+%RG: the lesson from vorbis is that as small as possible is really
+% important in some applications. Practically, what's acceptable
+% depends a great deal on the target bitrate. I'd leave 16 kB in the
+% spec for now. fwiw more than 1k of comments is quite unusual.
+
+Our own design work indicates that the primary liability of the required header
+ is in mindshare; it is an unusual design and thus causes some amount of
+ complaint among engineers as this runs against current design trends and
+ points out limitations in some existing software/interface designs.
+However, we find that it does not fundamentally limit Theora's suitable
+ application space.
+
+%silvia: renamed
+%\subsection{Format Specification}
+\section{Format Conformance}
+
+The Theora format is well-defined by its decode specification; any encoder that
+ produces packets that are correctly decoded by an implementation following
+ this specification may be considered a proper Theora encoder.
+A decoder must faithfully and completely implement the specification defined
+ herein %, except where noted,
+ to be considered a conformant Theora decoder.
+A decoder need not be implemented strictly as described, but the
+ actual decoder process MUST be {\em entirely mathematically equivalent}
+ to the described process.
+Where appropriate, a non-normative description of encoder processes is
+ included.
+These sections will be marked as such, and a proper Theora encoder is not
+ bound to follow them.
+
+%TODO: \subsection{Hardware Profile}
+
+
+\chapter{Coded Video Structure}
+
+Theora's encoding and decoding process is based on $8\times 8$ blocks of
+ pixels.
+This sections describes how a video frame is laid out, divided into
+ blocks, and how those blocks are organized.
+
+\section{Frame Layout}
+
+A video frame in Theora is a two-dimensional array of pixels.
+Theora, like VP3, uses a right-handed coordinate system, with the origin in the
+ lower-left corner of the frame.
+This is contrary to many video formats which use a left-handed coordinate
+ system with the origin in the upper-left corner of the frame.
+%INT: This means that for interlaced material, the definition of `even fields'
+%INT: and `odd fields' may be reversed between Theora and other video codecs.
+%INT: This document will always refer to them as `top fields' and `bottom
+%INT: fields'.
+
+Theora divides the pixel array up into three separate \term{color planes}, one
+ for each of the $Y'$, $C_b$, and $C_r$ components of the pixel.
+The $Y'$ plane is also called the \term{luma plane}, and the $C_b$ and $C_r$
+ planes are also called the \term{chroma planes}.
+Each plane is assigned a numerical value, as shown in
+ Table~\ref{tab:color-planes}.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{cl}\toprule
+Index & Color Plane \\\midrule
+$0$ & $Y'$ \\
+$1$ & $C_b$ \\
+$2$ & $C_r$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Color Plane Indices}
+\label{tab:color-planes}
+\end{table}
+
+In some pixel formats, the chroma planes are subsampled by a factor of two
+ in one or both directions.
+This means that the width or height of the chroma planes may be half that of
+ the total frame width and height.
+The luma plane is never subsampled.
+
+\section{Picture Region}
+
+An encoded video frame in Theora is required to have a width and height that
+ are multiples of sixteen, making an integral number of blocks even when the
+ chroma planes are subsampled.
+However, inside a frame a smaller \term{picture region} may be defined
+ to present material whose dimensions are not a multiple of sixteen pixels, as
+ shown in Figure~\ref{fig:pic-frame}.
+The picture region can be offset from the lower-left corner of the frame by up
+ to 255 pixels in each direction, and may have an arbitrary width and height,
+ provided that it is contained entirely within the coded frame.
+It is this picture region that contains the actual video data.
+The portions of the frame which lie outside the picture region may contain
+ arbitrary image data, so the frame must be cropped to the picture region
+ before display.
+The picture region plays no other role in the decode process, which operates on
+ the entire video frame.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{pic-frame}
+\end{center}
+\caption{Location of frame and picture regions}
+\label{fig:pic-frame}
+\end{figure}
+
+\section{Blocks and Super Blocks}
+\label{sec:blocks-and-sbs}
+
+Each color plane is subdivided into \term{blocks} of $8\times 8$ pixels.
+Blocks are grouped into $4\times 4$ arrays called \term{super blocks} as
+ shown in Figure~\ref{fig:superblock}.
+Each color plane has its own set of blocks and super blocks.
+If the chroma planes are subsampled, they are still divided into $8\times 8$
+ blocks of pixels; there are just fewer blocks than in the luma plane.
+The boundaries of blocks and super blocks in the luma plane do not necessarily
+ coincide with those of the chroma planes, if the chroma planes have been
+ subsampled.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{superblock}
+\end{center}
+\caption{Subdivision of a frame into blocks and super blocks}
+\label{fig:superblock}
+\end{figure}
+
+Blocks are accessed in two different orders in the various decoder processes.
+The first is \term{raster order}, illustrated in Figure~\ref{fig:raster-block}.
+This accesses each block in row-major order, starting in the lower left of the
+ frame and continuing along the bottom row of the entire frame, followed by the
+ next row up, starting on the left edge of the frame, etc.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{raster-block}
+\end{center}
+\caption{Raster ordering of $n\times m$ blocks}
+\label{fig:raster-block}
+\end{figure}
+
+The second is \term{coded order}.
+In coded order, blocks are accessed by super block.
+Within each frame, super blocks are traversed in raster order,
+ similar to raster order for blocks.
+Within each super block, however, blocks are accessed in a Hilbert curve
+ pattern, illustrated in Figure~\ref{fig:hilbert-block}.
+If a color plane does not contain a complete super block on the top or right
+ sides, the same ordering is still used, simply with any blocks outside the
+ frame boundary ommitted.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{hilbert-block}
+\end{center}
+\caption{Hilbert curve ordering of blocks within a super block}
+\label{fig:hilbert-block}
+\end{figure}
+
+To illustrate this ordering, consider a frame that is 240 pixels wide and
+ 48 pixels high.
+Each row of the luma plane has 30 blocks and 8 super blocks, and there are 6
+ rows of blocks and two rows of super blocks.
+
+%When accessed in raster order, each block in the luma plane is assigned the
+% following indices:
+
+%\vspace{\baselineskip}
+%\begin{center}
+%\begin{tabular}{|ccccccc|}\hline
+%150 & 151 & 152 & 153 & $\ldots$ & 178 & 179 \\
+%120 & 121 & 122 & 123 & $\ldots$ & 148 & 149 \\\hline
+% 90 & 91 & 92 & 93 & $\ldots$ & 118 & 119 \\
+% 60 & 61 & 62 & 63 & $\ldots$ & 88 & 89 \\
+% 30 & 31 & 32 & 33 & $\ldots$ & 58 & 59 \\
+% 0 & 1 & 2 & 3 & $\ldots$ & 28 & 29 \\\hline
+%\end{tabular}
+%\end{center}
+%\vspace{\baselineskip}
+
+When accessed in coded order, each block in the luma plane is assigned the
+ following indices:
+
+\vspace{\baselineskip}
+\begin{center}
+\begin{tabular}{|cccc|c|cc|}\hline
+123 & 122 & 125 & 124 & $\ldots$ & 179 & 178 \\
+120 & 121 & 126 & 127 & $\ldots$ & 176 & 177 \\\hline
+ 5 & 6 & 9 & 10 & $\ldots$ & 117 & 118 \\
+ 4 & 7 & 8 & 11 & $\ldots$ & 116 & 119 \\
+ 3 & 2 & 13 & 12 & $\ldots$ & 115 & 114 \\
+ 0 & 1 & 14 & 15 & $\ldots$ & 112 & 113 \\\hline
+\end{tabular}
+\end{center}
+\vspace{\baselineskip}
+
+Here the index values specify the order in which the blocks would be accessed.
+The indices of the blocks are numbered continuously from one color plane to the
+ next.
+They do not reset to zero at the start of each plane.
+Instead, the numbering increases continuously from the $Y'$ plane to the $C_b$
+ plane to the $C_r$ plane.
+The implication is that the blocks from all planes are treated as a unit during
+ the various processing steps.
+
+Although blocks are sometimes accessed in raster order, in this document the
+ index associated with a block is {\em always} its index in coded order.
+
+\section{Macro Blocks}
+\label{sec:mbs}
+
+A macro block contains a $2\times 2$ array of blocks in the luma plane
+ {\em and} the co-located blocks in the chroma planes, as shown in
+ Figure~\ref{fig:macroblock}.
+Thus macro blocks can represent anywhere from six to twelve blocks, depending
+ on how the chroma planes are subsampled.
+This is in contrast to super blocks, which only contain blocks from a single
+ color plane.
+% the whole super vs. macro blocks thing is a little confusing, and it can be
+% hard to remember which is what initially. A figure would/will help here,
+% but I tried to add some text emphasizing the difference in terms of
+% functionality.
+%TBT: At this point we haven't described any functionality yet.
+%TBT: As far as the reader knows, the only purpose of the blocks, macro blocks
+%TBT: and super blocks is for data organization---and for blocks and super
+%TBT: blocks, this is essentially true.
+%TBT: So lets restrict the differences we emphasize to those of data
+%TBT: organization, which the sentence I just added above does.
+Macro blocks contain information about coding mode and motion vectors for the
+ corresponding blocks in all color planes.
+
+\begin{figure}[htbp]
+ \begin{center}
+ \includegraphics{macroblock}
+ \end{center}
+ \caption{Subdivision of a frame into macro blocks}
+ \label{fig:macroblock}
+\end{figure}
+
+Macro blocks are also accessed in a \term{coded order}.
+This coded order proceeds by examining each super block in the luma plane in
+ raster order, and traversing the four macro blocks inside using a smaller
+ Hilbert curve, as shown in Figure~\ref{fig:hilbert-mb}.
+%r: I rearranged the wording to make a more formal idiom here
+If the luma plane does not contain a complete super block on the top or right
+ sides, the same ordering is still used, with any macro blocks outside
+ the frame boundary simply omitted.
+Because the frame size is constrained to be a multiple of 16, there are never
+ any partial macro blocks.
+Unlike blocks, macro blocks need never be accessed in a pure raster order.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{hilbert-mb}
+\end{center}
+\caption{Hilbert curve ordering of macro blocks within a super block}
+\label{fig:hilbert-mb}
+\end{figure}
+
+Using the same frame size as the example above, there are 15 macro blocks in
+ each row and 3 rows of macro blocks.
+The macro blocks are assigned the following indices:
+
+\vspace{\baselineskip}
+\begin{center}
+\begin{tabular}{|cc|cc|c|cc|c|}\hline
+30 & 31 & 32 & 33 & $\cdots$ & 42 & 43 & 44 \\\hline
+ 1 & 2 & 5 & 6 & $\cdots$ & 25 & 26 & 29 \\
+ 0 & 3 & 4 & 7 & $\cdots$ & 24 & 27 & 28 \\\hline
+\end{tabular}
+\end{center}
+\vspace{\baselineskip}
+
+\section{Coding Modes and Prediction}
+
+Each block is coded using one of a small, fixed set of \term{coding modes} that
+ define how the block is predicted from previous frames.
+A block is predicted using one of two \term{reference frames}, selected
+ according to the coding mode.
+A reference frame is the fully decoded version of a previous frame in the
+ stream.
+The first available reference frame is the previous intra frame, called the
+ \term{golden frame}.
+The second available reference frame is the previous frame, whether it was an
+ intra frame or an inter frame.
+If the previous frame was an intra frame, then both reference frames are the
+ same.
+See Figure~\ref{fig:reference-frames} for an illustration of the reference
+ frames used for an intra frame that does not follow an intra frame.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{reference-frames}
+\end{center}
+\caption{Example of reference frames for an inter frame}
+\label{fig:reference-frames}
+\end{figure}
+
+Two coding modes in particular are worth mentioning here.
+The INTRA mode is used for blocks that are not predicted from either reference
+ frame.
+This is the only coding mode allowed in intra frames.
+The INTER\_NOMV coding mode uses the co-located contents of the block in the
+ previous frame as the predictor.
+This is the default coding mode.
+
+\section{DCT Coefficients}
+\label{sec:dct-coeffs}
+
+A \term{residual} is added to the predicted contents of a block to form the
+ final reconstruction.
+The residual is stored as a set of quantized coefficients from an integer
+ approximation of a two-dimensional Type II Discrete Cosine Transform.
+The DCT takes an $8\times 8$ array of pixel values as input and returns an
+ $8\times 8$ array of coefficient values.
+The \term{natural ordering} of these coefficients is defined to be row-major
+ order, from lowest to highest frequency.
+They are also often indexed in \term{zig-zag order}, as shown in
+ Figure~\ref{tab:zig-zag}.
+
+\begin{figure}[htbp]
+\begin{center}
+\begin{tabular}[c]{rr|c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c@{}c}
+ &\multicolumn{1}{r}{} & && &&&&&$c$&&& && && \\
+ &\multicolumn{1}{r}{} &0&&1&&2&&3&&4&&5&&6&&7 \\\cline{3-17}
+ &0 & 0 &$\rightarrow$& 1 && 5 &$\rightarrow$& 6 && 14 &$\rightarrow$& 15 && 27 &$\rightarrow$& 28 \\[-0.5\defaultaddspace]
+ & & &$\swarrow$&&$\nearrow$& &$\swarrow$&&$\nearrow$& &$\swarrow$&&$\nearrow$& &$\swarrow$& \\
+ &1 & 2 & & 4 && 7 & & 13 && 16 & & 26 && 29 & & 42 \\[-0.5\defaultaddspace]
+ & &$\downarrow$&$\nearrow$&&$\swarrow$&&$\nearrow$&&$\swarrow$&&$\nearrow$&&$\swarrow$&&$\nearrow$&$\downarrow$ \\
+ &2 & 3 & & 8 && 12 & & 17 && 25 & & 30 && 41 & & 43 \\[-0.5\defaultaddspace]
+ & & &$\swarrow$&&$\nearrow$& &$\swarrow$&&$\nearrow$& &$\swarrow$&&$\nearrow$& &$\swarrow$& \\
+ &3 & 9 & & 11 && 18 & & 24 && 31 & & 40 && 44 & & 53 \\[-0.5\defaultaddspace]
+$r$&&$\downarrow$&$\nearrow$&&$\swarrow$&&$\nearrow$&&$\swarrow$&&$\nearrow$&&$\swarrow$&&$\nearrow$&$\downarrow$ \\
+ &4 & 10 & & 19 && 23 & & 32 && 39 & & 45 && 52 & & 54 \\[-0.5\defaultaddspace]
+ & & &$\swarrow$&&$\nearrow$& &$\swarrow$&&$\nearrow$& &$\swarrow$&&$\nearrow$& &$\swarrow$& \\
+ &5 & 20 & & 22 && 33 & & 38 && 46 & & 51 && 55 & & 60 \\[-0.5\defaultaddspace]
+ & &$\downarrow$&$\nearrow$&&$\swarrow$&&$\nearrow$&&$\swarrow$&&$\nearrow$&&$\swarrow$&&$\nearrow$&$\downarrow$ \\
+ &6 & 21 & & 34 && 37 & & 47 && 50 & & 56 && 59 & & 61 \\[-0.5\defaultaddspace]
+ & & &$\swarrow$&&$\nearrow$& &$\swarrow$&&$\nearrow$& &$\swarrow$&&$\nearrow$& &$\swarrow$& \\
+ &7 & 35 &$\rightarrow$& 36 && 48 &$\rightarrow$& 49 && 57 &$\rightarrow$& 58 && 62 &$\rightarrow$& 63
+\end{tabular}
+\end{center}
+\caption{Zig-zag order}
+\label{tab:zig-zag}
+\end{figure}
+
+\begin{verse}
+{\bf Note:} the row and column indices refer to {\em frequency number} and not
+ pixel locations.
+The frequency numbers are defined independently of the memory organization of
+ the pixels.
+They have been written from top to bottom here to follow conventional notation,
+ despite the right-handed coordinate system Theora uses for pixel locations.
+%RG: I'd rather we were internally consistent and put dc at the lower left.
+Many implementations of the DCT operate `in-place'.
+That is, they return DCT coefficients in the same memory buffer that the
+ initial pixel values were stored in.
+Due to the right-handed coordinate system used for pixel locations in Theora,
+ one must note carefully how both pixel values and DCT coefficients are
+ organized in memory in such a system.
+\end{verse}
+
+DCT coefficient $(0,0)$ is called the \term{DC coefficient}.
+All the other coefficients are called \term{AC coefficients}.
+
+
+\chapter{Decoding Overview}
+
+This section provides a high level description of the Theora codec's
+ construction.
+A bit-by-bit specification appears beginning in Section~\ref{sec:bitpacking}.
+The later sections assume a high-level understanding of the Theora decode
+ process, which is provided below.
+
+\section{Decoder Configuration}
+
+Decoder setup consists of configuration of the quantization matrices and the
+ Huffman codebooks for the DCT coefficients, and a table of limit values for
+ the deblocking filter.
+The remainder of the decoding pipeline is not configurable.
+
+\subsection{Global Configuration}
+
+The global codec configuration consists of a few video related fields, such as
+ frame rate, frame size, picture size and offset, aspect ratio, color space,
+ pixel format, and a version number.
+The version number is divided into a major version, a minor version, amd a
+ minor revision number.
+%r: afaik the released vp3 codec called itself 3.1 and is compatible w/ theora
+%r: even though we received the in-progress 3.2 codebase
+For the format defined in this specification, these are `3', `2', and
+ `1', respectively, in reference to Theora's origin as a successor to
+ the VP3.1 format.
+
+\subsection{Quantization Matrices}
+
+Theora allows up to 384 different quantization matrices to be defined, one for
+ each \term{quantization type}, \term{color plane} ($Y'$, $C_b$, or $C_r$), and
+ \term{quantization index}, \qi, which ranges from zero to 63, inclusive.
+There are currently two quantization types defined, which depend on the coding
+ mode of the block being dequantized, as shown in Table~\ref{tab:quant-types}.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{cl}\toprule
+Quantization Type & Usage \\\midrule
+$0$ & INTRA-mode blocks \\
+$1$ & Blocks in any other mode. \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Quantization Type Indices}
+\label{tab:quant-types}
+\end{table}
+
+%r: I think 'nominally' is more specific than 'generally' here
+The quantization index, on the other hand, nominally represents a progressive
+ range of quality levels, from low quality near zero to high quality near 63.
+However, the interpretation is arbitrary, and it is possible, for example, to
+ partition the scale into two completely separate ranges with 32 levels each
+ that are meant to represent different classes of source material, or any
+ other arrangement that suits the encoder's requirements.
+
+Each quantization matrix is an $8\times 8$ matrix of 16-bit values, which is
+ used to quantize the output of the $8\times 8$ DCT\@.
+Quantization matrices are specified using three components: a
+ \term{base matrix} and two \term{scale values}.
+The first scale value is the \term{DC scale}, which is applied to the DC
+ component of the base matrix.
+The second scale value is the \term{AC scale}, which is applied to all the
+ other components of the base matrix.
+There are 64 DC scale values and 64 AC scale values, one for each \qi\ value.
+
+There are 64 elements in each base matrix, one for each DCT coefficient.
+They are stored in natural order (cf. Section~\ref{sec:dct-coeffs}).
+There is a separate set of base matrices for each quantization type and each
+ color plane, with up to 64 possible base matrices in each set, one for each
+ \qi\ value.
+%r: we will mention that the given matricies must bound the \qi range
+%r: in the detailed section. it's not important at this level.
+Typically the bitstream contains matrices for only a sparse subset of the
+ possible \qi\ values.
+The base matrices for the remainder of the \qi\ values are computed using
+ linear interpolation.
+This configuration allows the encoder to adjust the quantization matrices to
+ approximate the complex, non-linear response of the human visual system to
+ different quantization errors.
+
+Finally, because the in-loop deblocking filter strength depends on the strength
+ of the quantization matrices defined in this header, a table of 64 \term{loop
+ filter limit values} is defined, one for each \qi\ value.
+
+The precise specification of how all of this information is decoded appears in
+ Section~\ref{sub:loop-filter-limits} and Section~\ref{sub:quant-params}.
+
+\subsection{Huffman Codebooks}
+
+Theora uses 80 configurable binary Huffman codes to represent the 32 tokens
+ used to encode DCT coefficients.
+Each of the 32 token values has a different semantic meaning and is used to
+ represent single coefficient values, zero runs, combinations of the two, and
+ \term{End-Of-Block markers}.
+
+The 80 codes are divided up into five groups of 16, with each group
+ corresponding to a set of DCT coefficient indices.
+The first group corresponds to the DC coefficient, while the remaining four
+ groups correspond to different subsets of the AC coefficients.
+Within each frame, two pairs of 4-bit codebook indices are stored.
+The first pair selects which codebooks to use from the DC coefficient group for
+ the $Y'$ coefficients and the $C_b$ and $C_r$ coefficients.
+The second pair selects which codebooks to use from {\em all four} of the AC
+ coefficient groups for the $Y'$ coefficients and the $C_b$ and $C_r$
+ coefficients.
+
+The precise specification of how the codebooks are decoded appears in
+ Section~\ref{sub:huffman-tables}.
+
+\section{High-Level Decode Process}
+
+\subsection{Decoder Setup}
+
+Before decoding can begin, a decoder MUST be initialized using the bitstream
+ headers corresponding to the stream to be decoded.
+Theora uses three header packets; all are required, in order, by this
+ specification.
+Once set up, decode may begin at any intra-frame packet---or even inter-frame
+ packets, provided the appropriate decoded reference frames have already been
+ decoded and cached---belonging to the Theora stream.
+In Theora I, all packets after the three initial headers are intra-frame or
+ inter-frame packets.
+
+The header packets are, in order, the identification header, the comment
+ header, and the setup header.
+
+\paragraph{Identification Header}
+
+The identification header identifies the stream as Theora, provides a version
+ number, and defines the characteristics of the video stream such as frame
+ size.
+A complete description of the identification header appears in
+ Section~\ref{sec:idheader}.
+
+\paragraph{Comment Header}
+
+The comment header includes user text comments (`tags') and a vendor string
+ for the application/library that produced the stream.
+The format of the comment header is the same as that used in the Vorbis I and
+ Speex codecs, with slight modifications due to the use of a different bit
+ packing mechanism.
+A complete description of how the comment header is coded appears in
+ Section~\ref{sec:commentheader}, along with a suggested set of tags.
+
+\paragraph{Setup Header}
+
+The setup header includes extensive codec setup information, including the
+ complete set of quantization matrices and Huffman codebooks needed to decode
+ the DCT coefficients.
+A complete description of the setup header appears in
+ Section~\ref{sec:setupheader}.
+
+\subsection{Decode Procedure}
+
+The decoding and synthesis procedure for all video packets is fundamentally the
+ same, with some steps omitted for intra frames.
+\begin{itemize}
+\item
+Decode packet type flag.
+\item
+Decode frame header.
+\item
+Decode coded block information (inter frames only).
+\item
+Decode macro block mode information (inter frames only).
+\item
+Decode motion vectors (inter frames only).
+\item
+Decode block-level \qi\ information.
+\item
+Decode DC coefficient for each coded block.
+\item
+Decode 1st AC coefficient for each coded block.
+\item
+Decode 2nd AC coefficient for each coded block.
+\item
+$\ldots$
+\item
+Decode 63rd AC coefficient for each coded block.
+\item Perform DC coefficient prediction.
+\item Reconstruct coded blocks.
+\item Copy uncoded bocks.
+\item Perform loop filtering.
+\end{itemize}
+
+\begin{verse}
+{\bf Note:} clever rearrangement of the steps in this process is possible.
+As an example, in a memory-constrained environment, one can make multiple
+ passes through the DCT coefficients to avoid buffering them all in memory.
+On the first pass, the starting location of each coefficient is identified, and
+ then 64 separate get pointers are used to read in the 64 DCT coefficients
+ required to reconstruct each coded block in sequence.
+This operation produces entirely equivalent output and is naturally perfectly
+ legal.
+It may even be a benefit in non-memory-constrained environments due to a
+ reduced cache footprint.
+\end{verse}
+
+Theora makes equivalence easy to check by defining all decoding operations in
+ terms of exact integer operations.
+No floating-point math is required, and in particular, the implementation of
+ the iDCT transform MUST be followed precisely.
+This prevents the decoder mismatch problem commonly associated with codecs that
+ provide a less rigorous transform specification.
+Such a mismatch problem would be devastating to Theora, since a single rounding
+ error in one frame could propagate throughout the entire succeeding frame due
+ to DC prediction.
+
+\paragraph{Packet Type Decode}
+
+Theora uses four packet types.
+The first three packet types mark each of the three Theora headers described
+ above.
+The fourth packet type marks a video packet.
+All other packet types are reserved; packets marked with a reserved type should
+ be ignored.
+
+Additionally, zero-length packets are treated as if they were an inter
+frame with no blocks coded. That is, as a duplicate frame.
+
+\paragraph{Frame Header Decode}
+
+The frame header contains some global information about the current frame.
+The first is the frame type field, which specifies if this is an intra frame or
+ an inter frame.
+Inter frames predict their contents from previously decoded reference frames.
+Intra frames can be independently decoded with no established reference frames.
+
+The next piece of information in the frame header is the list of \qi\ values
+ allowed in the frame.
+Theora allows from one to three different \qi\ values to be used in a single
+ frame, each of which selects a set of six quantization matrices, one for each
+ quantization type (inter or intra), and one for each color plane.
+The first \qi\ value is {\em always} used when dequantizing DC coefficients.
+The \qi\ value used when dequantizing AC coefficients, however, can vary from
+ block to block.
+VP3, in contrast, only allows a single \qi\ value per frame for both the DC and
+ AC coefficients.
+
+\paragraph{Coded Block Information}
+
+This stage determines which blocks in the frame are coded and which are
+ uncoded.
+A \term{coded block list} is constructed which lists all the coded blocks in
+ coded order.
+For intra frames, every block is coded, and so no data needs to be read from
+ the packet.
+
+\paragraph{Macro Block Mode Information}
+
+For intra frames, every block is coded in INTRA mode, and this stage is
+ skipped.
+In inter frames a \term{coded macro block list} is constructed from the coded
+ block list.
+Any macro block which has at least one of its luma blocks coded is considered
+ coded; all other macro blocks are uncoded, even if they contain coded chroma
+ blocks.
+A coding mode is decoded for each coded macro block, and assigned to all its
+ constituent coded blocks.
+All coded chroma blocks in uncoded macro blocks are assigned the INTER\_NOMV
+ coding mode.
+
+\paragraph{Motion Vectors}
+
+Intra frames are coded entirely in INTRA mode, and so this stage is skipped.
+Some inter coding modes, however, require one or more motion vectors to be
+ specified for each macro block.
+These are decoded in this stage, and an appropriate motion vector is assigned
+ to each coded block in the macro block.
+
+\paragraph{Block-Level \qi\ Information}
+
+If a frame allows multiple \qi\ values, the \qi\ value assigned to each block
+ is decoded here.
+Frames that use only a single \qi\ value have nothing to decode.
+
+\paragraph{DCT Coefficients}
+
+Finally, the quantized DCT coefficients are decoded.
+A list of DCT coefficients in zig-zag order for a single block is represented
+ by a list of tokens.
+A token can take on one of 32 different values, each with a different semantic
+ meaning.
+A single token can represent a single DCT coefficient, a run of zero
+ coefficients within a single block, a combination of a run of zero
+ coefficients followed by a single non-zero coefficient, an
+ \term{End-Of-Block marker}, or a run of EOB markers.
+EOB markers signify that the remainder of the block is one long zero run.
+Unlike JPEG and MPEG, there is no requirement for each block to end with
+ a special marker.
+If non-EOB tokens yield values for all 64 of the coefficients in a block, then
+ no EOB marker occurs.
+
+Each token is associated with a specific \term{token index} in a block.
+For single-coefficient tokens, this index is the zig-zag index of the token in
+ the block.
+For zero-run tokens, this index is the zig-zag index of the {\em first}
+ coefficient in the run.
+For combination tokens, the index is again the zig-zag index of the first
+ coefficient in the zero run.
+For EOB markers, which signify that the remainder of the block is one long zero
+ run, the index is the zig-zag index of the first zero coefficient in that run.
+For EOB runs, the token index is that of the first EOB marker in the run.
+Due to zero runs and EOB markers, a block does not have to have a token for
+ every zig-zag index.
+
+Tokens are grouped in the stream by token index, not by the block they
+ originate from.
+This means that for each zig-zag index in turn, the tokens with that index from
+ {\em all} the coded blocks are coded in coded block order.
+When decoding, a current token index is maintained for each coded block.
+This index is advanced by the number of coefficients that are added to the
+ block as each token is decoded.
+After fully decoding all the tokens with token index \ti, the current token
+ index of every coded block will be \ti\ or greater.
+
+If an EOB run of $n$ blocks is decoded at token index \ti, then it ends the
+ next $n$ blocks in coded block order whose current token index is equal to
+ \ti, but not greater.
+If there are fewer than $n$ blocks with a current token index of \ti, then the
+ decoder goes through the coded block list again from the start, ending blocks
+ with a current token index of $\ti+1$, and so on, until $n$ blocks have been
+ ended.
+
+Tokens are read by parsing a Huffman code that depends on \ti\ and the color
+ plane of the next coded block whose current token index is equal to \ti, but
+ not greater.
+The Huffman codebooks are selected on a per-frame basis from the 80 codebooks
+ defined in the setup header.
+Many tokens have a fixed number of \term{extra bits} associated with them.
+These bits are read from the packet immediately after the token is decoded.
+These are used to define things such as coefficient magnitude, sign, and the
+ length of runs.
+
+\paragraph{DC Prediction}
+
+After the coefficients for each block are decoded, the quantized DC value of
+ each block is adjusted based on the DC values of its neighbors.
+This adjustment is performed by scanning the blocks in raster order, not coded
+ block order.
+
+\paragraph{Reconstruction}
+
+Finally, using the coding mode, motion vector (if applicable), quantized
+ coefficient list, and \qi\ value defined for each block, all the coded blocks
+ are reconstructed.
+The DCT coefficients are dequantized, an inverse DCT transform is applied, and
+ the predictor is formed from the coding mode and motion vector and added to
+ the result.
+
+\paragraph{Loop Filtering}
+
+To complete the reconstructed frame, an ``in-loop'' deblocking filter is
+ applied to the edges of all coded blocks.
+
+
+\chapter{Video Formats}
+
+This section gives a precise description of the video formats that Theora is
+ capable of storing.
+The Theora bitstream is capable of handling video at any arbitrary resolution
+ up to $1048560\times 1048560$.
+Such video would require almost three terabytes of storage per frame for
+ uncompressed data, so compliant decoders MAY refuse to decode images with
+ sizes beyond their capabilities.
+%TODO: What MUST a "compliant" decoder accept?
+%TODO: What SHOULD a decoder use for an upper bound? (derive from total amount
+%TODO: of memory and memory bandwidth)
+%TODO: Any lower limits?
+%TODO: We really need hardware device profiles, but such things should be
+%TODO: developed with input from the hardware community.
+%TODO: And even then sometimes they're useless
+
+The remainder of this section talks about two specific aspects of the video
+ format: the color space and the pixel format.
+The first describes how color is represented and how to transform that color
+ representation into a device independent color space such as CIE $XYZ$ (1931).
+The second describes the various schemes for sampling the color values in time
+ and space.
+
+\section{Color Space Conventions}
+
+There are a large number of different color standards used in digital video.
+Since Theora is a lossy codec, it restricts itself to only a few of them to
+ simplify playback.
+Unlike the alternate method of describing all the parameters of the color
+ model, this allows a few dedicated routines for color conversion to be written
+ and heavily optimized in a decoder.
+More flexible conversion functions should instead be specified in an encoder,
+ where additional computational complexity is more easily tolerated.
+The color spaces were selected to give a fair representation of color standards
+ in use around the world today.
+Most of the standards that do not exactly match one of these can be converted
+ to one fairly easily.
+
+All Theora color spaces are $Y'C_bC_r$ color spaces with one luma channel and
+ two chroma channels.
+Each channel contains 8-bit discrete values in the range $0\ldots255$, which
+ represent non-linear gamma pre-corrected signals.
+The Theora identification header contains an 8-bit value that describes the
+ color space.
+This merely selects one of the color spaces available from an enumerated list.
+Currently, only two color spaces are defined, with a third possibility that
+ indicates the color space is ``unknown".
+
+\section{Color Space Conversions and Parameters}
+\label{sec:color-xforms}
+
+The parameters which describe the conversions between each color space are
+ listed below.
+These are the parameters needed to map colors from the encoded $Y'C_bC_r$
+ representation to the device-independent color space CIE $XYZ$ (1931).
+These parameters define abstract mathematical conversion functions which are
+ infinitely precise.
+The accuracy and precision with which the conversions are performed in a real
+ system is determined by the quality of output desired and the available
+ processing power.
+Exact decoder output is defined by this specification only in the original
+ $Y'C_bC_r$ space.
+
+\begin{description}
+\item[$Y'C_bC_r$ to $Y'P_bP_r$:]
+\vspace{\baselineskip}\hfill
+
+This conversion takes 8-bit discrete values in the range $[0\ldots255]$ and
+ maps them to real values in the range $[0\ldots1]$ for Y and
+ $[-\frac{1}{2}\ldots\frac{1}{2}]$ for $P_b$ and $P_r$.
+Because some values may fall outside the offset and excursion defined for each
+ channel in the $Y'C_bC_r$ space, the results may fall outside these ranges in
+ $Y'P_bP_r$ space.
+No clamping should be done at this stage.
+
+\begin{align}
+Y'_\mathrm{out} & =
+ \frac{Y'_\mathrm{in}-\mathrm{Offset}_Y}{\mathrm{Excursion}_Y} \\
+P_b & =
+ \frac{C_b-\mathrm{Offset}_{C_b}}{\mathrm{Excursion}_{C_b}} \\
+P_r & =
+ \frac{C_r-\mathrm{Offset}_{C_r}}{\mathrm{Excursion}_{C_r}}
+\end{align}
+
+Parameters: $\mathrm{Offset}_{Y,C_b,C_r}$, $\mathrm{Excursion}_{Y,C_b,C_r}$.
+
+\item[$Y'P_bP_r$ to $R'G'B'$:]
+\vspace{\baselineskip}\hfill
+
+This conversion takes the one luma and two chroma channel representation and
+ maps it to the non-linear $R'G'B'$ space used to drive actual output devices.
+Values should be clamped into the range $[0\ldots1]$ after this stage.
+
+\begin{align}
+R' & = Y'+2(1-K_r)P_r \\
+G' & = Y'-2\frac{(1-K_b)K_b}{1-K_b-K_r}P_b-2\frac{(1-K_r)K_r}{1-K_b-K_r}P_r\\
+B' & = Y'+2(1-K_b)P_b
+\end{align}
+
+Parameters: $K_b,K_r$.
+
+\item[$R'G'B'$ to $RGB$ (Output device gamma correction):]
+\vspace{\baselineskip}\hfill
+
+This conversion takes the non-linear $R'G'B'$ voltage levels and maps them to
+ linear light levels produced by the actual output device.
+Note that this conversion is only that of the output device, and its inverse is
+ {\em not} that used by the input device.
+Because a dim viewing environment is assumed in most television standards, the
+ overall gamma between the input and output devices is usually around $1.1$ to
+ $1.2$, and not a strict $1.0$.
+
+For calibration with actual output devices, the model
+\begin{align}
+L & =(E'+\Delta)^\gamma
+\end{align}
+ should be used, with $\Delta$ the free parameter and $\gamma$ held fixed to
+ the value specified in this document.
+The conversion function presented here is an idealized version with $\Delta=0$.
+
+\begin{align}
+R & = R'^\gamma \\
+G & = G'^\gamma \\
+B & = B'^\gamma
+\end{align}
+
+Parameters: $\gamma$.
+
+\item[$RGB$ to $R'G'B'$ (Input device gamma correction):]
+\vspace{\baselineskip}\hfill
+
+%TODO: Tag section as non-normative
+
+This conversion takes linear light levels and maps them to the non-linear
+ voltage levels produced in the actual input device.
+This information is merely informative.
+It is not required for building a decoder or for converting between the various
+ formats and the actual output capabilities of a particular device.
+
+A linear segment is introduced on the low end to reduce noise in dark areas of
+ the image.
+The rest of the scale is adjusted so that the power segment of the curve
+ intersects the linear segment with the proper slope, and so that it still maps
+ 0 to 0 and 1 to 1.
+
+\begin{align}
+R' & = \left\{
+\begin{array}{ll}
+\alpha R, & 0\le R<\delta \\
+(1+\epsilon)R^\beta-\epsilon, & \delta\le R\le1
+\end{array}\right. \\
+G' & = \left\{
+\begin{array}{ll}
+\alpha G, & 0\le G<\delta \\
+(1+\epsilon)G^\beta-\epsilon, & \delta\le G\le1
+\end{array}\right. \\
+B' & = \left\{
+\begin{array}{ll}
+\alpha B, & 0\le B<\delta \\
+(1+\epsilon)B^\beta-\epsilon, & \delta\le B\le1
+\end{array}\right.
+\end{align}
+
+Parameters: $\beta$, $\alpha$, $\delta$, $\epsilon$.
+
+\item[$RGB$ to CIE $XYZ$ (1931):]
+\vspace{\baselineskip}\hfill
+
+This conversion maps a device-dependent linear RGB space to the
+ device-independent linear CIE $XYZ$ space.
+The parameters are the CIE chromaticity coordinates of the three
+ primaries---red, green, and blue---as well as the chromaticity coordinates
+ of the white point of the device.
+This is how hardware manufacturers and standards typically describe a
+ particular $RGB$ space.
+The math required to convert these parameters into a useful transformation
+ matrix is reproduced below.
+
+\begin{align}
+F & =
+\left[\begin{array}{ccc}
+\frac{x_r}{y_r} & \frac{x_g}{y_g} & \frac{x_b}{y_b} \\
+1 & 1 & 1 \\
+\frac{1-x_r-y_r}{y_r} & \frac{1-x_g-y_g}{y_g} & \frac{1-x_b-y_b}{y_b}
+\end{array}\right] \\
+\left[\begin{array}{c}
+s_r \\
+s_g \\
+s_b
+\end{array}\right] & =
+F^{-1}\left[\begin{array}{c}
+\frac{x_w}{y_w} \\
+1 \\
+\frac{1-x_w-y_w}{y_w}
+\end{array}\right] \\
+\left[\begin{array}{c}
+X \\
+Y \\
+Z
+\end{array}\right] & =
+F\left[\begin{array}{c}
+s_rR \\
+s_gG \\
+s_bB
+\end{array}\right]
+\end{align}
+Parameters: $x_r,x_g,x_b,x_w, y_r,y_g,y_b,y_w$.
+
+\end{description}
+
+\section{Available Color Spaces}
+\label{sec:colorspaces}
+
+These are the color spaces currently defined for use by Theora video.
+Each one has a short name, with which it is referred to in this document, and
+ a more detailed specification of the standards from which its parameters are
+ derived.
+Some standards do not specify all the parameters necessary.
+For these unspecified parameters, this document serves as the definition of
+ what should be used when encoding or decoding Theora video.
+
+\subsection{Rec.~470M (Rec.~ITU-R~BT.470-6 System M/NTSC with
+ Rec.~ITU-R~BT.601-5)}
+\label{sec:470m}
+
+This color space is used by broadcast television and DVDs in much of the
+ Americas, Japan, Korea, and the Union of Myanmar \cite{rec470}.
+This color space may also be used for System M/PAL (Brazil), with an
+ appropriate conversion supplied by the encoder to compensate for the
+ different gamma value.
+See Section~\ref{sec:470bg} for an appropriate gamma value to assume for M/PAL
+ input.
+
+In the US, studio monitors are adjusted to a D65 white point
+ ($x_w,y_w=0.313,0.329$).
+In Japan, studio monitors are adjusted to a D white of 9300K
+ ($x_w,y_w=0.285,0.293$).
+
+Rec.~470 does not specify a digital encoding of the color signals.
+For Theora, Rec.~ITU-R~BT.601-5 \cite{rec601} is used, starting from the
+ $R'G'B'$ signals specified by Rec.~470.
+
+Rec.~470 does not specify an input gamma function.
+For Theora, the Rec.~709 \cite{rec709} input function is assumed.
+This is the same as that specified by SMPTE 170M \cite{smpte170m}, which claims
+ to reflect modern practice in the creation of NTSC signals circa 1994.
+
+The parameters for all the color transformations defined in
+ Section~\ref{sec:color-xforms} are given in Table~\ref{tab:470m}.
+
+\begin{table}[htb]
+\begin{align*}
+\mathrm{Offset}_{Y,C_b,C_r} & = (16, 128, 128) \\
+\mathrm{Excursion}_{Y,C_b,C_r} & = (219, 224, 224) \\
+K_r & = 0.299 \\
+K_b & = 0.114 \\
+\gamma & = 2.2 \\
+\beta & = 0.45 \\
+\alpha & = 4.5 \\
+\delta & = 0.018 \\
+\epsilon & = 0.099 \\
+x_r,y_r & = 0.67, 0.33 \\
+x_g,y_g & = 0.21, 0.71 \\
+x_b,y_b & = 0.14, 0.08 \\
+\text{(Illuminant C) } x_w,y_w & = 0.310, 0.316 \\
+\end{align*}
+\caption{Rec.~470M Parameters}
+\label{tab:470m}
+\end{table}
+
+\subsection{Rec.~470BG (Rec.~ITU-R~BT.470-6 Systems B and G with
+ Rec.~ITU-R~BT.601-5)}
+\label{sec:470bg}
+
+This color space is used by the PAL and SECAM systems in much of the rest of
+ the world \cite{rec470}
+This can be used directly by systems (B, B1, D, D1, G, H, I, K, N)/PAL and (B,
+ D, G, H, K, K1, L)/SECAM\@.
+
+\begin{verse}
+{\bf Note:} the Rec.~470BG chromaticity values are different from those
+ specified in Rec.~470M\@.
+When PAL and SECAM systems were first designed, they were based upon the same
+ primaries as NTSC\@.
+However, as methods of making color picture tubes have changed, the primaries
+ used have changed as well.
+The U.S. recommends using correction circuitry to approximate the existing,
+ standard NTSC primaries.
+Current PAL and SECAM systems have standardized on primaries in accord with
+ more recent technology.
+\end{verse}
+
+Rec.~470 provisionally permits the use of the NTSC chromaticity values (given
+ in Section~\ref{sec:470m}) with legacy PAL and SECAM equipment.
+In Theora, material must be decoded assuming the new PAL and SECAM primaries.
+Material intended for display on old legacy devices should be converted by the
+ decoder.
+
+The official Rec.~470BG specifies a gamma value of $\gamma=2.8$.
+However, in practice this value is unrealistically high \cite{Poyn97}.
+Rec.~470BG states that the overall system gamma should be approximately
+ $\gamma\beta=1.2$.
+Since most cameras pre-correct with a gamma value of $\beta=0.45$,
+ this suggests an output device gamma of approximately $\gamma=2.67$.
+This is the value recommended for use with PAL systems in Theora.
+
+Rec.~470 does not specify a digital encoding of the color signals.
+For Theora, Rec.~ITU-R~BT.601-5 \cite{rec601} is used, starting from the
+ $R'G'B'$ signals specified by Rec.~470.
+
+Rec.~470 does not specify an input gamma function.
+For Theora, the Rec 709 \cite{rec709} input function is assumed.
+
+The parameters for all the color transformations defined in
+ Section~\ref{sec:color-xforms} are given in Table~\ref{tab:470bg}.
+
+\begin{table}[htb]
+\begin{align*}
+\mathrm{Offset}_{Y,C_b,C_r} & = (16, 128, 128) \\
+\mathrm{Excursion}_{Y,C_b,C_r} & = (219, 224, 224) \\
+K_r & = 0.299 \\
+K_b & = 0.114 \\
+\gamma & = 2.67 \\
+\beta & = 0.45 \\
+\alpha & = 4.5 \\
+\delta & = 0.018 \\
+\epsilon & = 0.099 \\
+x_r,y_r & = 0.64, 0.33 \\
+x_g,y_g & = 0.29, 0.60 \\
+x_b,y_b & = 0.15, 0.06 \\
+\text{(D65) } x_w,y_w & = 0.313, 0.329 \\
+\end{align*}
+\caption{Rec.~470BG Parameters}
+\label{tab:470bg}
+\end{table}
+
+\section{Pixel Formats}
+\label{sec:pixfmts}
+
+Theora supports several different pixel formats, each of which uses different
+ subsampling for the chroma planes relative to the luma plane.
+A decoder may need to recover a full resolution chroma plane with samples
+ co-sited with the luma plane in order to convert to RGB for display or perform
+ other processing.
+Decoders can assume that the chroma signal satisfies the Nyquist-Shannon
+ sampling theorem.
+The ideal low-pass reconstruction filter this implies is not practical, but any
+ suitable approximation can be used, depending on the available computing
+ power.
+Decoders MAY simply use a box filter, assigning to each luma sample the chroma
+ sample closest to it.
+Encoders would not go wrong in assuming that this will be the most common
+ approach.
+
+\subsection{4:4:4 Subsampling}
+\label{sec:444}
+
+All three color planes are stored at full resolution---each pixel has a $Y'$,
+ a $C_b$ and a $C_r$ value (see Figure~\ref{fig:pixel444}).
+The samples in the different planes are all at co-located sites.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{pixel444}
+\end{center}
+\caption{Pixels encoded 4:4:4}
+\label{fig:pixel444}
+\end{figure}
+
+% Figure.
+%YRB YRB
+%
+%
+%
+%YRB YRB
+%
+%
+%
+
+
+\subsection{4:2:2 Subsampling}
+\label{sec:422}
+
+The $C_b$ and $C_r$ planes are stored with half the horizontal resolution of
+ the $Y'$ plane.
+Thus, each of these planes has half the number of horizontal blocks as the luma
+ plane (see Figure~\ref{fig:pixel422}).
+Similarly, they have half the number of horizontal super blocks, rounded up.
+Macro blocks are defined across color planes, and so their number does not
+ change, but each macro block contains half as many chroma blocks.
+
+The chroma samples are vertically aligned with the luma samples, but
+ horizontally centered between two luma samples.
+Thus, each luma sample has a unique closest chroma sample.
+A horizontal phase shift may be required to produce signals which use different
+ horizontal chroma sampling locations for compatibility with different systems.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{pixel422}
+\end{center}
+\caption{Pixels encoded 4:2:2}
+\label{fig:pixel422}
+\end{figure}
+
+% Figure.
+%Y RB Y Y RB Y
+%
+%
+%
+%Y RB Y Y RB Y
+%
+%
+%
+
+\subsection{4:2:0 Subsampling}
+\label{sec:420}
+
+The $C_b$ and $C_r$ planes are stored with half the horizontal and half the
+ vertical resolution of the $Y'$ plane.
+Thus, each of these planes has half the number of horizontal blocks and half
+ the number of vertical blocks as the luma plane, for a total of one quarter
+ the number of blocks (see Figure~\ref{fig:pixel420}).
+Similarly, they have half the number of horizontal super blocks and half the
+ number of vertical super blocks, rounded up.
+Macro blocks are defined across color planes, and so their number does not
+ change, but each macro block contains within it one quarter as many
+ chroma blocks.
+
+The chroma samples are vertically and horizontally centered between four luma
+ samples.
+Thus, each luma sample has a unique closest chroma sample.
+This is the same sub-sampling pattern used with JPEG, MJPEG, and MPEG-1, and
+ was inherited from VP3.
+A horizontal or vertical phase shift may be required to produce signals which
+ use different chroma sampling locations for compatibility with different
+ systems.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{pixel420}
+\end{center}
+\caption{Pixels encoded 4:2:0}
+\label{fig:pixel420}
+\end{figure}
+
+% Figure.
+%Y Y Y Y
+%
+% RB RB
+%
+%Y Y Y Y
+%
+%
+%
+%Y Y Y Y
+%
+% RB RB
+%
+%Y Y Y Y
+%
+%
+%
+
+\subsection{Subsampling and the Picture Region}
+
+Although the frame size must be an integral number of macro blocks, and thus
+ both the number of pixels and the number of blocks in each direction must be
+ even, no such requirement is made of the picture region.
+Thus, when using subsampled pixel formats, careful attention must be paid to
+ which chroma samples correspond to which luma samples.
+
+As mentioned above, for each pixel format, there is a unique chroma sample that
+ is the closest to each luma sample.
+When cropping the chroma planes to the picture region, all the chroma samples
+ corresponding to a luma sample in the cropped picture region must be included.
+Thus, when dividing the width or height of the picture region by two to obtain
+ the size of the subsampled chroma planes, they must be rounded up.
+
+Furthermore, the sampling locations are defined relative to the frame,
+ {\em not} the picture region.
+When using the 4:2:2 and 4:2:0 formats, the locations of chroma samples
+ relative to the luma samples depends on whether or not the X offset of the
+ picture region is odd.
+If the offset is even, each column of chroma samples corresponds to two columns
+ of luma samples (see Figure~\ref{fig:pic_even} for an example).
+The only exception is if the width is odd, in which case the last column
+ corresponds to only one column of luma samples (see Figure~\ref{fig:pic_even_odd}).
+If the offset is odd, then the first column of chroma samples corresponds to
+ only one column of luma samples, while the remaining columns each correspond
+ to two (see Figure~\ref{fig:pic_odd}).
+In this case, if the width is even, the last column again corresponds to only
+ one column of luma samples (see Figure~\ref{fig:pic_odd_even}).
+
+A similar process is followed with the rows of a picture region of odd height
+ encoded in the 4:2:0 format.
+If the Y offset is even, each row of chroma samples corresponds to two rows of
+ luma samples (see Figure~\ref{fig:pic_even}), except with an odd height, where
+ the last row corresponds to one row of chroma luna samples only (see
+ Figure~\ref{fig:pic_even_odd}).
+If the offset is odd, then it is the first row of chroma samples which
+ corresponds to only one row of luma samples, while the remaining rows each
+ correspond to two (Figure~\ref{fig:pic_odd}), except with an even height,
+ where the last row also corresponds to one (Figure~\ref{fig:pic_odd_even}).
+
+Encoders should be aware of these differences in the subsampling when using an
+ even or odd offset.
+In the typical case, with an even width and height, where one expects two rows
+ or columns of luma samples for every row or column of chroma samples, the
+ encoder must take care to ensure that the offsets used are both even.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[width=\textwidth]{pic_even}
+\end{center}
+\caption{Pixel correspondence between color planes with even picture
+ offset and even picture size}
+\label{fig:pic_even}
+\end{figure}
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[width=\textwidth]{pic_even_odd}
+\end{center}
+\caption{Pixel correspondence with even picture offset and
+ odd picture size}
+\label{fig:pic_even_odd}
+\end{figure}
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[width=\textwidth]{pic_odd}
+\end{center}
+\caption{Pixel correspondence with odd picture offset and
+ odd picture size}
+\label{fig:pic_odd}
+\end{figure}
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[width=\textwidth]{pic_odd_even}
+\end{center}
+\caption{Pixel correspondence with odd picture offset and
+ even picture size}
+\label{fig:pic_odd_even}
+\end{figure}
+
+
+\chapter{Bitpacking Convention}
+\label{sec:bitpacking}
+
+\section{Overview}
+
+The Theora codec uses relatively unstructured raw packets containing
+ binary integer fields of arbitrary width.
+Logically, each packet is a bitstream in which bits are written one-by-one by
+ the encoder and then read one-by-one in the same order by the decoder.
+Most current binary storage arrangements group bits into a native storage unit
+ of eight bits (octets), sixteen bits, thirty-two bits, or less commonly other
+ fixed sizes.
+The Theora bitpacking convention specifies the correct mapping of the logical
+ packet bitstream into an actual representation in fixed-width units.
+
+\subsection{Octets and Bytes}
+
+In most contemporary architectures, a `byte' is synonymous with an `octect',
+ that is, eight bits.
+For purposes of the bitpacking convention, a byte implies the smallest native
+ integer storage representation offered by a platform.
+Modern file systems invariably offer bytes as the fundamental atom of storage.
+
+The most ubiquitous architectures today consider a `byte' to be an octet.
+Note, however, that the Theora bitpacking convention is still well defined for
+ any native byte size; an implementation can use the native bit-width of a
+ given storage system.
+This document assumes that a byte is one octet for purposes of example only.
+
+\subsection{Words and Byte Order}
+
+A `word' is an integer size that is a grouped multiple of the byte size.
+Most architectures consider a word to be a group of two, four, or eight bytes.
+Each byte in the word can be ranked by order of `significance', e.g.\ the
+ significance of the bits in each byte when storing a binary integer in the
+ word.
+Several byte orderings are possible in a word.
+The common ones are
+\begin{itemize}
+\item{Big-endian:}
+in which the most significant byte comes first, e.g.\ 3-2-1-0,
+\item{Little-endian:}
+in which the least significant byte comes first, e.g.\ 0-1-2-3, and
+\item{Mixed-endian:}
+one of the less-common orderings that cannot be put into the above two
+ categories, e.g.\ 3-1-2-0 or 0-2-1-3.
+\end{itemize}
+
+The Theora bitpacking convention specifies storage and bitstream manipulation
+ at the byte, not word, level.
+Thus host word ordering is of a concern only during optimization, when writing
+ code that operates on a word of storage at a time rather than a byte.
+Logically, bytes are always encoded and decoded in order from byte zero through
+ byte $n$.
+
+\subsection{Bit Order}
+
+A byte has a well-defined `least significant' bit (LSb), which is the only bit
+ set when the byte is storing the two's complement integer value $+1$.
+A byte's `most significant' bit (MSb) is at the opposite end.
+Bits in a byte are numbered from zero at the LSb to $n$ for the MSb, where
+ $n=7$ in an octet.
+
+\section{Coding Bits into Bytes}
+
+The Theora codec needs to encode arbitrary bit-width integers from zero to 32
+ bits wide into packets.
+These integer fields are not aligned to the boundaries of the byte
+ representation; the next field is read at the bit position immediately
+ after the end of the previous field.
+
+The decoder logically unpacks integers by first reading the MSb of a binary
+ integer from the logical bitstream, followed by the next most significant
+ bit, etc., until the required number of bits have been read.
+When unpacking the bytes into bits, the decoder begins by reading the MSb of
+ the integer to be read from the most significant unread bit position of the
+ source byte, followed by the next-most significant bit position of the
+ destination integer, and so on up to the requested number of bits.
+Note that this differs from the Vorbis I codec, which
+ begins decoding with the LSb of the source integer, reading it from the
+ LSb of the source byte.
+When all the bits of the current source byte are read, decoding continues with
+ the MSb of the next byte.
+Any unfilled bits in the last byte of the packet MUST be cleared to zero by the
+ encoder.
+
+\subsection{Signedness}
+
+The binary integers decoded by the above process may be either signed or
+ unsigned.
+This varies from integer to integer, and this specification
+ indicates how each value should be interpreted as it is read.
+That is, depending on context, the three bit binary pattern \bin{111} can be
+ taken to represent either `$7$' as an unsigned integer or `$-1$' as a signed,
+ two's complement integer.
+
+\subsection{Encoding Example}
+
+The following example shows the state of an (8-bit) byte stream after several
+ binary integers are encoded, including the location of the put pointer for the
+ next bit to write to and the total length of the stream in bytes.
+
+Encode the 4 bit unsigned integer value `12' (\bin{1100}) into an empty byte
+ stream.
+
+\begin{tabular}{r|ccccccccl}
+\multicolumn{1}{r}{}& &&&&$\downarrow$&&&& \\
+ & 7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & \\\cline{1-9}
+byte 0 & \textbf{1} & \textbf{1} & \textbf{0} & \textbf{0} &
+ 0 & 0 & 0 & 0 & $\leftarrow$ \\
+byte 1 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & \\
+byte 2 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & \\
+byte 3 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & \\
+\multicolumn{1}{c|}{$\vdots$}&\multicolumn{8}{c}{$\vdots$}& \\
+byte $n$ & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 &
+byte stream length: 1 byte
+\end{tabular}
+\vspace{\baselineskip}
+
+Continue by encoding the 3 bit signed integer value `-1' (\bin{111}).
+
+\begin{tabular}{r|ccccccccl}
+\multicolumn{1}{r}{} &&&&&&&&$\downarrow$& \\
+ & 7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & \\\cline{1-9}
+byte 0 & \textbf{1} & \textbf{1} & \textbf{0} & \textbf{0} &
+ \textbf{1} & \textbf{1} & \textbf{1} & 0 & $\leftarrow$ \\
+byte 1 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & \\
+byte 2 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & \\
+byte 3 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & \\
+\multicolumn{1}{c|}{$\vdots$}&\multicolumn{8}{c}{$\vdots$}& \\
+byte $n$ & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 &
+byte stream length: 1 byte
+\end{tabular}
+\vspace{\baselineskip}
+
+Continue by encoding the 7 bit integer value `17' (\bin{0010001}).
+
+\begin{tabular}{r|ccccccccl}
+\multicolumn{1}{r}{} &&&&&&&$\downarrow$&& \\
+ & 7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & \\\cline{1-9}
+byte 0 & \textbf{1} & \textbf{1} & \textbf{0} & \textbf{0} &
+ \textbf{1} & \textbf{1} & \textbf{1} & \textbf{0} & \\
+byte 1 & \textbf{0} & \textbf{1} & \textbf{0} & \textbf{0} &
+ \textbf{0} & \textbf{1} & 0 & 0 & $\leftarrow$ \\
+byte 2 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & \\
+byte 3 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 & \\
+\multicolumn{1}{c|}{$\vdots$}&\multicolumn{8}{c}{$\vdots$}& \\
+byte $n$ & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 &
+byte stream length: 2 bytes
+\end{tabular}
+\vspace{\baselineskip}
+
+Continue by encoding the 13 bit integer value `6969' (\bin{11011\ 00111001}).
+
+\begin{tabular}{r|ccccccccl}
+\multicolumn{1}{r}{} &&&&$\downarrow$&&&&& \\
+ & 7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & \\\cline{1-9}
+byte 0 & \textbf{1} & \textbf{1} & \textbf{0} & \textbf{0} &
+ \textbf{1} & \textbf{1} & \textbf{1} & \textbf{0} & \\
+byte 1 & \textbf{0} & \textbf{1} & \textbf{0} & \textbf{0} &
+ \textbf{0} & \textbf{1} & \textbf{1} & \textbf{1} & \\
+byte 2 & \textbf{0} & \textbf{1} & \textbf{1} & \textbf{0} &
+ \textbf{0} & \textbf{1} & \textbf{1} & \textbf{1} & \\
+byte 3 & \textbf{0} & \textbf{0} & \textbf{1} &
+ 0 & 0 & 0 & 0 & 0 & $\leftarrow$ \\
+\multicolumn{1}{c|}{$\vdots$}&\multicolumn{8}{c}{$\vdots$}& \\
+byte $n$ & 0 & 0 & 0 & 0 & 0 & 0 & 0 & 0 &
+byte stream length: 4 bytes
+\end{tabular}
+\vspace{\baselineskip}
+
+\subsection{Decoding Example}
+
+The following example shows the state of the (8-bit) byte stream encoded in the
+ previous example after several binary integers are decoded, including the
+ location of the get pointer for the next bit to read.
+
+Read a two bit unsigned integer from the example encoded above.
+
+\begin{tabular}{r|ccccccccl}
+\multicolumn{1}{r}{} &&&$\downarrow$&&&&&& \\
+ & 7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & \\\cline{1-9}
+byte 0 & \textbf{1} & \textbf{1} & 0 & 0 & 1 & 1 & 1 & 0 & $\leftarrow$ \\
+byte 1 & 0 & 1 & 0 & 0 & 0 & 1 & 1 & 1 & \\
+byte 2 & 0 & 1 & 1 & 0 & 0 & 1 & 1 & 1 & \\
+byte 3 & 0 & 0 & 1 & 0 & 0 & 0 & 0 & 0 &
+byte stream length: 4 bytes
+\end{tabular}
+\vspace{\baselineskip}
+
+Value read: 3 (\bin{11}).
+
+Read another two bit unsigned integer from the example encoded above.
+
+\begin{tabular}{r|ccccccccl}
+\multicolumn{1}{r}{} &&&&&$\downarrow$&&&& \\
+ & 7 & 6 & 5 & 4 & 3 & 2 & 1 & 0 & \\\cline{1-9}
+byte 0 & \textbf{1} & \textbf{1} & \textbf{0} & \textbf{0} &
+ 1 & 1 & 1 & 0 & $\leftarrow$ \\
+byte 1 & 0 & 1 & 0 & 0 & 0 & 1 & 1 & 1 & \\
+byte 2 & 0 & 1 & 1 & 0 & 0 & 1 & 1 & 1 & \\
+byte 3 & 0 & 0 & 1 & 0 & 0 & 0 & 0 & 0 &
+byte stream length: 4 bytes
+\end{tabular}
+\vspace{\baselineskip}
+
+Value read: 0 (\bin{00}).
+
+Two things are worth noting here.
+\begin{itemize}
+\item
+Although these four bits were originally written as a single four-bit integer,
+ reading some other combination of bit-widths from the bitstream is well
+ defined.
+No artificial alignment boundaries are maintained in the bitstream.
+\item
+The first value is the integer `$3$' only because the context stated we were
+ reading an unsigned integer.
+Had the context stated we were reading a signed integer, the returned value
+ would have been the integer `$-1$'.
+\end{itemize}
+
+\subsection{End-of-Packet Alignment}
+
+The typical use of bitpacking is to produce many independent byte-aligned
+ packets which are embedded into a larger byte-aligned container structure,
+ such as an Ogg transport bitstream.
+Externally, each bitstream encoded as a byte stream MUST begin and end on a
+ byte boundary.
+Often, the encoded packet bitstream is not an integer number of bytes, and so
+ there is unused space in the last byte of a packet.
+
+%r: I think the generality here is necessary to be consistent with our assertions
+%r: elsewhere about being independent of transport and byte width
+When a Theora encoder produces packets for embedding in a byte-aligned
+ container, unused space in the last byte of a packet is always zeroed during
+ the encoding process.
+Thus, should this unused space be read, it will return binary zeroes.
+There is no marker pattern or stuffing bits that will allow the decoder to
+ obtain the exact size, in bits, of the original bitstream.
+This knowledge is not required for decoding.
+
+Attempting to read past the end of an encoded packet results in an
+ `end-of-packet' condition.
+Any further read operations after an `end-of-packet' condition shall also
+ return `end-of-packet'.
+Unlike Vorbis, Theora does not use truncated packets as a normal mode of
+ operation.
+Therefore if a decoder encounters the `end-of-packet' condition during normal
+ decoding, it may attempt to use the bits that were read to recover as much of
+ encoded data as possible, signal a warning or error, or both.
+
+\subsection{Reading Zero Bit Integers}
+
+Reading a zero bit integer returns the value `$0$' and does not increment
+ the stream pointer.
+Reading to the end of the packet, but not past the end, so that an
+ `end-of-packet' condition is not triggered, and then reading a zero bit
+ integer shall succeed, returning `$0$', and not trigger an `end-of-packet'
+ condition.
+Reading a zero bit integer after a previous read sets the `end-of-packet'
+ condition shall fail, also returning `end-of-packet'.
+
+\chapter{Bitstream Headers}
+\label{sec:headers}
+
+A Theora bitstream begins with three header packets.
+The header packets are, in order, the identification header, the comment
+ header, and the setup header.
+All are required for decode compliance.
+An end-of-packet condition encountered while decoding the identification or
+ setup header packets renders the stream undecodable.
+An end-of-packet condition encountered while decode the comment header is a
+ non-fatal error condition, and MAY be ignored by a decoder.
+
+\paragraph{VP3 Compatibility}
+
+VP3 relies on the headers provided by its container, usually either AVI or
+ Quicktime.
+As such, several parameters available in these headers are not available to VP3
+ streams.
+These are indicated as they appear in the sections below.
+
+\section{Common Header Decode}
+\label{sub:common-header}
+
+\begin{figure}[Htbp]
+\begin{center}
+\begin{verbatim}
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | header type | `t' | `h' | `e' |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | `o' | `r' | `a' | data... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... header-specific data ... |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+\end{verbatim}
+\end{center}
+\caption{Common Header Packet Layout}
+\label{fig:commonheader}
+\end{figure}
+
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{HEADERTYPE} & Integer & 8 & No & The type of the header being
+ decoded. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:} None.
+\medskip
+
+Each header packet begins with the same header fields, which are decoded as
+ follows:
+
+\begin{enumerate}
+\item
+Read an 8-bit unsigned integer as \bitvar{HEADERTYPE}.
+If the most significant bit of this integer is not set, then stop.
+This is not a header packet.
+\item
+Read 6 8-bit unsigned integers.
+If these do not have the values \hex{74}, \hex{68}, \hex{65}, \hex{6F},
+ \hex{72}, and \hex{61}, respectively, then stop.
+This stream is not decodable by this specification.
+These values correspond to the ASCII values of the characters `t', `h', `e',
+ `o', `r', and `a'.
+\end{enumerate}
+
+Decode continues according to \bitvar{HEADERTYPE}.
+The identification header is type \hex{80}, the comment header is type
+ \hex{81}, and the setup header is type \hex{82}.
+These packets must occur in the order: identification, comment, setup.
+%r: I clarified the initial-bit scheme here
+%TBT: Dashes let the reader know they'll have to pick up the rest of the
+%TBT: sentence after the explanatory phrase.
+%TBT: Otherwise it just sounds like the bit must exist.
+All header packets have the most significant bit of the type
+ field---which is the initial bit in the packet---set.
+This distinguishes them from video data packets in which the first bit
+ is unset.
+% extra header packets are a feature Dan argued for way back when for
+% backward-compatible extensions (and icc colourspace for example)
+% I think it's reasonable
+%TBT: You can always just stick more stuff in the setup header.
+Packets with other header types (\hex{83}--\hex{FF}) are reserved and MUST be
+ ignored.
+
+\section{Identification Header Decode}
+\label{sec:idheader}
+
+\begin{figure}[Htbp]
+\begin{center}
+\begin{verbatim}
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 0x80 | `t' | `h' | `e' |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | `o' | `r' | `a' | VMAJ |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | VMIN | VREV | FMBW |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | FMBH | PICW... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ...PICW | PICH |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | PICX | PICY | FRN... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ...FRN | FRD... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ...FRD | PARN... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ...PARN | PARD |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | CS | NOMBR |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | QUAL | KFGSHIFT| PF| Res |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+\end{verbatim}
+\end{center}
+\caption{Identification Header Packet}
+\label{fig:idheader}
+\end{figure}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{VMAJ} & Integer & 8 & No & The major version number. \\
+\bitvar{VMIN} & Integer & 8 & No & The minor version number. \\
+\bitvar{VREV} & Integer & 8 & No & The version revision number. \\
+\bitvar{FMBW} & Integer & 16 & No & The width of the frame in macro
+ blocks. \\
+\bitvar{FMBH} & Integer & 16 & No & The height of the frame in macro
+ blocks. \\
+\bitvar{NSBS} & Integer & 32 & No & The total number of super blocks in a
+ frame. \\
+\bitvar{NBS} & Integer & 36 & No & The total number of blocks in a
+ frame. \\
+\bitvar{NMBS} & Integer & 32 & No & The total number of macro blocks in a
+ frame. \\
+\bitvar{PICW} & Integer & 20 & No & The width of the picture region in
+ pixels. \\
+\bitvar{PICH} & Integer & 20 & No & The height of the picture region in
+ pixels. \\
+\bitvar{PICX} & Integer & 8 & No & The X offset of the picture region in
+ pixels. \\
+\bitvar{PICY} & Integer & 8 & No & The Y offset of the picture region in
+ pixels. \\
+\bitvar{FRN} & Integer & 32 & No & The frame-rate numerator. \\
+\bitvar{FRD} & Integer & 32 & No & The frame-rate denominator. \\
+\bitvar{PARN} & Integer & 24 & No & The pixel aspect-ratio numerator. \\
+\bitvar{PARD} & Integer & 24 & No & The pixel aspect-ratio denominator. \\
+\bitvar{CS} & Integer & 8 & No & The color space. \\
+\bitvar{PF} & Integer & 2 & No & The pixel format. \\
+\bitvar{NOMBR} & Integer & 24 & No & The nominal bitrate of the stream, in
+ bits per second. \\
+\bitvar{QUAL} & Integer & 6 & No & The quality hint. \\
+\bitvar{KFGSHIFT} & Integer & 5 & No & The amount to shift the key frame
+ number by in the granule position. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:} None.
+\medskip
+
+The identification header is a short header with only a few fields used to
+ declare the stream definitively as Theora and provide detailed information
+ about the format of the fully decoded video data.
+The identification header is decoded as follows:
+
+\begin{enumerate}
+\item
+Decode the common header fields according to the procedure described in
+ Section~\ref{sub:common-header}.
+If \bitvar{HEADERTYPE} returned by this procedure is not \hex{80}, then stop.
+This packet is not the identification header.
+\item
+Read an 8-bit unsigned integer as \bitvar{VMAJ}.
+If \bitvar{VMAJ} is not $3$, then stop.
+This stream is not decodable according to this specification.
+\item
+Read an 8-bit unsigned integer as \bitvar{VMIN}.
+If \bitvar{VMIN} is not $2$, then stop.
+This stream is not decodable according to this specification.
+\item
+Read an 8-bit unsigned integer as \bitvar{VREV}.
+If \bitvar{VREV} is greater than $1$, then this stream
+may contain optional features or interpretational changes
+documented in a future version of this specification.
+Regardless of the value of \bitvar{VREV}, the stream is decodable
+according to this specification.
+\item
+Read a 16-bit unsigned integer as \bitvar{FMBW}.
+This MUST be greater than zero.
+This specifies the width of the coded frame in macro blocks.
+The actual width of the frame in pixels is $\bitvar{FMBW}*16$.
+\item
+Read a 16-bit unsigned integer as \bitvar{FMBH}.
+This MUST be greater than zero.
+This specifies the height of the coded frame in macro blocks.
+The actual height of the frame in pixels is $\bitvar{FMBH}*16$.
+\item
+Read a 24-bit unsigned integer as \bitvar{PICW}.
+This MUST be no greater than $(\bitvar{FMBW}*16)$.
+Note that 24 bits are read, even though only 20 bits are sufficient to specify
+ any value of the picture width.
+This is done to preserve octet alignment in this header, to allow for a
+ simplified parser implementation.
+\item
+Read a 24-bit unsigned integer as \bitvar{PICH}.
+This MUST be no greater than $(\bitvar{FMBH}*16)$.
+Together with \bitvar{PICW}, this specifies the size of the displayable picture
+ region within the coded frame.
+See Figure~\ref{fig:pic-frame}.
+Again, 24 bits are read instead of 20.
+\item
+Read an 8-bit unsigned integer as \bitvar{PICX}.
+This MUST be no greater than $(\bitvar{FMBW}*16-\bitvar{PICX})$.
+\item
+Read an 8-bit unsigned integer as \bitvar{PICY}.
+This MUST be no greater than $(\bitvar{FMBH}*16-\bitvar{PICY})$.
+Together with \bitvar{PICX}, this specifies the location of the lower-left
+ corner of the displayable picture region.
+See Figure~\ref{fig:pic-frame}.
+\item
+Read a 32-bit unsigned integer as \bitvar{FRN}.
+This MUST be greater than zero.
+\item
+Read a 32-bit unsigned integer as \bitvar{FRD}.
+This MUST be greater than zero.
+Theora is a fixed-frame rate video codec.
+Frames are sampled at the constant rate of $\frac{\bitvar{FRN}}{\bitvar{FRD}}$
+ frames per second.
+The presentation time of the first frame is at zero seconds.
+No mechanism is provided to specify a non-zero offset for the initial
+ frame.
+\item
+Read a 24-bit unsigned integer as \bitvar{PARN}.
+\item
+Read a 24-bit unsigned integer as \bitvar{PARD}.
+Together with \bitvar{PARN}, these specify the aspect ratio of the pixels
+ within a frame, defined as the ratio of the physical width of a pixel to its
+ physical height.
+This is given by the ratio $\bitvar{PARN}:\bitvar{PARD}$.
+If either of these fields are zero, this indicates that pixel aspect ratio
+ information was not available to the encoder.
+In this case it MAY be specified by the application via an external means, or
+ a default value of $1:1$ MAY be used.
+\item
+Read an 8-bit unsigned integer as \bitvar{CS}.
+This is a value from an enumerated list of the available color spaces, given in
+ Table~\ref{tab:colorspaces}.
+The `Undefined' value indicates that color space information was not available
+ to the encoder.
+It MAY be specified by the application via an external means.
+If a reserved value is given, a decoder MAY refuse to decode the stream.
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular*}{215pt}{cl@{\extracolsep{\fill}}c}\toprule
+Value & Color Space \\\midrule
+$0$ & Undefined. \\
+$1$ & Rec.~470M (see Section~\ref{sec:470m}). \\
+$2$ & Rec.~470BG (see Section~\ref{sec:470bg}). \\
+$3$ & Reserved. \\
+$\vdots$ & \\
+$255$ & \\
+\bottomrule\end{tabular*}
+\end{center}
+\caption{Enumerated List of Color Spaces}
+\label{tab:colorspaces}
+\end{table}
+\item
+Read a 24-bit unsigned integer as \bitvar{NOMBR} signifying a rate in bits
+per second. Rates equal to or greater than $2^{24}-1$ bits per second are
+represented as $2^{24}-1$.
+The \bitvar{NOMBR} field is used only as a hint.
+For pure VBR streams, this value may be considerably off.
+The field MAY be set to zero to indicate that the encoder did not care to
+speculate.
+\item
+Read a 6-bit unsigned integer as \bitvar{QUAL}.
+This value is used to provide a hint as to the relative quality of the stream
+ when compared to others produced by the same encoder.
+Larger values indicate higher quality.
+This can be used, for example, to select among several streams containing the
+ same material encoded with different settings.
+\item
+Read a 5-bit unsigned integer as \bitvar{KFGSHIFT}.
+The \bitvar{KFGSHIFT} is used to partition the granule position associated with
+ each packet into two different parts.
+The frame number of the last key frame, starting from zero, is stored in the
+ upper $64-\bitvar{KFGSHIFT}$ bits, while the lower \bitvar{KFGSHIFT} bits
+ contain the number of frames since the last keyframe.
+Complete details on the granule position mapping are specified in Section~REF.
+\item
+Read a 2-bit unsigned integer as \bitvar{PF}.
+The \bitvar{PF} field contains a value from an enumerated list of the available
+ pixel formats, given in Table~\ref{tab:pixel-formats}.
+If the reserved value $1$ is given, stop.
+This stream is not decodable according to this specification.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular*}{215pt}{cl@{\extracolsep{\fill}}c}\toprule
+Value & Pixel Format \\\midrule
+$0$ & 4:2:0 (see Section~\ref{sec:420}). \\
+$1$ & Reserved. \\
+$2$ & 4:2:2 (see Section~\ref{sec:422}). \\
+$3$ & 4:4:4 (see Section~\ref{sec:444}). \\
+\bottomrule\end{tabular*}
+\end{center}
+\caption{Enumerated List of Pixel Formats}
+\label{tab:pixel-formats}
+\end{table}
+
+\item
+Read a 3-bit unsigned integer.
+These bits are reserved.
+If this value is not zero, then stop.
+This stream is not decodable according to this specification.
+\item
+Assign \bitvar{NSBS} a value according to \bitvar{PF}, as given by
+ Table~\ref{tab:nsbs-for-pf}.
+
+\begin{table}[bt]
+\begin{center}
+\begin{tabular}{cc}\toprule
+\bitvar{PF} & \bitvar{NSBS} \\\midrule
+$0$ & $\begin{aligned}
+&((\bitvar{FMBW}+1)//2)*((\bitvar{FMBH}+1)//2)\\
+& +2*((\bitvar{FMBW}+3)//4)*((\bitvar{FMBH}+3)//4)
+\end{aligned}$ \\\midrule
+$2$ & $\begin{aligned}
+&((\bitvar{FMBW}+1)//2)*((\bitvar{FMBH}+1)//2)\\
+& +2*((\bitvar{FMBW}+3)//4)*((\bitvar{FMBH}+1)//2)
+\end{aligned}$ \\\midrule
+$3$ & $3*((\bitvar{FMBW}+1)//2)*((\bitvar{FMBH}+1)//2)$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Number of Super Blocks for each Pixel Format}
+\label{tab:nsbs-for-pf}
+\end{table}
+
+\item
+Assign \bitvar{NBS} a value according to \bitvar{PF}, as given by
+ Table~\ref{tab:nbs-for-pf}.
+
+\begin{table}[tb]
+\begin{center}
+\begin{tabular}{cc}\toprule
+\bitvar{PF} & \bitvar{NBS} \\\midrule
+$0$ & $6*\bitvar{FMBW}*\bitvar{FMBH}$ \\\midrule
+$2$ & $8*\bitvar{FMBW}*\bitvar{FMBH}$ \\\midrule
+$3$ & $12*\bitvar{FMBW}*\bitvar{FMBH}$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Number of Blocks for each Pixel Format}
+\label{tab:nbs-for-pf}
+\end{table}
+
+\item
+Assign \bitvar{NMBS} the value $(\bitvar{FMBW}*\bitvar{FMBH})$.
+
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+VP3 does not correctly handle frame sizes that are not a multiple of 16.
+Thus, \bitvar{PICW} and \bitvar{PICH} should be set to the frame width and
+ height in pixels, respectively, and \bitvar{PICX} and \bitvar{PICY} should be
+ set to zero.
+VP3 headers do not specify a color space.
+VP3 only supports the 4:2:0 pixel format.
+
+\section{Comment Header}
+\label{sec:commentheader}
+
+The Theora comment header is the second of three header packets that begin a
+ Theora stream.
+It is meant for short text comments, not aribtrary metadata; arbitrary metadata
+ belongs in a separate logical stream that provides greater structure and
+ machine parseability.
+
+%r: I tried to morph this a little more in the direction of our
+% application space
+The comment field is meant to be used much like someone jotting a quick note on
+ the label of a video.
+It should be a little information to remember the disc or tape by and explain it to
+ others; a short, to-the-point text note that can be more than a couple words,
+ but isn't going to be more than a short paragraph.
+The essentials, in other words, whatever they turn out to be, e.g.:
+
+%TODO: Example
+
+The comment header is stored as a logical list of eight-bit clean vectors; the
+ number of vectors is bounded at $2^{32}-1$ and the length of each vector is
+ limited to $2^{32}-1$ bytes.
+The vector length is encoded; the vector contents themselves are not null
+ terminated.
+In addition to the vector list, there is a single vector for a vendor name,
+ also eight-bit clean with a length encoded in 32 bits.
+%TODO: The 1.0 release of libtheora sets the vendor string to ...
+
+\subsection{Comment Length Decode}
+\label{sub:comment-len}
+
+\begin{figure}
+\begin{center}
+\begin{tabular}{ | c | c | }
+ \hline
+ 4 byte length &
+ UTF-8 encoded string ...\\
+ \hline
+\end{tabular}
+\end{center}
+\caption{Length encoded string layout}
+\label{fig:comment-len}
+\end{figure}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{LEN} & Integer & 32 & No & A single 32-bit length value. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{LEN0} & Integer & 8 & No & The first octet of the string length. \\
+\locvar{LEN1} & Integer & 8 & No & The second octet of the string length. \\
+\locvar{LEN2} & Integer & 8 & No & The third octet of the string length. \\
+\locvar{LEN3} & Integer & 8 & No & The fourth octet of the string
+ length. \\
+\bottomrule\end{tabularx}
+\medskip
+
+A single comment vector is decoded as follows:
+
+\begin{enumerate}
+\item
+Read an 8-bit unsigned integer as \locvar{LEN0}.
+\item
+Read an 8-bit unsigned integer as \locvar{LEN1}.
+\item
+Read an 8-bit unsigned integer as \locvar{LEN2}.
+\item
+Read an 8-bit unsigned integer as \locvar{LEN3}.
+\item
+Assign \bitvar{LEN} the value $(\locvar{LEN0}+(\locvar{LEN1}<<8)+
+ (\locvar{LEN2}<<16)+(\locvar{LEN3}<<24))$.
+This construction is used so that on platforms with 8-bit bytes, the memory
+ organization of the comment header is identical with that of Vorbis I,
+ allowing for common parsing code despite the different bit packing
+ conventions.
+\end{enumerate}
+
+\subsection{Comment Header Decode}
+
+\begin{figure}
+\begin{center}
+\begin{tabular}{ | c | }
+ \hline
+ vendor string \\ \hline
+ number of comments \\ \hline
+ comment string \\ \hline
+ comment string \\ \hline
+ ... \\
+ \hline
+\end{tabular}
+\end{center}
+\caption{Comment Header Layout}
+\label{fig:commentheader}
+\end{figure}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{VENDOR} & \multicolumn{3}{l}{String} & The vendor string. \\
+\bitvar{NCOMMENTS} & Integer & 32 & No & The number of user
+ comments. \\
+\bitvar{COMMENTS} & \multicolumn{3}{l}{String Array} & A list of
+ \bitvar{NCOMMENTS} user comment values. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\ci} & Integer & 32 & No & The index of the current user
+ comment. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The complete comment header is decoded as follows:
+
+\begin{enumerate}
+\item
+Decode the common header fields according to the procedure described in
+ Section~\ref{sub:common-header}.
+If \bitvar{HEADERTYPE} returned by this procedure is not \hex{81}, then stop.
+This packet is not the comment header.
+\item
+Decode the length of the vendor string using the procedure given in
+ Section~\ref{sub:comment-len} into \bitvar{LEN}.
+\item
+Read \bitvar{LEN} 8-bit unsigned integers.
+\item
+Set the string \bitvar{VENDOR} to the contents of these octets.
+\item
+Decode the number of user comments using the procedure given in
+ Section~\ref{sub:comment-len} into \bitvar{LEN}.
+\item
+Assign \bitvar{NCOMMENTS} the value stored in \bitvar{LEN}.
+\item
+For each consecutive value of \locvar{\ci} from $0$ to
+ $(\bitvar{NCOMMENTS}-1)$, inclusive:
+\begin{enumerate}
+\item
+Decode the length of the current user comment using the procedure given in
+ Section~\ref{sub:comment-len} into \bitvar{LEN}.
+\item
+Read \bitvar{LEN} 8-bit unsigned integers.
+\item
+Set the string $\bitvar{COMMENTS}[\locvar{\ci}]$ to the contents of these
+ octets.
+\end{enumerate}
+\end{enumerate}
+
+The comment header comprises the entirety of the second header packet.
+Unlike the first header packet, it is not generally the only packet on the
+ second page and may span multiple pages.
+The length of the comment header packet is (practically) unbounded.
+The comment header packet is not optional; it must be present in the stream
+ even if it is logically empty.
+
+%TODO: \paragraph{VP3 Compatibility}
+
+\subsection{User Comment Format}
+
+The user comment vectors are structured similarly to a UNIX environment
+ variable.
+That is, comment fields consist of a field name and a corresponding value and
+ look like:
+\begin{center}
+\begin{tabular}{rcl}
+$\bitvar{COMMENTS}[0]$ & = & ``TITLE=the look of Theora" \\
+$\bitvar{COMMENTS}[1]$ & = & ``DIRECTOR=me"
+\end{tabular}
+\end{center}
+
+The field name is case-insensitive and MUST consist of ASCII characters
+ \hex{20} through \hex{7D}, \hex{3D} (`=') excluded.
+ASCII \hex{41} through \hex{5A} inclusive (characters `A'--`Z') are to be
+ considered equivalent to ASCII \hex{61} through \hex{7A} inclusive
+ (characters `a'--`z').
+An entirely empty field name---one that is zero characters long---is not
+ disallowed.
+
+The field name is immediately followed by ASCII \hex{3D} (`='); this equals
+ sign is used to terminate the field name.
+
+The data immediately after \hex{3D} until the end of the vector is the eight-bit
+ clean value of the field contents encoded as a UTF-8 string~\cite{rfc2044}.
+
+Field names MUST NOT be `internationalized'; this is a concession to
+ simplicity, not an attempt to exclude the majority of the world that doesn't
+ speak English.
+Applications MAY wish to present internationalized versions of the standard
+ field names listed below to the user, but they are not to be stored in the
+ bitstream.
+Field {\em contents}, however, use the UTF-8 character encoding to allow easy
+ representation of any language.
+
+Individual `vendors' MAY use non-standard field names within reason.
+The proper use of comment fields as human-readable notes has already been
+ explained.
+Abuse will be discouraged.
+
+There is no vendor-specific prefix to `non-standard' field names.
+Vendors SHOULD make some effort to avoid arbitrarily polluting the common
+ namespace.
+%"and other bodies"?
+%If you're going to be that vague, you might as well not say anything at all.
+Xiph.Org and other bodies will generally collect and rationalize the more
+ useful tags to help with standardization.
+
+Field names are not restricted to occur only once within a comment header.
+%TODO: Example
+
+\paragraph{Field Names}
+
+%r should this be an appendix?
+
+Below is a proposed, minimal list of standard field names with a description of
+ their intended use.
+No field names are mandatory; a comment header may contain one or more, all, or
+ none of the names in this list.
+
+\begin{description}
+\item{TITLE:} Video name.
+\item{ARTIST:} Filmmaker or other creator name.
+\item{VERSION:} Subtitle, remix info, or other text distinguishing
+ versions of a video.
+\item{DATE:} Date associated with the video. Implementations SHOULD attempt
+ to parse this field as an ISO 8601 date for machine interpretation and
+ conversion.
+\item{LOCATION:} Location associated with the video. This is usually the
+ filming location for non-fiction works.
+\item{COPYRIGHT:} Copyright statement.
+\item{LICENSE:} Copyright and other licensing information.
+ Implementations wishing to do automatic parsing of e.g
+ of distribution terms SHOULD look here for a URL uniquely defining
+ the license. If no instance of this field is present, or if no
+ instance contains a parseable URL, and implementation MAY look
+ in the COPYRIGHT field for such a URL.
+\item{ORGANIZATION:} Studio name, Publisher, or other organization
+ involved in the creation of the video.
+
+\item{DIRECTOR:} Director or Filmmaker credit, similar to ARTIST.
+\item{PRODUCER:} Producer credit for the video.
+\item{COMPOSER:} Music credit for the video.
+\item{ACTOR:} Acting credit for the video.
+
+\item{TAG:} subject or category tag, keyword, or other content
+ classification labels. The value of each instance of this
+ field SHOULD be treated as a single label, with multiple
+ instances of the field for multiple tags. The value of
+ a single field SHOULD NOT be parsed into multiple tags
+ based on some internal delimeter.
+\item{DESCRIPTION:} General description, summary, or blurb.
+\end{description}
+
+\section{Setup Header}
+\label{sec:setupheader}
+
+The Theora setup header contains the limit values used to drive the loop
+ filter, the base matrices and scale values used to build the dequantization
+ tables, and the Huffman tables used to unpack the DCT tokens.
+Because the contents of this header are specific to Theora, no concessions have
+ been made to keep the fields octet-aligned for easy parsing.
+
+\begin{figure}
+\begin{center}
+\begin{tabular}{ | c | }
+ \hline
+ common header block \\ \hline
+ loop filter table resolution \\ \hline
+ loop filter table \\ \hline
+ scale table resolution \\ \hline
+ AC scale table \\ \hline
+ DC scale table \\ \hline
+ number of base matricies \\ \hline
+ base quatization matricies \\ \hline
+ ... \\ \hline
+ quant range interpolation table \\ \hline
+ DCT token Huffman tables \\
+ \hline
+\end{tabular}
+\end{center}
+\caption{Setup Header structure}
+\label{fig:setupheader}
+\end{figure}
+
+\subsection{Loop Filter Limit Table Decode}
+\label{sub:loop-filter-limits}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{LFLIMS} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 7 & No & A 64-element array of loop filter limit
+ values. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\qi} & Integer & 6 & No & The quantization index. \\
+\locvar{NBITS} & Integer & 3 & No & The size of values being read in the
+ current table. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure decodes the table of loop filter limit values used to drive the
+ loop filter, which is described in Section~\ref{sub:loop-filter-limits}.
+It is decoded as follows:
+
+\begin{enumerate}
+\item
+Read a 3-bit unsigned integer as \locvar{NBITS}.
+\item
+For each consecutive value of \locvar{\qi} from $0$ to $63$, inclusive:
+\begin{enumerate}
+\item
+Read an \locvar{NBITS}-bit unsigned integer as $\bitvar{LFLIMS}[\locvar{\qi}]$.
+\end{enumerate}
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+The loop filter limit values are hardcoded in VP3.
+The values used are given in Appendix~\ref{app:vp3-loop-filter-limits}.
+
+\subsection{Quantization Parameters Decode}
+\label{sub:quant-params}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{ACSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 16 & No & A 64-element array of scale values for
+ AC coefficients for each \qi\ value. \\
+\bitvar{DCSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 16 & No & A 64-element array of scale values for
+ the DC coefficient for each \qi\ value. \\
+\bitvar{NBMS} & Integer & 10 & No & The number of base matrices. \\
+\bitvar{BMS} & \multicolumn{1}{p{50pt}}{2D Integer array} &
+ 8 & No & A $\bitvar{NBMS}\times 64$ array
+ containing the base matrices. \\
+\bitvar{NQRS} & \multicolumn{1}{p{50pt}}{2D Integer array} &
+ 6 & No & A $2\times 3$ array containing the
+ number of quant ranges for a given \qti\ and \pli, respectively.
+This is at most $63$. \\
+\bitvar{QRSIZES} & \multicolumn{1}{p{50pt}}{3D Integer array} &
+ 6 & No & A $2\times 3\times 63$ array of the
+ sizes of each quant range for a given \qti\ and \pli, respectively.
+Only the first $\bitvar{NQRS}[\qti][\pli]$ values are used. \\
+\bitvar{QRBMIS} & \multicolumn{1}{p{50pt}}{3D Integer array} &
+ 9 & No & A $2\times 3\times 64$ array of the
+ \bmi's used for each quant range for a given \qti\ and \pli, respectively.
+Only the first $(\bitvar{NQRS}[\qti][\pli]+1)$ values are used. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\qti} & Integer & 1 & No & A quantization type index.
+See Table~\ref{tab:quant-types}.\\
+\locvar{\qtj} & Integer & 1 & No & A quantization type index. \\
+\locvar{\pli} & Integer & 2 & No & A color plane index.
+See Table~\ref{tab:color-planes}.\\
+\locvar{\plj} & Integer & 2 & No & A color plane index. \\
+\locvar{\qi} & Integer & 6 & No & The quantization index. \\
+\locvar{\ci} & Integer & 6 & No & The DCT coefficient index. \\
+\locvar{\bmi} & Integer & 9 & No & The base matrix index. \\
+\locvar{\qri} & Integer & 6 & No & The quant range index. \\
+\locvar{NBITS} & Integer & 5 & No & The size of fields to read. \\
+\locvar{NEWQR} & Integer & 1 & No & Flag that indicates a new set of quant
+ ranges will be defined. \\
+\locvar{RPQR} & Integer & 1 & No & Flag that indicates the quant ranges to
+ copy will come from the same color plane. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The AC scale and DC scale values are defined in two simple tables with 64
+ values each, one for each \qi\ value.
+The same scale values are used for every quantization type and color plane.
+
+The base matrices for all quantization types and color planes are stored in a
+ single table.
+These are then referenced by index in several sets of \term{quant ranges}.
+The purpose of the quant ranges is to specify which base matrices are used for
+ which \qi\ values.
+
+A set of quant ranges is defined for each quantization type and color plane.
+To save space in the header, bit flags allow a set of quant ranges to be copied
+ from a previously defined set instead of being specified explicitly.
+Every set except the first one can be copied from the immediately preceding
+ set.
+Similarly, if the quantization type is not $0$, the set can be copied from the
+ set defined for the same color plane for the preceding quantization type.
+This formulation allows compact representation of, for example, the same
+ set of quant ranges in both chroma channels, as is done in the original VP3,
+ or the same set of quant ranges in INTRA and INTER modes.
+
+Each quant range is defined by a size and two base matrix indices, one for each
+ end of the range.
+The base matrix for the end of one range is used as the start of the next
+ range, so that for $n$ ranges, $n+1$ base matrices are specified.
+The base matrices for the \qi\ values between the two endpoints of the range
+ are generated by linear interpolation.
+
+%TODO: figure
+
+The location of the endpoints of each range is encoded by their size.
+The \qi\ value for the left end-point is the sum of the sizes of all preceding
+ ranges, and the \qi\ value for the right end-point adds the size of the
+ current range.
+Thus the sum of the sizes of all the ranges MUST be 63, so that the last range
+ falls on the last possible \qi\ value.
+
+The complete set of quantization parameters are decoded as follows:
+
+\begin{enumerate}
+\item
+Read a 4-bit unsigned integer.
+Assign \locvar{NBITS} the value read, plus one.
+\item
+For each consecutive value of \locvar{\qi} from $0$ to $63$, inclusive:
+\begin{enumerate}
+\item
+Read an \locvar{NBITS}-bit unsigned integer as
+ $\bitvar{ACSCALE}[\locvar{\qi}]$.
+\end{enumerate}
+\item
+Read a 4-bit unsigned integer.
+Assign \locvar{NBITS} the value read, plus one.
+\item
+For each consecutive value of \locvar{\qi} from $0$ to $63$, inclusive:
+\begin{enumerate}
+\item
+Read an \locvar{NBITS}-bit unsigned integer as
+ $\bitvar{DCSCALE}[\locvar{\qi}]$.
+\end{enumerate}
+\item
+Read a 9-bit unsigned integer.
+Assign \bitvar{NBMS} the value decoded, plus one.
+\bitvar{NBMS} MUST be no greater than 384.
+\item
+For each consecutive value of \locvar{\bmi} from $0$ to $(\bitvar{NBMS}-1)$,
+ inclusive:
+\begin{enumerate}
+\item
+For each consecutive value of \locvar{\ci} from $0$ to $63$, inclusive:
+\begin{enumerate}
+\item
+Read an 8-bit unsigned integer as $\bitvar{BMS}[\locvar{\bmi}][\locvar{\ci}]$.
+\end{enumerate}
+\end{enumerate}
+\item
+For each consecutive value of \locvar{\qti} from $0$ to $1$, inclusive:
+\begin{enumerate}
+\item
+For each consecutive value of \locvar{\pli} from $0$ to $2$, inclusive:
+\begin{enumerate}
+\item
+If $\locvar{\qti}>0$ or $\locvar{\pli}>0$, read a 1-bit unsigned integer as
+ \locvar{NEWQR}.
+\item
+Else, assign \locvar{NEWQR} the value one.
+\item
+If \locvar{NEWQR} is zero, then we are copying a previously defined set of
+ quant ranges.
+In that case:
+\begin{enumerate}
+\item
+If $\locvar{\qti}>0$, read a 1-bit unsigned integer as \locvar{RPQR}.
+\item
+Else, assign \locvar{RPQR} the value zero.
+\item
+If \locvar{RPQR} is one, assign \locvar{\qtj} the value $(\locvar{\qti}-1)$
+ and assign \locvar{\plj} the value \locvar{\pli}.
+This selects the set of quant ranges defined for the same color plane as this
+ one, but for the previous quantization type.
+\item
+Else assign \locvar{\qtj} the value $(3*\locvar{\qti}+\locvar{\pli}-1)//3$ and
+ assign \locvar{\plj} the value $(\locvar{\pli}+2)\%3$.
+This selects the most recent set of quant ranges defined.
+\item
+Assign $\bitvar{NQRS}[\locvar{\qti}][\locvar{\pli}]$ the value
+ $\bitvar{NQRS}[\locvar{\qtj}][\locvar{\plj}]$.
+\item
+Assign $\bitvar{QRSIZES}[\locvar{\qti}][\locvar{\pli}]$ the values in
+ $\bitvar{QRSIZES}[\locvar{\qtj}][\locvar{\plj}]$.
+\item
+Assign $\bitvar{QRBMIS}[\locvar{\qti}][\locvar{\pli}]$ the values in
+ $\bitvar{QRBMIS}[\locvar{\qtj}][\locvar{\plj}]$.
+\end{enumerate}
+\item
+Else, \locvar{NEWQR} is one, which indicates that we are defining a new set of
+ quant ranges.
+In that case:
+\begin{enumerate}
+\item
+Assign $\locvar{\qri}$ the value zero.
+\item
+Assign $\locvar{\qi}$ the value zero.
+\item
+Read an $\ilog(\bitvar{NBMS}-1)$-bit unsigned integer as\\
+ $\bitvar{QRBMIS}[\locvar{\qti}][\locvar{\pli}][\locvar{\qri}]$.
+If this is greater than or equal to \bitvar{NBMS}, stop.
+The stream is undecodable.
+\item
+\label{step:qr-loop}
+Read an $\ilog(62-\locvar{\qi})$-bit unsigned integer.
+Assign\\ $\bitvar{QRSIZES}[\locvar{\qti}][\locvar{\pli}][\locvar{\qri}]$ the value
+ read, plus one.
+\item
+Assign \locvar{\qi} the value $\locvar{\qi}+
+ \bitvar{QRSIZES}[\locvar{\qti}][\locvar{\pli}][\locvar{\qri}]$.
+\item
+Assign \locvar{\qri} the value $\locvar{\qri}+1$.
+\item
+Read an $\ilog(\bitvar{NBMS}-1)$-bit unsigned integer as\\
+ $\bitvar{QRBMIS}[\locvar{\qti}][\locvar{\pli}][\locvar{\qri}]$.
+\item
+If \locvar{\qi} is less than 63, go back to step~\ref{step:qr-loop}.
+\item
+If \locvar{\qi} is greater than 63, stop.
+The stream is undecodable.
+\item
+Assign $\bitvar{NQRS}[\locvar{\qti}][\locvar{\pli}]$ the value \locvar{\qri}.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+The quantization parameters are hardcoded in VP3.
+The values used are given in Appendix~\ref{app:vp3-quant-params}.
+
+\subsection{Computing a Quantization Matrix}
+\label{sub:quant-mat}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{ACSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 16 & No & A 64-element array of scale values for
+ AC coefficients for each \qi\ value. \\
+\bitvar{DCSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 16 & No & A 64-element array of scale values for
+ the DC coefficient for each \qi\ value. \\
+\bitvar{BMS} & \multicolumn{1}{p{50pt}}{2D Integer array} &
+ 8 & No & A $\bitvar{NBMS}\times 64$ array
+ containing the base matrices. \\
+\bitvar{NQRS} & \multicolumn{1}{p{50pt}}{2D Integer array} &
+ 6 & No & A $2\times 3$ array containing the
+ number of quant ranges for a given \qti\ and \pli, respectively.
+This is at most $63$. \\
+\bitvar{QRSIZES} & \multicolumn{1}{p{50pt}}{3D Integer array} &
+ 6 & No & A $2\times 3\times 63$ array of the
+ sizes of each quant range for a given \qti\ and \pli, respectively.
+Only the first $\bitvar{NQRS}[\qti][\pli]$ values are used. \\
+\bitvar{QRBMIS} & \multicolumn{1}{p{50pt}}{3D Integer array} &
+ 9 & No & A $2\times 3\times 64$ array of the
+ \bmi's used for each quant range for a given \qti\ and \pli, respectively.
+Only the first $(\bitvar{NQRS}[\qti][\pli]+1)$ values are used. \\
+\bitvar{\qti} & Integer & 1 & No & A quantization type index.
+See Table~\ref{tab:quant-types}.\\
+\bitvar{\pli} & Integer & 2 & No & A color plane index.
+See Table~\ref{tab:color-planes}.\\
+\bitvar{\qi} & Integer & 6 & No & The quantization index. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{QMAT} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 16 & No & A 64-element array of quantization
+ values for each DCT coefficient in natural order. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\ci} & Integer & 6 & No & The DCT coefficient index. \\
+\locvar{\bmi} & Integer & 9 & No & The base matrix index. \\
+\locvar{\bmj} & Integer & 9 & No & The base matrix index. \\
+\locvar{\qri} & Integer & 6 & No & The quant range index. \\
+\locvar{QISTART} & Integer & 6 & No & The left end-point of the \qi\ range. \\
+\locvar{QIEND } & Integer & 6 & No & The right end-point of the \qi\ range. \\
+\locvar{BM} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 8 & No & A 64-element array containing the
+ interpolated base matrix. \\
+\locvar{QMIN} & Integer & 16 & No & The minimum quantization value allowed
+ for the current coefficient. \\
+\locvar{QSCALE} & Integer & 16 & No & The current scale value. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The following procedure can be used to generate a single quantization matrix
+ for a given quantization type, color plane, and \qi\ value, given the
+ quantization parameters decoded in Section~\ref{sub:quant-params}.
+
+Note that the product of the scale value and the base matrix value is in units
+ of $100$ths of a pixel value, and thus is divided by $100$ to return it to
+ units of a single pixel value.
+This value is then scaled by four, to match the scaling of the DCT output,
+ which is also a factor of four larger than the orthonormal version of the
+ transform.
+
+\begin{enumerate}
+\item
+Assign \locvar{\qri} the index of a quant range such that
+\begin{displaymath}
+\bitvar{\qi} \ge \sum_{\qrj=0}^{\locvar{\qri}-1}
+ \bitvar{QRSIZES}[\bitvar{\qti}][\bitvar{\pli}][\qrj],
+\end{displaymath}
+ and
+\begin{displaymath}
+\bitvar{\qi} \le \sum_{\qrj=0}^{\locvar{\qri}}
+ \bitvar{QRSIZES}[\bitvar{\qti}][\bitvar{\pli}][\qrj],
+\end{displaymath}
+ where summation from $0$ to $-1$ is defined to be zero.
+If there is more than one such value of $\locvar{\qri}$, i.e., if \bitvar{\qi}
+ lies on the boundary between two quant ranges, then the output will be the
+ same regardless of which one is chosen.
+\item
+Assign \locvar{QISTART} the value
+\begin{displaymath}
+\sum_{\qrj=0}^{\qri-1} \bitvar{QRSIZES}[\bitvar{\qti}][\bitvar{\pli}][\qrj].
+\end{displaymath}
+\item
+Assign \locvar{QIEND} the value
+\begin{displaymath}
+\sum_{\qrj=0}^{\qri} \bitvar{QRSIZES}[\bitvar{\qti}][\bitvar{\pli}][\qrj].
+\end{displaymath}
+\item
+Assign \locvar{\bmi} the value
+ $\bitvar{QRBMIS}[\bitvar{\qti}][\bitvar{\pli}][\qri]$.
+\item
+Assign \locvar{\bmj} the value
+ $\bitvar{QRBMIS}[\bitvar{\qti}][\bitvar{\pli}][\qri+1]$.
+\item
+For each consecutive value of \locvar{\ci} from $0$ to $63$, inclusive:
+\begin{enumerate}
+\item
+Assign $\locvar{BM}[\locvar{\ci}]$ the value
+\begin{displaymath}
+\begin{split}
+(&2*(\locvar{QIEND}-\bitvar{\qi})*\bitvar{BMS}[\locvar{\bmi}][\locvar{\ci}]\\
+ &+2*(\bitvar{\qi}-
+ \locvar{QISTART})*\bitvar{BMS}[\locvar{\bmj}][\locvar{\ci}]\\
+ &+\bitvar{QRSIZES}[\bitvar{\qti}][\bitvar{\pli}][\locvar{\qri}])//
+ (2*\bitvar{QRSIZES}[\bitvar{\qti}][\bitvar{\pli}][\locvar{\qri}])
+\end{split}
+\end{displaymath}
+\item
+Assign \locvar{QMIN} the value given by Table~\ref{tab:qmin} according to
+ \bitvar{\qti} and \locvar{\ci}.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{clr}\toprule
+Coefficient & \multicolumn{1}{c}{\bitvar{\qti}}
+ & \locvar{QMIN} \\\midrule
+$\locvar{\ci}=0$ & $0$ (Intra) & $16$ \\
+$\locvar{\ci}>0$ & $0$ (Intra) & $8$ \\
+$\locvar{\ci}=0$ & $1$ (Inter) & $32$ \\
+$\locvar{\ci}>0$ & $1$ (Inter) & $16$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Minimum Quantization Values}
+\label{tab:qmin}
+\end{table}
+
+\item
+If \locvar{\ci} equals zero, assign $\locvar{QSCALE}$ the value
+ $\bitvar{DCSCALE}[\bitvar{\qi}]$.
+\item
+Else, assign $\locvar{QSCALE}$ the value
+ $\bitvar{ACSCALE}[\bitvar{\qi}]$.
+\item
+Assign $\bitvar{QMAT}[\locvar{\ci}]$ the value
+\begin{displaymath}
+\max(\locvar{QMIN},
+ \min((\locvar{QSCALE}*\locvar{BM}[\locvar{\ci}]//100)*4,4096)).
+\end{displaymath}
+\end{enumerate}
+\end{enumerate}
+
+\subsection{DCT Token Huffman Tables}
+\label{sub:huffman-tables}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{HTS} & \multicolumn{3}{l}{Huffman table array}
+ & An 80-element array of Huffman tables
+ with up to 32 entries each. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{HBITS} & Bit string & 32 & No & A string of up to 32 bits. \\
+\locvar{TOKEN} & Integer & 5 & No & A single DCT token value. \\
+\locvar{ISLEAF} & Integer & 1 & No & Flag that indicates if the current
+ node of the tree being decoded is a leaf node. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The Huffman tables used to decode DCT tokens are stored in the setup header in
+ the form of a binary tree.
+This enforces the requirements that the code be full---so that any sequence of
+ bits will produce a valid sequence of tokens---and that the code be
+ prefix-free so that there is no ambiguity when decoding.
+
+One more restriction is placed on the tables that is not explicitly enforced by
+ the bitstream syntax, but nevertheless must be obeyed by compliant encoders.
+There must be no more than 32 entries in a single table.
+Note that this restriction along with the fullness requirement limit the
+ maximum size of a single Huffman code to 32 bits.
+It is probably a good idea to enforce this latter consequence explicitly when
+ implementing the decoding procedure as a recursive algorithm, so as to prevent
+ a possible stack overflow given an invalid bitstream.
+
+Although there are 32 different DCT tokens, and thus a normal table will have
+ exactly 32 entries, this is not explicitly required.
+It is allowable to use a Huffman code that omits some---but not all---of the
+ possible token values.
+It is also allowable, if not particularly useful, to specify multiple codes for
+ the same token value in a single table.
+Note also that token values may appear in the tree in any order.
+In particular, it is not safe to assume that token value zero (which ends a
+ single block), has a Huffman code of all zeros.
+
+The tree is decoded as follows:
+
+\begin{enumerate}
+\item
+For each consecutive value of \locvar{\hti} from $0$ to $79$, inclusive:
+\begin{enumerate}
+\item
+Set \locvar{HBITS} to the empty string.
+\item
+\label{step:huff-tree-loop}
+If \locvar{HBITS} is longer than 32 bits in length, stop.
+The stream is undecodable.
+\item
+Read a 1-bit unsigned integer as \locvar{ISLEAF}.
+\item
+If \locvar{ISLEAF} is one:
+\begin{enumerate}
+\item
+If the number of entries in table $\bitvar{HTS}[\locvar{\hti}]$ is already 32,
+ stop.
+The stream is undecodable.
+\item
+Read a 5-bit unsigned integer as \locvar{TOKEN}.
+\item
+Add the pair $(\locvar{HBITS},\locvar{TOKEN})$ to Huffman table
+ $\bitvar{HTS}[\locvar{\hti}]$.
+\end{enumerate}
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Add a `0' to the end of \locvar{HBITS}.
+\item
+Decode the `0' sub-tree using this procedure, starting from
+ step~\ref{step:huff-tree-loop}.
+\item
+Remove the `0' from the end of \locvar{HBITS} and add a `1' to the end of
+ \locvar{HBITS}.
+\item
+Decode the `1' sub-tree using this procedure, starting from
+ step~\ref{step:huff-tree-loop}.
+\item
+Remove the `1' from the end of \locvar{HBITS}.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+The DCT token Huffman tables are hardcoded in VP3.
+The values used are given in Appendix~\ref{app:vp3-huffman-tables}.
+
+\subsection{Setup Header Decode}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{LFLIMS} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 7 & No & A 64-element array of loop filter limit
+ values. \\
+\bitvar{ACSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 16 & No & A 64-element array of scale values for
+ AC coefficients for each \qi\ value. \\
+\bitvar{DCSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 16 & No & A 64-element array of scale values for
+ the DC coefficient for each \qi\ value. \\
+\bitvar{NBMS} & Integer & 10 & No & The number of base matrices. \\
+\bitvar{BMS} & \multicolumn{1}{p{50pt}}{2D Integer array} &
+ 8 & No & A $\bitvar{NBMS}\times 64$ array
+ containing the base matrices. \\
+\bitvar{NQRS} & \multicolumn{1}{p{50pt}}{2D Integer array} &
+ 6 & No & A $2\times 3$ array containing the
+ number of quant ranges for a given \qti\ and \pli, respectively.
+This is at most $63$. \\
+\bitvar{QRSIZES} & \multicolumn{1}{p{50pt}}{3D Integer array} &
+ 6 & No & A $2\times 3\times 63$ array of the
+ sizes of each quant range for a given \qti\ and \pli, respectively.
+Only the first $\bitvar{NQRS}[\qti][\pli]$ values will be used. \\
+\bitvar{QRBMIS} & \multicolumn{1}{p{50pt}}{3D Integer array} &
+ 9 & No & A $2\times 3\times 64$ array of the
+ \bmi's used for each quant range for a given \qti\ and \pli, respectively.
+Only the first $(\bitvar{NQRS}[\qti][\pli]+1)$ values will be used. \\
+\bitvar{HTS} & \multicolumn{3}{l}{Huffman table array}
+ & An 80-element array of Huffman tables
+ with up to 32 entries each. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:} None.
+\medskip
+
+The complete setup header is decoded as follows:
+
+\begin{enumerate}
+\item
+Decode the common header fields according to the procedure described in
+ Section~\ref{sub:common-header}.
+If \bitvar{HEADERTYPE} returned by this procedure is not \hex{82}, then stop.
+This packet is not the setup header.
+\item
+Decode the loop filter limit value table using the procedure given in
+ Section~\ref{sub:loop-filter-limits} into \bitvar{LFLIMS}.
+\item
+Decode the quantization parameters using the procedure given in
+ Section~\ref{sub:quant-params}.
+The results are stored in \bitvar{ACSCALE}, \bitvar{DCSCALE}, \bitvar{NBMS},
+ \bitvar{BMS}, \bitvar{NQRS}, \bitvar{QRSIZES}, and \bitvar{QRBMIS}.
+\item
+Decode the DCT token Huffman tables using the procedure given in
+ Section~\ref{sub:huffman-tables} into \bitvar{HTS}.
+\end{enumerate}
+
+\chapter{Frame Decode}
+
+This section describes the complete procedure necessary to decode a single
+ frame.
+This begins with the frame header, followed by coded block flags, macro block
+ modes, motion vectors, block-level \qi\ values, and finally the DCT residual
+ tokens, which are used to reconstruct the frame.
+
+\section{Frame Header Decode}
+\label{sub:frame-header}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{FTYPE} & Integer & 1 & No & The frame type. \\
+\bitvar{NQIS} & Integer & 2 & No & The number of \qi\ values. \\
+\bitvar{QIS} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 6 & No & An \bitvar{NQIS}-element array of
+ \qi\ values. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{MOREQIS} & Integer & 1 & No & A flag indicating there are more
+ \qi\ values to be decoded. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The frame header selects which type of frame is being decoded, intra or inter,
+ and contains the list of \qi\ values that will be used in this frame.
+The first \qi\ value will be used for {\em all} DC coefficients in all blocks.
+This is done to ensure that DC prediction, which is done in the quantized
+ domain, works as expected.
+The AC coefficients, however, can be dequantized using any \qi\ value on the
+ list, selected on a block-by-block basis.
+
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer.
+If the value read is not zero, stop.
+This is not a data packet.
+\item
+Read a 1-bit unsigned integer as \bitvar{FTYPE}.
+This is the type of frame being decoded, as given in
+ Table~\ref{tab:frame-type}.
+If this is the first frame being decoded, this MUST be zero.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{cl}\toprule
+\bitvar{FTYPE} & Frame Type \\\midrule
+$0$ & Intra frame \\
+$1$ & Inter frame \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Frame Type Values}
+\label{tab:frame-type}
+\end{table}
+
+\item
+Read in a 6-bit unsigned integer as $\bitvar{QIS}[0]$.
+\item
+Read a 1-bit unsigned integer as \locvar{MOREQIS}.
+\item
+If \locvar{MOREQIS} is zero, set \bitvar{NQIS} to 1.
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Read in a 6-bit unsigned integer as $\bitvar{QIS}[1]$.
+\item
+Read a 1-bit unsigned integer as \locvar{MOREQIS}.
+\item
+If \locvar{MOREQIS} is zero, set \bitvar{NQIS} to 2.
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Read in a 6-bit unsigned integer as $\bitvar{QIS}[2]$.
+\item
+Set \bitvar{NQIS} to 3.
+\end{enumerate}
+\end{enumerate}
+\item
+If \bitvar{FTYPE} is 0, read a 3-bit unsigned integer.
+These bits are reserved.
+If this value is not zero, stop.
+This frame is not decodable according to this specification.
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+The precise format of the frame header is substantially different in Theora
+ than in VP3.
+The original VP3 format includes a larger number of unused, reserved bits that
+ are required to be zero.
+The original VP3 frame header also can contain only a single \qi\ value,
+ because VP3 does not support block-level \qi\ values and uses the same
+ \qi\ value for all the coefficients in a frame.
+
+\section{Run-Length Encoded Bit Strings}
+
+Two variations of run-length encoding are used to store sequences of bits for
+ the block coded flags and the block-level \qi\ values.
+The procedures to decode these bit sequences are specified in the following two
+ sections.
+
+\subsection{Long-Run Bit String Decode}
+\label{sub:long-run}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{NBITS} & Integer & 36 & No & The number of bits to decode. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{BITS} & Bit string & & & The decoded bits. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{LEN} & Integer & 36 & No & The number of bits decoded so far. \\
+\locvar{BIT} & Integer & 1 & No & The value associated with the current
+ run. \\
+\locvar{RLEN} & Integer & 13 & No & The length of the current run. \\
+\locvar{RBITS} & Integer & 4 & No & The number of extra bits needed to
+ decode the run length. \\
+\locvar{RSTART} & Integer & 6 & No & The start of the possible run-length
+ values for a given Huffman code. \\
+\locvar{ROFFS} & Integer & 12 & No & The offset from \locvar{RSTART} of the
+ run-length. \\
+\bottomrule\end{tabularx}
+\medskip
+
+There is no practical limit to the number of consecutive 0's and 1's that can
+ be decoded with this procedure.
+In reality, the run length is limited by the number of blocks in a single
+ frame, because more will never be requested.
+A separate procedure described in Section~\ref{sub:short-run} is used when
+ there is a known limit on the maximum size of the runs.
+
+For the first run, a single bit value is read, and then a Huffman-coded
+ representation of a run length is decoded, and that many copies of the bit
+ value are appended to the bit string.
+For each consecutive run, the value of the bit is toggled instead of being read
+ from the bitstream.
+
+The only exception is if the length of the previous run was 4129, the maximum
+ possible length encodable by the Huffman-coded representation.
+In this case another bit value is read from the stream, to allow for
+ consecutive runs of 0's or 1's longer than this maximum.
+
+Note that in both cases---for the first run and after a run of length 4129---if
+ no more bits are needed, then no bit value is read.
+
+The complete decoding procedure is as follows:
+
+\begin{enumerate}
+\item
+Assign \locvar{LEN} the value 0.
+\item
+Assign \bitvar{BITS} the empty string.
+\item
+If \locvar{LEN} equals \bitvar{NBITS}, return the completely decoded string
+ \bitvar{BITS}.
+\item
+Read a 1-bit unsigned integer as \locvar{BIT}.
+\item
+\label{step:long-run-loop}
+Read a bit at a time until one of the Huffman codes given in
+ Table~\ref{tab:long-run} is recognized.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{lrrl}\toprule
+Huffman Code & \locvar{RSTART} & \locvar{RBITS} & Run Lengths \\\midrule
+\bin{0} & $1$ & $0$ & $1$ \\
+\bin{10} & $2$ & $1$ & $2\ldots 3$ \\
+\bin{110} & $4$ & $1$ & $4\ldots 5$ \\
+\bin{1110} & $6$ & $2$ & $6\ldots 9$ \\
+\bin{11110} & $10$ & $3$ & $10\ldots 17$ \\
+\bin{111110} & $18$ & $4$ & $18\ldots 33$ \\
+\bin{111111} & $34$ & $12$ & $34\ldots 4129$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Huffman Codes for Long Run Lengths}
+\label{tab:long-run}
+\end{table}
+
+\item
+Assign \locvar{RSTART} and \locvar{RBITS} the values given in
+ Table~\ref{tab:long-run} according to the Huffman code read.
+\item
+Read an \locvar{RBITS}-bit unsigned integer as \locvar{ROFFS}.
+\item
+Assign \locvar{RLEN} the value $(\locvar{RSTART}+\locvar{ROFFS})$.
+\item
+Append \locvar{RLEN} copies of \locvar{BIT} to \bitvar{BITS}.
+\item
+Add \locvar{RLEN} to the value \locvar{LEN}.
+\locvar{LEN} MUST be less than or equal to \bitvar{NBITS}.
+\item
+If \locvar{LEN} equals \bitvar{NBITS}, return the completely decoded string
+ \bitvar{BITS}.
+\item
+If \locvar{RLEN} equals 4129, read a 1-bit unsigned integer as \locvar{BIT}.
+\item
+Otherwise, assign \locvar{BIT} the value $(1-\locvar{BIT})$.
+\item
+Continue decoding runs from step~\ref{step:long-run-loop}.
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+VP3 does not read a new bit value after decoding a run length of 4129.
+This limits the maximum number of consecutive 0's or 1's to 4129 in
+ VP3-compatible streams.
+For reasonable video sizes of $1920\times 1080$ or less in 4:2:0 format---the
+ only pixel format VP3 supports---this does not pose any problems because runs
+ longer than 4129 are not needed.
+
+\subsection{Short-Run Bit String Decode}
+\label{sub:short-run}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{NBITS} & Integer & 36 & No & The number of bits to decode. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{BITS} & Bit string & & & The decoded bits. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{LEN} & Integer & 36 & No & The number of bits decoded so far. \\
+\locvar{BIT} & Integer & 1 & No & The value associated with the current
+ run. \\
+\locvar{RLEN} & Integer & 13 & No & The length of the current run. \\
+\locvar{RBITS} & Integer & 4 & No & The number of extra bits needed to
+ decode the run length. \\
+\locvar{RSTART} & Integer & 6 & No & The start of the possible run-length
+ values for a given Huffman code. \\
+\locvar{ROFFS} & Integer & 12 & No & The offset from \locvar{RSTART} of the
+ run-length. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure is similar to the procedure outlined in
+ Section~\ref{sub:long-run}, except that the maximum number of consecutive 0's
+ or 1's is limited to 30.
+This is the maximum run length needed when encoding a bit for each of the 16
+ blocks in a super block when it is known that not all the bits in a super
+ block are the same.
+
+The complete decoding procedure is as follows:
+
+\begin{enumerate}
+\item
+Assign \locvar{LEN} the value 0.
+\item
+Assign \bitvar{BITS} the empty string.
+\item
+If \locvar{LEN} equals \bitvar{NBITS}, return the completely decoded string
+ \bitvar{BITS}.
+\item
+Read a 1-bit unsigned integer as \locvar{BIT}.
+\item
+\label{step:short-run-loop}
+Read a bit at a time until one of the Huffman codes given in
+ Table~\ref{tab:short-run} is recognized.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{lrrl}\toprule
+Huffman Code & \locvar{RSTART} & \locvar{RBITS} & Run Lengths \\\midrule
+\bin{0} & $1$ & $1$ & $1\ldots 2$ \\
+\bin{10} & $3$ & $1$ & $3\ldots 4$ \\
+\bin{110} & $5$ & $1$ & $5\ldots 6$ \\
+\bin{1110} & $7$ & $2$ & $7\ldots 10$ \\
+\bin{11110} & $11$ & $2$ & $11\ldots 14$ \\
+\bin{11111} & $15$ & $4$ & $15\ldots 30$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Huffman Codes for Short Run Lengths}
+\label{tab:short-run}
+\end{table}
+
+\item
+Assign \locvar{RSTART} and \locvar{RBITS} the values given in
+ Table~\ref{tab:short-run} according to the Huffman code read.
+\item
+Read an \locvar{RBITS}-bit unsigned integer as \locvar{ROFFS}.
+\item
+Assign \locvar{RLEN} the value $(\locvar{RSTART}+\locvar{ROFFS})$.
+\item
+Append \locvar{RLEN} copies of \locvar{BIT} to \bitvar{BITS}.
+\item
+Add \locvar{RLEN} to the value \locvar{LEN}.
+\locvar{LEN} MUST be less than or equal to \bitvar{NBITS}.
+\item
+If \locvar{LEN} equals \bitvar{NBITS}, return the completely decoded string
+ \bitvar{BITS}.
+\item
+Assign \locvar{BIT} the value $(1-\locvar{BIT})$.
+\item
+Continue decoding runs from step~\ref{step:short-run-loop}.
+\end{enumerate}
+
+\section{Coded Block Flags Decode}
+\label{sub:coded-blocks}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{FTYPE} & Integer & 1 & No & The frame type. \\
+\bitvar{NSBS} & Integer & 32 & No & The total number of super blocks in a
+ frame. \\
+\bitvar{NBS} & Integer & 36 & No & The total number of blocks in a
+ frame. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{BCODED} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 1 & No & An \bitvar{NBS}-element array of flags
+ indicating which blocks are coded. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{NBITS} & Integer & 36 & No & The length of a bit string to decode. \\
+\locvar{BITS} & Bit string & & & A decoded set of flags. \\
+\locvar{SBPCODED} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 1 & No & An \bitvar{NSBS}-element array of flags
+ indicating whether or not each super block is partially coded. \\
+\locvar{SBFCODED} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 1 & No & An \bitvar{NSBS}-element array of flags
+ indicating whether or not each non-partially coded super block is fully
+ coded. \\
+\locvar{\sbi} & Integer & 32 & No & The index of the current super
+ block. \\
+\locvar{\bi} & Integer & 36 & No & The index of the current block in coded
+ order. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure determines which blocks are coded in a given frame.
+In an intra frame, it marks all blocks coded.
+In an inter frame, however, any or all of the blocks may remain uncoded.
+The output is a list of bit flags, one for each block, marking it coded or not
+ coded.
+
+It is important to note that flags are still decoded for any blocks which lie
+ entirely outside the picture region, even though they are not displayed.
+Encoders MAY choose to code such blocks.
+Decoders MUST faithfully reconstruct such blocks, because their contents can be
+ used for predictors in future frames.
+Flags are \textit{not} decoded for portions of a super block which lie outside
+ the full frame, as there are no blocks in those regions.
+
+The complete procedure is as follows:
+
+\begin{enumerate}
+\item
+If \bitvar{FTYPE} is zero (intra frame):
+\begin{enumerate}
+\item
+For each consecutive value of \locvar{\bi} from 0 to $(\locvar{NBS}-1)$, assign
+ $\bitvar{BCODED}[\locvar{\bi}]$ the value one.
+\end{enumerate}
+\item
+Otherwise (inter frame):
+\begin{enumerate}
+\item
+Assign \locvar{NBITS} the value \bitvar{NSBS}.
+\item
+Read an \locvar{NBITS}-bit bit string into \locvar{BITS}, using the procedure
+ described in Section~\ref{sub:long-run}.
+This represents the list of partially coded super blocks.
+\item
+For each consecutive value of \locvar{\sbi} from 0 to $(\locvar{NSBS}-1)$,
+ remove the bit at the head of the string \locvar{BITS} and assign it to
+ $\locvar{SBPCODED}[\locvar{\sbi}]$.
+\item
+Assign \locvar{NBITS} the total number of super blocks such that \\
+ $\locvar{SBPCODED}[\locvar{\sbi}]$ equals zero.
+\item
+Read an \locvar{NBITS}-bit bit string into \locvar{BITS}, using the procedure
+ described in Section~\ref{sub:long-run}.
+This represents the list of fully coded super blocks.
+\item
+For each consecutive value of \locvar{\sbi} from 0 to $(\locvar{NSBS}-1)$ such
+ that $\locvar{SBPCODED}[\locvar{\sbi}]$ equals zero, remove the bit at the
+ head of the string \locvar{BITS} and assign it to
+ $\locvar{SBFCODED}[\locvar{\sbi}]$.
+\item
+Assign \locvar{NBITS} the number of blocks contained in super blocks where
+ $\locvar{SBPCODED}[\locvar{\sbi}]$ equals one.
+Note that this might {\em not} be equal to 16 times the number of partially
+ coded super blocks, since super blocks which overlap the edge of the frame
+ will have fewer than 16 blocks in them.
+\item
+Read an \locvar{NBITS}-bit bit string into \locvar{BITS}, using the procedure
+ described in Section~\ref{sub:short-run}.
+\item
+For each block in coded order---indexed by \locvar{\bi}:
+\begin{enumerate}
+\item
+Assign \locvar{\sbi} the index of the super block containing block
+ \locvar{\bi}.
+\item
+If $\locvar{SBPCODED}[\locvar{\sbi}]$ is zero, assign
+ $\bitvar{BCODED}[\locvar{\bi}]$ the value $\locvar{SBFCODED}[\locvar{\sbi}]$.
+\item
+Otherwise, remove the bit at the head of the string \locvar{BITS} and assign it
+ to $\bitvar{BCODED}[\locvar{\bi}]$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\section{Macro Block Coding Modes}
+\label{sub:mb-modes}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{FTYPE} & Integer & 1 & No & The frame type. \\
+\bitvar{NMBS} & Integer & 32 & No & The total number of macro blocks in a
+ frame. \\
+\bitvar{NBS} & Integer & 36 & No & The total number of blocks in a
+ frame. \\
+\bitvar{BCODED} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 1 & No & An \bitvar{NBS}-element array of flags
+ indicating which blocks are coded. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{MBMODES} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 3 & No & An \bitvar{NMBS}-element array of coding
+ modes for each macro block. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{MSCHEME} & Integer & 3 & No & The mode coding scheme. \\
+\locvar{MALPHABET} & \multicolumn{1}{p{40pt}}{Integer array}
+ & 3 & No & The list of modes corresponding to each
+ Huffman code. \\
+\locvar{\mbi} & Integer & 32 & No & The index of the current macro
+ block. \\
+\locvar{\bi} & Integer & 36 & No & The index of the current block in
+ coded order. \\
+\locvar{\mi} & Integer & 3 & No & The index of a Huffman code from
+ Table~\ref{tab:mode-codes}, starting from $0$. \\
+\bottomrule\end{tabularx}
+\medskip
+
+In an intra frame, every macro block marked as coded in INTRA mode.
+In an inter frame, however, a macro block can be coded in one of eight coding
+ modes, given in Table~\ref{tab:coding-modes}.
+All of the blocks in all color planes contained in a macro block will be
+ assigned the coding mode of that macro block.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{cl}\toprule
+Index & Coding Mode \\\midrule
+$0$ & INTER\_NOMV \\
+$1$ & INTRA \\
+$2$ & INTER\_MV \\
+$3$ & INTER\_MV\_LAST \\
+$4$ & INTER\_MV\_LAST2 \\
+$5$ & INTER\_GOLDEN\_NOMV \\
+$6$ & INTER\_GOLDEN\_MV \\
+$7$ & INTER\_MV\_FOUR \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Macro Block Coding Modes}
+\label{tab:coding-modes}
+\end{table}
+
+An important thing to note is that a coding mode is only stored in the
+ bitstream for a macro block if it has at least one {\em luma} block coded.
+A macro block that contains coded blocks in the chroma planes, but not in the
+ luma plane, MUST be coded in INTER\_NOMV mode.
+Thus, no coding mode needs to be decoded for such a macro block.
+
+Coding modes are encoded using one of eight different schemes.
+Schemes 0 through 6 use the same simple Huffman code to represent the mode
+ numbers, as given in Table~\ref{tab:mode-codes}.
+The difference in the schemes is the mode number assigned to each code.
+Scheme 0 uses an assignment specified in the bitstream, while schemes 1--6 use
+ a fixed assignment, also given in Table~\ref{tab:mode-codes}.
+Scheme 7 simply codes each mode directly in the bitstream using three bits.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{lccccccc}\toprule
+Scheme & $1$ & $2$ & $3$ & $4$ & $5$ & $6$ & $7$ \\\cmidrule{2-7}
+Huffman Code & \multicolumn{6}{c}{Coding Mode} & \locvar{\mi} \\\midrule
+\bin{0} & $3$ & $3$ & $3$ & $3$ & $0$ & $0$ & $0$ \\
+\bin{10} & $4$ & $4$ & $2$ & $2$ & $3$ & $5$ & $1$ \\
+\bin{110} & $2$ & $0$ & $4$ & $0$ & $4$ & $3$ & $2$ \\
+\bin{1110} & $0$ & $2$ & $0$ & $4$ & $2$ & $4$ & $3$ \\
+\bin{11110} & $1$ & $1$ & $1$ & $1$ & $1$ & $2$ & $4$ \\
+\bin{111110} & $5$ & $5$ & $5$ & $5$ & $5$ & $1$ & $5$ \\
+\bin{1111110} & $6$ & $6$ & $6$ & $6$ & $6$ & $6$ & $6$ \\
+\bin{1111111} & $7$ & $7$ & $7$ & $7$ & $7$ & $7$ & $7$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Macro Block Mode Schemes}
+\label{tab:mode-codes}
+\end{table}
+
+\begin{enumerate}
+\item
+If \bitvar{FTYPE} is 0 (intra frame):
+\begin{enumerate}
+\item
+For each consecutive value of \locvar{\mbi} from 0 to $(\bitvar{NMBS}-1)$,
+ inclusive, assign $\bitvar{MBMODES}[\mbi]$ the value 1 (INTRA).
+\end{enumerate}
+\item
+Otherwise (inter frame):
+\begin{enumerate}
+\item
+Read a 3-bit unsigned integer as \locvar{MSCHEME}.
+\item
+If \locvar{MSCHEME} is 0:
+\begin{enumerate}
+\item
+For each consecutive value of \locvar{MODE} from 0 to 7, inclusive:
+\begin{enumerate}
+\item
+Read a 3-bit unsigned integer as \locvar{\mi}.
+\item
+Assign $\locvar{MALPHABET}[\mi]$ the value \locvar{MODE}.
+\end{enumerate}
+\end{enumerate}
+\item
+Otherwise, if \locvar{MSCHEME} is not 7, assign the entries of
+ \locvar{MALPHABET} the values in the corresponding column of
+ Table~\ref{tab:mode-codes}.
+\item
+For each consecutive macro block in coded order (cf.
+ Section~\ref{sec:mbs})---indexed by \locvar{\mbi}:
+\begin{enumerate}
+\item
+If a block \locvar{\bi} in the luma plane of macro block \locvar{\mbi} exists
+ such that $\bitvar{BCODED}[\locvar{\bi}]$ is 1:
+\begin{enumerate}
+\item
+If \locvar{MSCHEME} is not 7, read one bit at a time until one of the Huffman
+ codes in Table~\ref{tab:mode-codes} is recognized, and assign
+ $\bitvar{MBMODES}[\locvar{\mbi}]$ the value
+ $\locvar{MALPHABET}[\locvar{\mi}]$, where \locvar{\mi} is the index of the
+ Huffman code decoded.
+\item
+Otherwise, read a 3-bit unsigned integer as $\bitvar{MBMODES}[\locvar{\mbi}]$.
+\end{enumerate}
+\item
+Otherwise, if no luma-plane blocks in the macro block are coded, assign
+ $\bitvar{MBMODES}[\locvar{\mbi}]$ the value 0 (INTER\_NOMV).
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\section{Motion Vectors}
+
+In an intra frame, no motion vectors are used, and so motion vector decoding is
+ skipped.
+In an inter frame, however, many of the inter coding modes require a motion
+ vector in order to specify an offset into the reference frame from which to
+ predict a block.
+These procedures assigns such a motion vector to every block.
+
+\subsection{Motion Vector Decode}
+\label{sub:mv-decode}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{MVMODE} & Integer & 1 & No & The motion vector decoding method. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{MVX} & Integer & 6 & Yes & The X component of the motion
+ vector. \\
+\bitvar{MVY} & Integer & 6 & Yes & The Y component of the motion
+ vector. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{MVSIGN} & Integer & 1 & No & The sign of the motion vector component
+ just decoded. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The individual components of a motion vector can be coded using one of two
+ methods.
+The first uses a variable length Huffman code, given in
+ Table~\ref{tab:mv-huff-codes}.
+The second encodes the magnitude of the component directly in 5 bits, and the
+ sign in one bit.
+Note that in this case there are two representations for the value zero.
+For compatibility with VP3, a sign bit is read even if the magnitude read is
+ zero.
+One scheme is chosen and used for the entire frame.
+
+Each component can take on integer values from $-31\ldots 31$, inclusive, at
+ half-pixel resolution, i.e. $-15.5\ldots 15.5$ pixels in the luma plane.
+For each subsampled axis in the chroma planes, the corresponding motion vector
+ component is interpreted as being at quarter-pixel resolution, i.e.
+ $-7.75\ldots 7.75$ pixels.
+The precise details of how these vectors are used to compute predictors for
+ each block are described in Section~\ref{sec:predictors}.
+
+\begin{table}[ht]
+\begin{center}
+\begin{tabular}{lrlr}\toprule
+Huffman Code & Value & Huffman Code & Value \\\midrule
+\bin{000} & $0$ \\
+\bin{001} & $1$ & \bin{010} & $-1$ \\
+\bin{0110} & $2$ & \bin{0111} & $-2$ \\
+\bin{1000} & $3$ & \bin{1001} & $-3$ \\
+\bin{101000} & $4$ & \bin{101001} & $-4$ \\
+\bin{101010} & $5$ & \bin{101011} & $-5$ \\
+\bin{101100} & $6$ & \bin{101101} & $-6$ \\
+\bin{101110} & $7$ & \bin{101111} & $-7$ \\
+\bin{1100000} & $8$ & \bin{1100001} & $-8$ \\
+\bin{1100010} & $9$ & \bin{1100011} & $-9$ \\
+\bin{1100100} & $10$ & \bin{1100101} & $-10$ \\
+\bin{1100110} & $11$ & \bin{1100111} & $-11$ \\
+\bin{1101000} & $12$ & \bin{1101001} & $-12$ \\
+\bin{1101010} & $13$ & \bin{1101011} & $-13$ \\
+\bin{1101100} & $14$ & \bin{1101101} & $-14$ \\
+\bin{1101110} & $15$ & \bin{1101111} & $-15$ \\
+\bin{11100000} & $16$ & \bin{11100001} & $-16$ \\
+\bin{11100010} & $17$ & \bin{11100011} & $-17$ \\
+\bin{11100100} & $18$ & \bin{11100101} & $-18$ \\
+\bin{11100110} & $19$ & \bin{11100111} & $-19$ \\
+\bin{11101000} & $20$ & \bin{11101001} & $-20$ \\
+\bin{11101010} & $21$ & \bin{11101011} & $-21$ \\
+\bin{11101100} & $22$ & \bin{11101101} & $-22$ \\
+\bin{11101110} & $23$ & \bin{11101111} & $-23$ \\
+\bin{11110000} & $24$ & \bin{11110001} & $-24$ \\
+\bin{11110010} & $25$ & \bin{11110011} & $-25$ \\
+\bin{11110100} & $26$ & \bin{11110101} & $-26$ \\
+\bin{11110110} & $27$ & \bin{11110111} & $-27$ \\
+\bin{11111000} & $28$ & \bin{11111001} & $-28$ \\
+\bin{11111010} & $29$ & \bin{11111011} & $-29$ \\
+\bin{11111100} & $30$ & \bin{11111101} & $-30$ \\
+\bin{11111110} & $31$ & \bin{11111111} & $-31$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Huffman Codes for Motion Vector Components}
+\label{tab:mv-huff-codes}
+\end{table}
+
+A single motion vector is decoded is follows:
+
+\begin{enumerate}
+\item
+If \bitvar{MVMODE} is 0:
+\begin{enumerate}
+\item
+Read 1 bit at a time until one of the Huffman codes in
+ Table~\ref{tab:mv-huff-codes} is recognized, and assign the value to
+ \locvar{MVX}.
+\item
+Read 1 bit at a time until one of the Huffman codes in
+ Table~\ref{tab:mv-huff-codes} is recognized, and assign the value to
+ \locvar{MVY}.
+\end{enumerate}
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Read a 5-bit unsigned integer as \bitvar{MVX}.
+\item
+Read a 1-bit unsigned integer as \locvar{MVSIGN}.
+\item
+If \locvar{MVSIGN} is 1, assign \bitvar{MVX} the value $-\bitvar{MVX}$.
+\item
+Read a 5-bit unsigned integer as \bitvar{MVY}.
+\item
+Read a 1-bit unsigned integer as \locvar{MVSIGN}.
+\item
+If \locvar{MVSIGN} is 1, assign \bitvar{MVY} the value $-\bitvar{MVY}$.
+\end{enumerate}
+\end{enumerate}
+
+\subsection{Macro Block Motion Vector Decode}
+\label{sub:mb-mv-decode}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{PF} & Integer & 2 & No & The pixel format. \\
+\bitvar{NMBS} & Integer & 32 & No & The total number of macro blocks in a
+ frame. \\
+\bitvar{MBMODES} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 3 & No & An \bitvar{NMBS}-element array of coding
+ modes for each macro block. \\
+\bitvar{NBS} & Integer & 36 & No & The total number of blocks in a
+ frame. \\
+\bitvar{BCODED} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 1 & No & An \bitvar{NBS}-element array of flags
+ indicating which blocks are coded. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{MVECTS} & \multicolumn{1}{p{50pt}}{Array of 2D Integer Vectors} &
+ 6 & Yes & An \bitvar{NBS}-element array of
+ motion vectors for each block. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{LAST1} & \multicolumn{1}{p{50pt}}{2D Integer Vector} &
+ 6 & Yes & The last motion vector. \\
+\locvar{LAST2} & \multicolumn{1}{p{50pt}}{2D Integer Vector} &
+ 6 & Yes & The second to last motion vector. \\
+\locvar{MVX} & Integer & 6 & Yes & The X component of a motion vector. \\
+\locvar{MVY} & Integer & 6 & Yes & The Y component of a motion vector. \\
+\locvar{\mbi} & Integer & 32 & No & The index of the current macro
+ block. \\
+\locvar{A} & Integer & 36 & No & The index of the lower-left luma block
+ in the macro block. \\
+\locvar{B} & Integer & 36 & No & The index of the lower-right luma
+ block in the macro block. \\
+\locvar{C} & Integer & 36 & No & The index of the upper-left luma block
+ in the macro block. \\
+\locvar{D} & Integer & 36 & No & The index of the upper-right luma
+ block in the macro block. \\
+\locvar{E} & Integer & 36 & No & The index of a chroma block in the
+ macro block, depending on the pixel format. \\
+\locvar{F} & Integer & 36 & No & The index of a chroma block in the
+ macro block, depending on the pixel format. \\
+\locvar{G} & Integer & 36 & No & The index of a chroma block in the
+ macro block, depending on the pixel format. \\
+\locvar{H} & Integer & 36 & No & The index of a chroma block in the
+ macro block, depending on the pixel format. \\
+\locvar{I} & Integer & 36 & No & The index of a chroma block in the
+ macro block, depending on the pixel format. \\
+\locvar{J} & Integer & 36 & No & The index of a chroma block in the
+ macro block, depending on the pixel format. \\
+\locvar{K} & Integer & 36 & No & The index of a chroma block in the
+ macro block, depending on the pixel format. \\
+\locvar{L} & Integer & 36 & No & The index of a chroma block in the
+ macro block, depending on the pixel format. \\
+\bottomrule\end{tabularx}
+\medskip
+
+Motion vectors are stored for each macro block.
+In every mode except for INTER\_MV\_FOUR, every block in all the color planes
+ are assigned the same motion vector.
+In INTER\_MV\_FOUR mode, all four blocks in the luma plane are assigned their
+ own motion vector, and motion vectors for blocks in the chroma planes are
+ computed from these, using averaging appropriate to the pixel format.
+
+For INTER\_MV and INTER\_GOLDEN\_MV modes, a single motion vector is decoded
+ and applied to each block.
+For INTER\_MV\_FOUR macro blocks, a motion vector is decoded for each coded
+ luma block, in raster order, not coded order.
+Uncoded luma blocks receive the default $(0,0)$ vector for the purposes of
+ computing the chroma motion vectors.
+
+None of the remaining macro block coding modes require decoding motion vectors
+ from the stream.
+INTRA mode does not use a motion-compensated predictor, and thus does not
+ require a motion vector.
+Both the INTER\_NOMV and the INTER\_GOLDEN\_NOMV modes use the default
+ vector $(0,0)$ for each block.
+This also includes all macro blocks with no coded luma blocks, as they are
+ coded in INTER\_NOMV mode by definition.
+
+The modes INTER\_MV\_LAST and INTER\_MV\_LAST2 use the motion vector from the
+ last macro block (in coded order) and the second to last macro block,
+ respectively, that contained a motion vector pointing to the previous frame.
+Thus no explicit motion vector needs to be decoded for these modes.
+Macro blocks coded in INTRA mode or one of the GOLDEN modes are not considered
+ in this process.
+For macro blocks coded in INTER\_MV\_FOUR mode, this process uses the vector
+ from the last coded luma block in the macro block, again in raster order, not
+ coded order.
+This is usually the upper-right block.
+If an insufficient number of macro blocks have been coded in one of the INTER
+ modes, then the $(0,0)$ vector is used instead.
+
+The motion vectors are decoded from the stream as follows:
+
+\begin{enumerate}
+\item
+Assign \locvar{LAST1} and \locvar{LAST2} both the value $(0,0)$.
+\item
+Read a 1-bit unsigned integer as \locvar{MVMODE}.
+Note that this value is read even if no macro blocks require a motion vector to
+ be decoded.
+\item
+For each consecutive value of \locvar{\mbi} from 0 to $(\bitvar{NMBS}-1)$:
+\begin{enumerate}
+\item
+If $\bitvar{MBMODES}[\locvar{\mbi}]$ is 7 (INTER\_MV\_FOUR):
+\begin{enumerate}
+\item
+Let \locvar{A}, \locvar{B}, \locvar{C}, and \locvar{D} be the indices in coded
+ order \locvar{\bi} of the luma blocks in macro block \locvar{\mbi}, arranged
+ into raster order.
+Thus, \locvar{A} is the index in coded order of the block in the lower left,
+ \locvar{B} the lower right, \locvar{C} the upper left, and \locvar{D} the
+ upper right. % TODO: as shown in Figure~REF.
+\item If $\bitvar{BCODED}[\locvar{A}]$ is non-zero:
+\begin{enumerate}
+\item Decode a single motion vector into \locvar{MVX} and \locvar{MVY} using
+ the procedure described in Section~\ref{sub:mv-decode}.
+\item Assign $\bitvar{MVECTS}[\locvar{A}]$ the value
+ $(\locvar{MVX},\locvar{MVY})$.
+\end{enumerate}
+\item Otherwise, assign $\bitvar{MVECTS}[\locvar{A}]$ the value $(0,0)$.
+\item If $\bitvar{BCODED}[\locvar{B}]$ is non-zero:
+\begin{enumerate}
+\item Decode a single motion vector into \locvar{MVX} and \locvar{MVY} using
+ the procedure described in Section~\ref{sub:mv-decode}.
+\item Assign $\bitvar{MVECTS}[\locvar{B}]$ the value
+ $(\locvar{MVX},\locvar{MVY})$.
+\end{enumerate}
+\item
+Otherwise assign $\bitvar{MVECTS}[\locvar{B}]$ the value $(0,0)$.
+\item If $\bitvar{BCODED}[\locvar{C}]$ is non-zero:
+\begin{enumerate}
+\item Decode a single motion vector into \locvar{MVX} and \locvar{MVY} using
+ the procedure described in Section~\ref{sub:mv-decode}.
+\item Assign $\bitvar{MVECTS}[\locvar{C}]$ the value
+ $(\locvar{MVX},\locvar{MVY})$.
+\end{enumerate}
+\item Otherwise assign $\bitvar{MVECTS}[\locvar{C}]$ the value $(0,0)$.
+\item If $\bitvar{BCODED}[\locvar{D}]$ is non-zero:
+\begin{enumerate}
+\item Decode a single motion vector into \locvar{MVX} and \locvar{MVY} using
+ the procedure described in Section~\ref{sub:mv-decode}.
+\item Assign $\bitvar{MVECTS}[\locvar{D}]$ the value
+ $(\locvar{MVX},\locvar{MVY})$.
+\end{enumerate}
+\item
+Otherwise, assign $\bitvar{MVECTS}[\locvar{D}]$ the value $(0,0)$.
+\item
+If \bitvar{PF} is 0 (4:2:0):
+\begin{enumerate}
+\item
+Let \locvar{E} and \locvar{F} be the index in coded order of the one block in
+ the macro block from the $C_b$ and $C_r$ planes, respectively.
+\item
+Assign $\bitvar{MVECTS}[\locvar{E}]$ and $\bitvar{MVECTS}[\locvar{F}]$ the
+ value
+\begin{multline*}
+(\round\biggl(\frac{\begin{aligned}
+ \bitvar{MVECTS}[\locvar{A}]_x+\bitvar{MVECTS}[\locvar{B}]_x+\\
+ \bitvar{MVECTS}[\locvar{C}]_x+\bitvar{MVECTS}[\locvar{D}]_x
+ \end{aligned}}{4}\biggr), \\
+ \round\biggl(\frac{\begin{aligned}
+ \bitvar{MVECTS}[\locvar{A}]_y+\bitvar{MVECTS}[\locvar{B}]_y+\\
+ \bitvar{MVECTS}[\locvar{C}]_y+\bitvar{MVECTS}[\locvar{D}]_y
+ \end{aligned}}{4}\biggr))
+\end{multline*}
+\end{enumerate}
+\item
+If \bitvar{PF} is 2 (4:2:2):
+\begin{enumerate}
+\item
+Let \locvar{E} and \locvar{F} be the indices in coded order of the bottom and
+ top blocks in the macro block from the $C_b$ plane, respectively, and
+ \locvar{G} and \locvar{H} be the indices in coded order of the bottom and top
+ blocks in the $C_r$ plane, respectively. %TODO: as shown in Figure~REF.
+\item
+Assign $\bitvar{MVECTS}[\locvar{E}]$ and $\bitvar{MVECTS}[\locvar{G}]$ the
+ value
+\begin{multline*}
+(\round\left(\frac{
+ \bitvar{MVECTS}[\locvar{A}]_x+\bitvar{MVECTS}[\locvar{B}]_x}{2}\right), \\
+ \round\left(\frac{
+ \bitvar{MVECTS}[\locvar{A}]_y+\bitvar{MVECTS}[\locvar{B}]_y}{2}\right))
+\end{multline*}
+\item
+Assign $\bitvar{MVECTS}[\locvar{F}]$ and $\bitvar{MVECTS}[\locvar{H}]$ the
+ value
+\begin{multline*}
+(\round\left(\frac{
+ \bitvar{MVECTS}[\locvar{C}]_x+\bitvar{MVECTS}[\locvar{D}]_x}{2}\right), \\
+ \round\left(\frac{
+ \bitvar{MVECTS}[\locvar{C}]_y+\bitvar{MVECTS}[\locvar{D}]_y}{2}\right))
+\end{multline*}
+\end{enumerate}
+\item
+If \bitvar{PF} is 3 (4:4:4):
+\begin{enumerate}
+\item
+Let \locvar{E}, \locvar{F}, \locvar{G}, and \locvar{H} be the indices
+ \locvar{\bi} in coded order of the $C_b$ plane blocks in macro block
+ \locvar{\mbi}, arranged into raster order, and \locvar{I}, \locvar{J},
+ \locvar{K}, and \locvar{L} be the indices \locvar{\bi} in coded order of the
+ $C_r$ plane blocks in macro block \locvar{\mbi}, arranged into raster order.
+ %TODO: as shown in Figure~REF.
+\item
+Assign $\bitvar{MVECTS}[\locvar{E}]$ and $\bitvar{MVECTS}[\locvar{I}]$ the
+ value \\ $\bitvar{MVECTS}[\locvar{A}]$.
+\item
+Assign $\bitvar{MVECTS}[\locvar{F}]$ and $\bitvar{MVECTS}[\locvar{J}]$ the
+ value \\ $\bitvar{MVECTS}[\locvar{B}]$.
+\item
+Assign $\bitvar{MVECTS}[\locvar{G}]$ and $\bitvar{MVECTS}[\locvar{K}]$ the
+ value \\ $\bitvar{MVECTS}[\locvar{C}]$.
+\item
+Assign $\bitvar{MVECTS}[\locvar{H}]$ and $\bitvar{MVECTS}[\locvar{L}]$ the
+ value \\ $\bitvar{MVECTS}[\locvar{D}]$.
+\end{enumerate}
+\item
+Assign \locvar{LAST2} the value \locvar{LAST1}.
+\item
+Assign \locvar{LAST1} the value $(\locvar{MVX},\locvar{MVY})$.
+This is the value of the motion vector decoded from the last coded luma block
+ in raster order.
+There must always be at least one, since macro blocks with no coded luma blocks
+ must use mode 0:~INTER\_NOMV.
+\end{enumerate}
+\item
+Otherwise, if $\bitvar{MBMODES}[\locvar{\mbi}]$ is 6 (INTER\_GOLDEN\_MV),
+ decode a single motion vector into \locvar{MVX} and \locvar{MVY} using the
+ procedure described in Section~\ref{sub:mv-decode}.
+\item
+Otherwise, if $\bitvar{MBMODES}[\locvar{\mbi}]$ is 4 (INTER\_MV\_LAST2):
+\begin{enumerate}
+\item
+Assign $(\locvar{MVX},\locvar{MVY})$ the value \locvar{LAST2}.
+\item
+Assign \locvar{LAST2} the value \locvar{LAST1}.
+\item
+Assign \locvar{LAST1} the value $(\locvar{MVX},\locvar{MVY})$.
+\end{enumerate}
+\item
+Otherwise, if $\bitvar{MBMODES}[\locvar{\mbi}]$ is 3 (INTER\_MV\_LAST), assign
+ $(\locvar{MVX},\locvar{MVY})$ the value \locvar{LAST1}.
+\item
+Otherwise, if $\bitvar{MBMODES}[\locvar{\mbi}]$ is 2 (INTER\_MV):
+\begin{enumerate}
+\item
+Decode a single motion vector into \locvar{MVX} and \locvar{MVY} using the
+ procedure described in Section~\ref{sub:mv-decode}.
+\item
+Assign \locvar{LAST2} the value \locvar{LAST1}.
+\item
+Assign \locvar{LAST1} the value $(\locvar{MVX},\locvar{MVY})$.
+\end{enumerate}
+\item
+Otherwise ($\bitvar{MBMODES}[\locvar{\mbi}]$ is 5:~INTER\_GOLDEN\_NOMV,
+ 1:~INTRA, or 0:~INTER\_NOMV), assign \locvar{MVX} and \locvar{MVY} the value
+ zero.
+\item
+If $\bitvar{MBMODES}[\locvar{\mbi}]$ is not 7 (not INTER\_MV\_FOUR), then for
+ each coded block \locvar{\bi} in macro block \locvar{\mbi}:
+\begin{enumerate}
+\item
+Assign $\bitvar{MVECTS}[\locvar{\bi}]$ the value $(\locvar{MVX},\locvar{MVY})$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+Unless all four luma blocks in the macro block are coded, the VP3 encoder does
+ not select mode INTER\_MV\_FOUR.
+Theora removes this restriction by treating the motion vector for an uncoded
+ luma block as the default $(0,0)$ vector.
+This is consistent with the premise that the block has not changed since the
+ previous frame and that chroma information can be largely ignored when
+ estimating motion.
+
+No modification is required for INTER\_MV\_FOUR macro blocks in VP3 streams to
+ be decoded correctly by a Theora decoder.
+However, regardless of how many of the luma blocks are actually coded, the VP3
+ decoder always reads four motion vectors from the stream for INTER\_MV\_FOUR
+ mode.
+The motion vectors read are used to calculate the motion vectors for the chroma
+ blocks, but are otherwise ignored.
+Thus, care should be taken when creating Theora streams meant to be backwards
+ compatible with VP3 to only use INTER\_MV\_FOUR mode when all four luma
+ blocks are coded.
+
+\section{Block-Level \qi\ Decode}
+\label{sub:block-qis}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{NBS} & Integer & 36 & No & The total number of blocks in a
+ frame. \\
+\bitvar{BCODED} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 1 & No & An \bitvar{NBS}-element array of flags
+ indicating which blocks are coded. \\
+\bitvar{NQIS} & Integer & 2 & No & The number of \qi\ values. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{QIIS} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 2 & No & An \bitvar{NBS}-element array of
+ \locvar{\qii} values for each block. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{NBITS} & Integer & 36 & No & The length of a bit string to decode. \\
+\locvar{BITS} & Bit string & & & A decoded set of flags. \\
+\locvar{\bi} & Integer & 36 & No & The index of the current block in
+ coded order. \\
+\locvar{\qii} & Integer & 2 & No & The index of \qi\ value in the list of
+ \qi\ values defined for this frame. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure selects the \qi\ value to be used for dequantizing the AC
+ coefficients of each block.
+DC coefficients all use the same \qi\ value, so as to avoid interference with
+ the DC prediction mechanism, which occurs in the quantized domain.
+
+The value is actually represented by an index \locvar{\qii} into the list of
+ \qi\ values defined for the frame.
+The decoder makes multiple passes through the list of coded blocks, one for
+ each \qi\ value except the last one.
+In each pass, an RLE-coded bitmask is decoded to divide the blocks into two
+ groups: those that use the current \qi\ value in the list, and those that use
+ a value from later in the list.
+Each subsequent pass is restricted to the blocks in the second group.
+
+\begin{enumerate}
+\item
+For each value of \locvar{\bi} from 0 to $(\bitvar{NBS}-1)$, assign
+ $\bitvar{QIIS}[\locvar{\bi}]$ the value zero.
+\item
+For each consecutive value of \locvar{\qii} from 0 to $(\bitvar{NQIS}-2)$:
+\begin{enumerate}
+\item
+Assign \locvar{NBITS} be the number of blocks \locvar{\bi} such that
+ $\bitvar{BCODED}[\locvar{\bi}]$ is non-zero and $\bitvar{QIIS}[\locvar{\bi}]$
+ equals $\locvar{\qii}$.
+\item
+Read an \locvar{NBITS}-bit bit string into \locvar{BITS}, using the procedure
+ described in Section~\ref{sub:long-run}.
+This represents the list of blocks that use \qi\ value \locvar{\qii} or higher.
+\item
+For each consecutive value of \locvar{\bi} from 0 to $(\bitvar{NBS}-1)$ such
+ that $\bitvar{BCODED}[\locvar{\bi}]$ is non-zero and
+ $\bitvar{QIIS}[\locvar{\bi}]$ equals $\locvar{\qii}$:
+\begin{enumerate}
+\item
+Remove the bit at the head of the string \locvar{BITS} and add its value to
+ $\bitvar{QIIS}[\locvar{\bi}]$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+For VP3 compatible streams, only one \qi\ value can be specified in the frame
+ header, so the main loop of the above procedure, which would iterate from $0$
+ to $-1$, is never executed.
+Thus, no bits are read, and each block uses the one \qi\ value defined for the
+ frame.
+
+\cleardoublepage
+
+\section{DCT Coefficients}
+\label{sec:dct-decode}
+
+The quantized DCT coefficients are decoded by making 64 passes through the list
+ of coded blocks, one for each token index in zig-zag order.
+For the DC tokens, two Huffman tables are chosen from among the first 16, one
+ for the luma plane and one for the chroma planes.
+The AC tokens, however, are divided into four different groups.
+Again, two 4-bit indices are decoded, one for the luma plane, and one for the
+ chroma planes, but these select the codebooks for {\em all four} groups.
+AC coefficients in group one use codebooks $16\ldots 31$, while group two uses
+ $32\ldots 47$, etc.
+Note that this second set of indices is decoded even if there are no non-zero
+ AC coefficients in the frame.
+
+Tokens are divided into two major types: EOB tokens, which fill the remainder
+ of one or more blocks with zeros, and coefficient tokens, which fill in one or
+ more coefficients within a single block.
+A decoding procedure for the first is given in Section~\ref{sub:eob-token}, and
+ for the second in Section~\ref{sub:coeff-token}.
+The decoding procedure for the complete set of quantized coefficients is given
+ in Section~\ref{sub:dct-coeffs}.
+
+\subsection{EOB Token Decode}
+\label{sub:eob-token}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{TOKEN} & Integer & 5 & No & The token being decoded.
+This must be in the range $0\ldots 6$. \\
+\bitvar{NBS} & Integer & 36 & No & The total number of blocks in a
+ frame. \\
+\bitvar{TIS} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 7 & No & An \bitvar{NBS}-element array of the
+ current token index for each block. \\
+\bitvar{NCOEFFS} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 7 & No & An \bitvar{NBS}-element array of the
+ coefficient count for each block. \\
+\bitvar{COEFFS} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bitvar{\bi} & Integer & 36 & No & The index of the current block in
+ coded order. \\
+\bitvar{\ti} & Integer & 6 & No & The current token index. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{TIS} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 7 & No & An \bitvar{NBS}-element array of the
+ current token index for each block. \\
+\bitvar{COEFFS} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bitvar{EOBS} & Integer & 36 & No & The remaining length of the current
+ EOB run. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\bj} & Integer & 36 & No & Another index of a block in coded
+ order. \\
+\locvar{\tj} & Integer & 6 & No & Another token index. \\
+\bottomrule\end{tabularx}
+\medskip
+
+A summary of the EOB tokens is given in Table~\ref{tab:eob-tokens}.
+An important thing to note is that token 6 does not add an offset to the
+ decoded run value, even though in general it should only be used for runs of
+ size 32 or longer.
+If a value of zero is decoded for this run, it is treated as an EOB run the
+ size of the remaining coded blocks.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{ccl}\toprule
+Token Value & Extra Bits & EOB Run Lengths \\\midrule
+$0$ & $0$ & $1$ \\
+$1$ & $0$ & $2$ \\
+$2$ & $0$ & $3$ \\
+$3$ & $2$ & $4\ldots 7$ \\
+$4$ & $3$ & $8\ldots 15$ \\
+$5$ & $4$ & $16\ldots 31$ \\
+$6$ & $12$ & $1\ldots 4095$, or all remaining blocks \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{EOB Token Summary}
+\label{tab:eob-tokens}
+\end{table}
+
+There is no restriction that one EOB token cannot be immediately followed by
+ another, so no special cases are necessary to extend the range of the maximum
+ run length as were required in Section~\ref{sub:long-run}.
+Indeed, depending on the lengths of the Huffman codes, it may even cheaper to
+ encode, by way of example, an EOB run of length 31 followed by an EOB run of
+ length 1 than to encode an EOB run of length 32 directly.
+There is also no restriction that an EOB run stop at the end of a color plane
+ or a token index.
+The run MUST, however, end at or before the end of the frame.
+
+\begin{enumerate}
+\item
+If \bitvar{TOKEN} is 0, assign \bitvar{EOBS} the value 1.
+\item
+Otherwise, if \bitvar{TOKEN} is 1, assign \bitvar{EOBS} the value 2.
+\item
+Otherwise, if \bitvar{TOKEN} is 2, assign \bitvar{EOBS} the value 3.
+\item
+Otherwise, if \bitvar{TOKEN} is 3:
+\begin{enumerate}
+\item
+Read a 2-bit unsigned integer as \bitvar{EOBS}.
+\item
+Assign \bitvar{EOBS} the value $(\bitvar{EOBS}+4)$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 4:
+\begin{enumerate}
+\item
+Read a 3-bit unsigned integer as \bitvar{EOBS}.
+\item
+Assign \bitvar{EOBS} the value $(\bitvar{EOBS}+8)$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 5:
+\begin{enumerate}
+\item
+Read a 4-bit unsigned integer as \bitvar{EOBS}.
+\item
+Assign \bitvar{EOBS} the value $(\bitvar{EOBS}+16)$.
+\end{enumerate}
+\item
+Otherwise, \bitvar{TOKEN} is 6:
+\begin{enumerate}
+\item
+Read a 12-bit unsigned integer as \bitvar{EOBS}.
+\item
+If \bitvar{EOBS} is zero, assign \bitvar{EOBS} to be the number of coded blocks
+ \locvar{\bj} such that $\bitvar{TIS}[\locvar{\bj}]$ is less than 64.
+\end{enumerate}
+\item
+For each value of \locvar{\tj} from $\bitvar{\ti}$ to 63, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value 64.
+\item
+Assign \bitvar{EOBS} the value $(\bitvar{EOBS}-1)$.
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+The VP3 encoder does not use the special interpretation of a zero-length EOB
+ run, though its decoder {\em does} support it.
+That may be due more to a happy accident in the way the decoder was written
+ than intentional design, however, and other VP3 implementations might not
+ reproduce it faithfully.
+For backwards compatibility, it may be wise to avoid it, especially as for most
+ frame sizes there are fewer than 4095 blocks, making it unnecessary.
+
+\subsection{Coefficient Token Decode}
+\label{sub:coeff-token}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{TOKEN} & Integer & 5 & No & The token being decoded.
+This must be in the range $7\ldots 31$. \\
+\bitvar{NBS} & Integer & 36 & No & The total number of blocks in a
+ frame. \\
+\bitvar{TIS} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 7 & No & An \bitvar{NBS}-element array of the
+ current token index for each block. \\
+\bitvar{COEFFS} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bitvar{\bi} & Integer & 36 & No & The index of the current block in
+ coded order. \\
+\bitvar{\ti} & Integer & 6 & No & The current token index. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{TIS} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 7 & No & An \bitvar{NBS}-element array of the
+ current token index for each block. \\
+\bitvar{NCOEFFS} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 7 & No & An \bitvar{NBS}-element array of the
+ coefficient count for each block. \\
+\bitvar{COEFFS} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{SIGN} & Integer & 1 & No & A flag indicating the sign of the
+ current coefficient. \\
+\locvar{MAG} & Integer & 10 & No & The magnitude of the current
+ coefficient. \\
+\locvar{RLEN} & Integer & 6 & No & The length of the current zero run. \\
+\locvar{\tj} & Integer & 6 & No & Another token index. \\
+\bottomrule\end{tabularx}
+\medskip
+
+Each of these tokens decodes one or more coefficients in the current block.
+A summary of the meanings of the token values is presented in
+ Table~\ref{tab:coeff-tokens}.
+There are often several different ways to tokenize a given coefficient list.
+Which one is optimal depends on the exact lengths of the Huffman codes used to
+ represent each token.
+Note that we do not update the coefficient count for the block if we decode a
+ pure zero run.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabularx}{\textwidth}{cclX}\toprule
+Token Value & Extra Bits & \multicolumn{1}{p{55pt}}{Number of Coefficients}
+ & Description \\\midrule
+$7$ & $3$ & $1\ldots 8$ & Short zero run. \\
+$8$ & $6$ & $1\ldots 64$ & Zero run. \\
+$9$ & $0$ & $1$ & $1$. \\
+$10$ & $0$ & $1$ & $-1$. \\
+$11$ & $0$ & $1$ & $2$. \\
+$12$ & $0$ & $1$ & $-2$. \\
+$13$ & $1$ & $1$ & $\pm 3$. \\
+$14$ & $1$ & $1$ & $\pm 4$. \\
+$15$ & $1$ & $1$ & $\pm 5$. \\
+$16$ & $1$ & $1$ & $\pm 6$. \\
+$17$ & $2$ & $1$ & $\pm 7\ldots 8$. \\
+$18$ & $3$ & $1$ & $\pm 9\ldots 12$. \\
+$19$ & $4$ & $1$ & $\pm 13\ldots 20$. \\
+$20$ & $5$ & $1$ & $\pm 21\ldots 36$. \\
+$21$ & $6$ & $1$ & $\pm 37\ldots 68$. \\
+$22$ & $10$ & $1$ & $\pm 69\ldots 580$. \\
+$23$ & $1$ & $2$ & One zero followed by $\pm 1$. \\
+$24$ & $1$ & $3$ & Two zeros followed by $\pm 1$. \\
+$25$ & $1$ & $4$ & Three zeros followed by
+ $\pm 1$. \\
+$26$ & $1$ & $5$ & Four zeros followed by
+ $\pm 1$. \\
+$27$ & $1$ & $6$ & Five zeros followed by
+ $\pm 1$. \\
+$28$ & $3$ & $7\ldots 10$ & $6\ldots 9$ zeros followed by
+ $\pm 1$. \\
+$29$ & $4$ & $11\ldots 18$ & $10\ldots 17$ zeros followed by
+ $\pm 1$.\\
+$30$ & $2$ & $2$ & One zero followed by
+ $\pm 2\ldots 3$. \\
+$31$ & $3$ & $3\ldots 4$ & $2\ldots 3$ zeros followed by
+ $\pm 2\ldots 3$. \\
+\bottomrule\end{tabularx}
+\end{center}
+\caption{Coefficient Token Summary}
+\label{tab:coeff-tokens}
+\end{table}
+
+For tokens which represent more than one coefficient, they MUST NOT bring the
+ total number of coefficients in the block to more than 64.
+Care should be taken in a decoder to check for this, as otherwise it may permit
+ buffer overflows from invalidly formed packets.
+\begin{verse}
+{\bf Note:} One way to achieve this efficiently is to combine the inverse
+ zig-zag mapping (described later in Section~\ref{sub:dequant}) with
+ coefficient decode, and use a table look-up to map zig-zag indices greater
+ than 63 to a safe location.
+\end{verse}
+
+\begin{enumerate}
+\item
+If \bitvar{TOKEN} is 7:
+\begin{enumerate}
+\item
+Read in a 3-bit unsigned integer as \locvar{RLEN}.
+\item
+Assign \locvar{RLEN} the value $(\locvar{RLEN}+1)$.
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to
+ $(\bitvar{\ti}+\locvar{RLEN}-1)$, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value
+ $\bitvar{TIS}[\bitvar{\bi}]+\locvar{RLEN}$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 8:
+\begin{enumerate}
+\item
+Read in a 6-bit unsigned integer as \locvar{RLEN}.
+\item
+Assign \locvar{RLEN} the value $(\locvar{RLEN}+1)$.
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to
+ $(\bitvar{\ti}+\locvar{RLEN}-1)$, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value
+ $\bitvar{TIS}[\bitvar{\bi}]+\locvar{RLEN}$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 9:
+\begin{enumerate}
+\item
+Assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value $1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 10:
+\begin{enumerate}
+\item
+Assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value $-1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 11:
+\begin{enumerate}
+\item
+Assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value $2$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 12:
+\begin{enumerate}
+\item
+Assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value $-2$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 13:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $3$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value $-3$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 14:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $4$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value $-4$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 15:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $5$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value $-5$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 16:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $6$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value $-6$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 17:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 1-bit unsigned integer as \locvar{MAG}.
+\item
+Assign \locvar{MAG} the value $(\locvar{MAG}+7)$.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $\locvar{MAG}$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value
+ $-\locvar{MAG}$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 18:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 2-bit unsigned integer as \locvar{MAG}.
+\item
+Assign \locvar{MAG} the value $(\locvar{MAG}+9)$.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $\locvar{MAG}$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value
+ $-\locvar{MAG}$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 19:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 3-bit unsigned integer as \locvar{MAG}.
+\item
+Assign \locvar{MAG} the value $(\locvar{MAG}+13)$.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $\locvar{MAG}$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value
+ $-\locvar{MAG}$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 20:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 4-bit unsigned integer as \locvar{MAG}.
+\item
+Assign \locvar{MAG} the value $(\locvar{MAG}+21)$.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $\locvar{MAG}$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value
+ $-\locvar{MAG}$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 21:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 5-bit unsigned integer as \locvar{MAG}.
+\item
+Assign \locvar{MAG} the value $(\locvar{MAG}+37)$.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $\locvar{MAG}$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value
+ $-\locvar{MAG}$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 22:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 9-bit unsigned integer as \locvar{MAG}.
+\item
+Assign \locvar{MAG} the value $(\locvar{MAG}+69)$.
+\item
+If \locvar{SIGN} is zero, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$
+ the value $\locvar{MAG}$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value
+ $-\locvar{MAG}$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 23:
+\begin{enumerate}
+\item
+Assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}]$ the value zero.
+\item
+Read a 1-bit unsigned integer as SIGN.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+1]$ the value $1$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+1]$ the value
+ $-1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+2$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 24:
+\begin{enumerate}
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to $(\bitvar{\ti}+1)$, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+Read a 1-bit unsigned integer as SIGN.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+2]$ the value $1$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+2]$ the value
+ $-1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+3$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 25:
+\begin{enumerate}
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to $(\bitvar{\ti}+2)$, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+Read a 1-bit unsigned integer as SIGN.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+3]$ the value $1$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+3]$ the value
+ $-1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+4$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 26:
+\begin{enumerate}
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to $(\bitvar{\ti}+3)$, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+Read a 1-bit unsigned integer as SIGN.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+4]$ the value $1$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+4]$ the value
+ $-1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+5$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 27:
+\begin{enumerate}
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to $(\bitvar{\ti}+4)$, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+Read a 1-bit unsigned integer as SIGN.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+5]$ the value $1$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+5]$ the value
+ $-1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+6$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 28:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 2-bit unsigned integer as \locvar{RLEN}.
+\item
+Assign \locvar{RLEN} the value $(\locvar{RLEN}+6)$.
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to
+ $(\bitvar{\ti}+\locvar{RLEN}-1)$, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+\locvar{RLEN}]$ the value $1$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+\locvar{RLEN}]$
+ the value $-1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value
+ $\bitvar{TIS}[\bitvar{\bi}]+\locvar{RLEN}+1$.
+\item
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 29:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 3-bit unsigned integer as \locvar{RLEN}.
+\item
+Assign \locvar{RLEN} the value $(\locvar{RLEN}+10)$.
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to
+ $(\bitvar{\ti}+\locvar{RLEN}-1)$, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+\locvar{RLEN}]$ the value $1$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+\locvar{RLEN}]$
+ the value $-1$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value
+ $\bitvar{TIS}[\bitvar{\bi}]+\locvar{RLEN}+1$.
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 30:
+\begin{enumerate}
+\item
+Assign $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\ti}]$ the value zero.
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 1-bit unsigned integer as \locvar{MAG}.
+\item
+Assign \locvar{MAG} the value $(\locvar{MAG}+2)$.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+1]$ the value $\locvar{MAG}$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+1]$ the value
+ $-\locvar{MAG}$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]+2$.
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\item
+Otherwise, if \bitvar{TOKEN} is 31:
+\begin{enumerate}
+\item
+Read a 1-bit unsigned integer as \locvar{SIGN}.
+\item
+Read a 1-bit unsigned integer as \locvar{MAG}.
+\item
+Assign \locvar{MAG} the value $(\locvar{MAG}+2)$.
+\item
+Read a 1-bit unsigned integer as \locvar{RLEN}.
+\item
+Assign \locvar{RLEN} the value $(\locvar{RLEN}+2)$.
+\item
+For each value of \locvar{\tj} from \bitvar{\ti} to
+ $(\bitvar{\ti}+\locvar{RLEN}-1)$, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+If \locvar{SIGN} is zero, assign
+ $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+\locvar{RLEN}]$ the value
+ $\locvar{MAG}$.
+\item
+Otherwise, assign $\bitvar{COEFFS}[\bitvar{\bi}][\bitvar{\ti}+\locvar{RLEN}]$
+ the value $-\locvar{MAG}$.
+\item
+Assign $\bitvar{TIS}[\bitvar{\bi}]$ the value
+ $\bitvar{TIS}[\bitvar{\bi}]+\locvar{RLEN}+1$.
+Assign $\bitvar{NCOEFFS}[\bitvar{\bi}]$ the value $\bitvar{TIS}[\bitvar{\bi}]$.
+\end{enumerate}
+\end{enumerate}
+
+\subsection{DCT Coefficient Decode}
+\label{sub:dct-coeffs}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{NBS} & Integer & 36 & No & The total number of blocks in a
+ frame. \\
+\bitvar{BCODED} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 1 & No & An \bitvar{NBS}-element array of flags
+ indicating which blocks are coded. \\
+\bitvar{NMBS} & Integer & 32 & No & The total number of macro blocks in a
+ frame. \\
+\bitvar{HTS} & \multicolumn{3}{l}{Huffman table array}
+ & An 80-element array of Huffman tables
+ with up to 32 entries each. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{COEFFS} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bitvar{NCOEFFS} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 7 & No & An \bitvar{NBS}-element array of the
+ coefficient count for each block. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{NLBS} & Integer & 34 & No & The number of blocks in the luma
+ plane. \\
+\locvar{TIS} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 7 & No & An \bitvar{NBS}-element array of the
+ current token index for each block. \\
+\locvar{EOBS} & Integer & 36 & No & The remaining length of the current
+ EOB run. \\
+\locvar{TOKEN} & Integer & 5 & No & The current token being decoded. \\
+\locvar{HG} & Integer & 3 & No & The current Huffman table group. \\
+\locvar{\cbi} & Integer & 36 & No & The index of the current block in the
+ coded block list. \\
+\locvar{\bi} & Integer & 36 & No & The index of the current block in
+ coded order. \\
+\locvar{\bj} & Integer & 36 & No & Another index of a block in coded
+ order. \\
+\locvar{\ti} & Integer & 6 & No & The current token index. \\
+\locvar{\tj} & Integer & 6 & No & Another token index. \\
+\locvar{\hti_L} & Integer & 4 & No & The index of the current Huffman table
+ to use for the luma plane within a group. \\
+\locvar{\hti_C} & Integer & 4 & No & The index of the current Huffman table
+ to use for the chroma planes within a group. \\
+\locvar{\hti} & Integer & 7 & No & The index of the current Huffman table
+ to use. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure puts the above two procedures to work to decode the entire set
+ of DCT coefficients for the frame.
+At the end of this procedure, \locvar{EOBS} MUST be zero, and
+ $\locvar{TIS}[\locvar{\bi}]$ MUST be 64 for every coded \locvar{\bi}.
+
+Note that we update the coefficient count of every block before continuing an
+ EOB run or decoding a token, despite the fact that it is already up to date
+ unless the previous token was a pure zero run.
+This is done intentionally to mimic the VP3 accounting rules.
+Thus the only time the coefficient count does not include the coefficients in a
+ pure zero run is when when that run reaches all the way to coefficient 63.
+Note, however, that regardless of the coefficient count, any additional
+ coefficients are still set to zero.
+The only use of the count is in determining if a special case of the inverse
+ DCT can be used in Section~\ref{sub:2d-idct}.
+
+\begin{enumerate}
+\item
+Assign \locvar{NLBS} the value $(\bitvar{NMBS}*4)$.
+\item
+For each consecutive value of \locvar{\bi} from 0 to $(\bitvar{NBS}-1)$,
+ assign $\locvar{TIS}[\locvar{\bi}]$ the value zero.
+\item
+Assign \locvar{EOBS} the value 0.
+\item
+For each consecutive value of \locvar{\ti} from 0 to 63:
+\begin{enumerate}
+\item
+If \locvar{\ti} is $0$ or $1$:
+\begin{enumerate}
+\item
+Read a 4-bit unsigned integer as \locvar{\hti_L}.
+\item
+Read a 4-bit unsigned integer as \locvar{\hti_C}.
+\end{enumerate}
+\item
+For each consecutive value of \locvar{\bi} from 0 to $(\bitvar{NBS}-1)$ for
+ which $\bitvar{BCODED}[\locvar{\bi}]$ is non-zero and
+ $\locvar{TIS}[\locvar{\bi}]$ equals \locvar{\ti}:
+\begin{enumerate}
+\item
+Assign $\bitvar{NCOEFFS}[\locvar{\bi}]$ the value \locvar{\ti}.
+\item
+If \locvar{EOBS} is greater than zero:
+\begin{enumerate}
+\item
+For each value of \locvar{\tj} from $\locvar{\ti}$ to 63, assign
+ $\bitvar{COEFFS}[\locvar{\bi}][\locvar{\tj}]$ the value zero.
+\item
+Assign $\locvar{TIS}[\locvar{\bi}]$ the value 64.
+\item
+Assign \locvar{EOBS} the value $(\locvar{EOBS}-1)$.
+\end{enumerate}
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Assign \locvar{HG} a value based on \locvar{\ti} from
+ Table~\ref{tab:huff-groups}.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{lc}\toprule
+\locvar{\ti} & \locvar{HG} \\\midrule
+$0$ & $0$ \\
+$1\ldots 5$ & $1$ \\
+$6\ldots 14$ & $2$ \\
+$15\ldots 27$ & $3$ \\
+$28\ldots 63$ & $4$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Huffman Table Groups}
+\label{tab:huff-groups}
+\end{table}
+
+\item
+If \locvar{\bi} is less than \locvar{NLBS}, assign \locvar{\hti} the value
+ $(16*\locvar{HG}+\locvar{\hti_L})$.
+\item
+Otherwise, assign \locvar{\hti} the value
+ $(16*\locvar{HG}+\locvar{\hti_C})$.
+\item
+Read one bit at a time until one of the codes in $\bitvar{HTS}[\locvar{\hti}]$
+ is recognized, and assign the value to \locvar{TOKEN}.
+\item
+If \locvar{TOKEN} is less than 7, expand an EOB token using the procedure given
+ in Section~\ref{sub:eob-token} to update $\locvar{TIS}[\locvar{\bi}]$,
+ $\bitvar{COEFFS}[\locvar{\bi}]$, and \locvar{EOBS}.
+\item
+Otherwise, expand a coefficient token using the procedure given in
+ Section~\ref{sub:coeff-token} to update $\locvar{TIS}[\locvar{\bi}]$,
+ $\bitvar{COEFFS}[\locvar{\bi}]$, and $\bitvar{NCOEFFS}[\locvar{\bi}]$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\section{Undoing DC Prediction}
+
+The actual value of a DC coefficient decoded by Section~\ref{sec:dct-decode} is
+ the residual from a predicted value computed by the encoder.
+This prediction is only applied to DC coefficients.
+Quantized AC coefficients are encoded directly.
+
+This section describes how to undo this prediction to recover the original
+ DC coefficients.
+The predicted DC value for a block is computed from the DC values of its
+ immediate neighbors which precede the block in raster order.
+Thus, reversing this prediction must procede in raster order, instead of coded
+ order.
+
+Note that this step comes before dequantizing the coefficients.
+For this reason, DC coefficients are all quantized with the same \qi\ value,
+ regardless of the block-level \qi\ values decoded in
+ Section~\ref{sub:block-qis}.
+Those \qi\ values are applied only to the AC coefficients.
+
+\subsection{Computing the DC Predictor}
+\label{sub:dc-pred}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{BCODED} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 1 & No & An \bitvar{NBS}-element array of flags
+ indicating which blocks are coded. \\
+\bitvar{MBMODES} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 3 & No & An \bitvar{NMBS}-element array of
+ coding modes for each macro block. \\
+\bitvar{LASTDC} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 16 & Yes & A 3-element array containing the
+ most recently decoded DC value, one for inter mode and for each reference
+ frame. \\
+\bitvar{COEFFS} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bitvar{\bi} & Integer & 36 & No & The index of the current block in
+ coded order. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{DCPRED} & Integer & 16 & Yes & The predicted DC value for the current
+ block. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{P} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 1 & No & A 4-element array indicating which
+ neighbors can be used for DC prediction. \\
+\locvar{PBI} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 36 & No & A 4-element array containing the
+ coded-order block index of the current block's neighbors. \\
+\locvar{W} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 7 & Yes & A 4-element array of the weights to
+ apply to each neighboring DC value. \\
+\locvar{PDIV} & Integer & 8 & No & The value to divide the weighted sum
+ by. \\
+\locvar{\bj} & Integer & 36 & No & The index of a neighboring block in
+ coded order. \\
+\locvar{\mbi} & Integer & 32 & No & The index of the macro block
+ containing block \bitvar{\bi}. \\
+\locvar{\mbj} & Integer & 32 & No & The index of the macro block
+ containing block \locvar{\bj}. \\
+\locvar{\rfi} & Integer & 2 & No & The index of the reference frame
+ indicated by the coding mode for macro block \locvar{\mbi}. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure outlines how a predictor is formed for a single block.
+
+The predictor is computed as a weighted sum of the neighboring DC values from
+ coded blocks which use the same reference frame.
+This latter condition is determined only by checking the coding mode for the
+ block.
+Even if the golden frame and the previous frame are in fact the same, e.g. for
+ the first inter frame after an intra frame, they are still treated as being
+ different for the purposes of DC prediction.
+The weighted sum is divided by a power of two, with truncation towards zero,
+ and the result is checked for outranging if necessary.
+
+If there are no neighboring coded blocks which use the same reference frame as
+ the current block, then the most recent DC value of any block that used that
+ reference frame is used instead.
+If no such block exists, then the predictor is set to zero.
+
+\begin{enumerate}
+\item
+Assign \locvar{\mbi} the index of the macro block containing block
+ \bitvar{\bi}.
+\item
+Assign \locvar{\rfi} the value of the Reference Frame Index column of
+ Table~\ref{tab:cm-refs} corresponding to $\bitvar{MBMODES}[\locvar{\mbi}]$.
+
+\begin{table}[htpb]
+\begin{center}
+\begin{tabular}{ll}\toprule
+Coding Mode & Reference Frame Index \\\midrule
+$0$ (INTER\_NOMV) & $1$ (Previous) \\
+$1$ (INTRA) & $0$ (None) \\
+$2$ (INTER\_MV) & $1$ (Previous) \\
+$3$ (INTER\_MV\_LAST) & $1$ (Previous) \\
+$4$ (INTER\_MV\_LAST2) & $1$ (Previous) \\
+$5$ (INTER\_GOLDEN\_NOMV) & $2$ (Golden) \\
+$6$ (INTER\_GOLDEN\_MV) & $2$ (Golden) \\
+$7$ (INTER\_MV\_FOUR) & $1$ (Previous) \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Reference Frames for Each Coding Mode}
+\label{tab:cm-refs}
+\end{table}
+
+\item
+If block \bitvar{\bi} is not along the left edge of the coded frame:
+\begin{enumerate}
+\item
+Assign \locvar{\bj} the coded-order index of block \bitvar{\bi}'s left
+ neighbor, i.e., in the same row but one column to the left.
+\item
+If $\bitvar{BCODED}[\bj]$ is not zero:
+\begin{enumerate}
+\item
+Assign \locvar{\mbj} the index of the macro block containing block
+ \locvar{\bj}.
+\item
+If the value of the Reference Frame Index column of Table~\ref{tab:cm-refs}
+ corresonding to $\bitvar{MBMODES}[\locvar{\mbj}]$ equals \locvar{\rfi}:
+\begin{enumerate}
+\item
+Assign $\locvar{P}[0]$ the value $1$.
+\item
+Assign $\locvar{PBI}[0]$ the value \locvar{\bj}.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[0]$ the value zero.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[0]$ the value zero.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[0]$ the value zero.
+
+\item
+If block \bitvar{\bi} is not along the left edge nor the bottom edge of the
+ coded frame:
+\begin{enumerate}
+\item
+Assign \locvar{\bj} the coded-order index of block \bitvar{\bi}'s lower-left
+ neighbor, i.e., one row down and one column to the left.
+\item
+If $\bitvar{BCODED}[\bj]$ is not zero:
+\begin{enumerate}
+\item
+Assign \locvar{\mbj} the index of the macro block containing block
+ \locvar{\bj}.
+\item
+If the value of the Reference Frame Index column of Table~\ref{tab:cm-refs}
+ corresonding to $\bitvar{MBMODES}[\locvar{\mbj}]$ equals \locvar{\rfi}:
+\begin{enumerate}
+\item
+Assign $\locvar{P}[1]$ the value $1$.
+\item
+Assign $\locvar{PBI}[1]$ the value \locvar{\bj}.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[1]$ the value zero.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[1]$ the value zero.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[1]$ the value zero.
+
+\item
+If block \bitvar{\bi} is not along the bottom edge of the coded frame:
+\begin{enumerate}
+\item
+Assign \locvar{\bj} the coded-order index of block \bitvar{\bi}'s lower
+ neighbor, i.e., in the same column but one row down.
+\item
+If $\bitvar{BCODED}[\bj]$ is not zero:
+\begin{enumerate}
+\item
+Assign \locvar{\mbj} the index of the macro block containing block
+ \locvar{\bj}.
+\item
+If the value of the Reference Frame Index column of Table~\ref{tab:cm-refs}
+ corresonding to $\bitvar{MBMODES}[\locvar{\mbj}]$ equals \locvar{\rfi}:
+\begin{enumerate}
+\item
+Assign $\locvar{P}[2]$ the value $1$.
+\item
+Assign $\locvar{PBI}[2]$ the value \locvar{\bj}.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[2]$ the value zero.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[2]$ the value zero.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[2]$ the value zero.
+
+\item
+If block \bitvar{\bi} is not along the right edge nor the bottom edge of the
+ coded frame:
+\begin{enumerate}
+\item
+Assign \locvar{\bj} the coded-order index of block \bitvar{\bi}'s lower-right
+ neighbor, i.e., one row down and one column to the right.
+\item
+If $\bitvar{BCODED}[\bj]$ is not zero:
+\begin{enumerate}
+\item
+Assign \locvar{\mbj} the index of the macro block containing block
+ \locvar{\bj}.
+\item
+If the value of the Reference Frame Index column of Table~\ref{tab:cm-refs}
+ corresonding to $\bitvar{MBMODES}[\locvar{\mbj}]$ equals \locvar{\rfi}:
+\begin{enumerate}
+\item
+Assign $\locvar{P}[3]$ the value $1$.
+\item
+Assign $\locvar{PBI}[3]$ the value \locvar{\bj}.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[3]$ the value zero.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[3]$ the value zero.
+\end{enumerate}
+\item
+Otherwise, assign $\locvar{P}[3]$ the value zero.
+
+\item
+If none of the values $\locvar{P}[0]$, $\locvar{P}[1]$, $\locvar{P}[2]$, nor
+ $\locvar{P}[3]$ are non-zero, then assign \bitvar{DCPRED} the value
+ $\bitvar{LASTDC}[\locvar{\rfi}]$.
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Assign the array \locvar{W} and the variable \locvar{PDIV} the values from the
+ row of Table~\ref{tab:dc-weights} corresonding to the values of each
+ $\locvar{P}[\idx{i}]$.
+
+\begin{table}[htb]
+\begin{center}
+\begin{tabular}{ccccrrrrr}\toprule
+\multicolumn{1}{p{25pt}}{\centering$\locvar{P}[0]$ (L)} &
+\multicolumn{1}{p{25pt}}{\centering$\locvar{P}[1]$ (DL)} &
+\multicolumn{1}{p{25pt}}{\centering$\locvar{P}[2]$ (D)} &
+\multicolumn{1}{p{25pt}}{\centering$\locvar{P}[3]$ (DR)} &
+\multicolumn{1}{p{25pt}}{\centering$\locvar{W}[0]$ (L)} &
+\multicolumn{1}{p{25pt}}{\centering$\locvar{W}[1]$ (DL)} &
+\multicolumn{1}{p{25pt}}{\centering$\locvar{W}[2]$ (D)} &
+\multicolumn{1}{p{25pt}}{\centering$\locvar{W}[3]$ (DR)} &
+\locvar{PDIV} \\\midrule
+$1$ & $0$ & $0$ & $0$ & $1$ & $0$ & $0$ & $0$ & $1$ \\
+$0$ & $1$ & $0$ & $0$ & $0$ & $1$ & $0$ & $0$ & $1$ \\
+$1$ & $1$ & $0$ & $0$ & $1$ & $0$ & $0$ & $0$ & $1$ \\
+$0$ & $0$ & $1$ & $0$ & $0$ & $0$ & $1$ & $0$ & $1$ \\
+$1$ & $0$ & $1$ & $0$ & $1$ & $0$ & $1$ & $0$ & $2$ \\
+$0$ & $1$ & $1$ & $0$ & $0$ & $0$ & $1$ & $0$ & $1$ \\
+$1$ & $1$ & $1$ & $0$ & $29$ & $-26$ & $29$ & $0$ & $32$ \\
+$0$ & $0$ & $0$ & $1$ & $0$ & $0$ & $0$ & $1$ & $1$ \\
+$1$ & $0$ & $0$ & $1$ & $75$ & $0$ & $0$ & $53$ & $128$ \\
+$0$ & $1$ & $0$ & $1$ & $0$ & $1$ & $0$ & $1$ & $2$ \\
+$1$ & $1$ & $0$ & $1$ & $75$ & $0$ & $0$ & $53$ & $128$ \\
+$0$ & $0$ & $1$ & $1$ & $0$ & $0$ & $1$ & $0$ & $1$ \\
+$1$ & $0$ & $1$ & $1$ & $75$ & $0$ & $0$ & $53$ & $128$ \\
+$0$ & $1$ & $1$ & $1$ & $0$ & $3$ & $10$ & $3$ & $16$ \\
+$1$ & $1$ & $1$ & $1$ & $29$ & $-26$ & $29$ & $0$ & $32$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Weights and Divisors for Each Set of Available DC Predictors}
+\label{tab:dc-weights}
+\end{table}
+
+\item
+Assign \bitvar{DCPRED} the value zero.
+\item
+If $\locvar{P}[0]$ is non-zero, assign \bitvar{DCPRED} the value
+ $(\bitvar{DCPRED}+\locvar{W}[0]*\bitvar{COEFFS}[\locvar{PBI}[0]][0])$.
+\item
+If $\locvar{P}[1]$ is non-zero, assign \bitvar{DCPRED} the value
+ $(\bitvar{DCPRED}+\locvar{W}[1]*\bitvar{COEFFS}[\locvar{PBI}[1]][0])$.
+\item
+If $\locvar{P}[2]$ is non-zero, assign \bitvar{DCPRED} the value
+ $(\bitvar{DCPRED}+\locvar{W}[2]*\bitvar{COEFFS}[\locvar{PBI}[2]][0])$.
+\item
+If $\locvar{P}[3]$ is non-zero, assign \bitvar{DCPRED} the value
+ $(\bitvar{DCPRED}+\locvar{W}[3]*\bitvar{COEFFS}[\locvar{PBI}[3]][0])$.
+\item
+Assign \bitvar{DCPRED} the value $(\bitvar{DCPRED}//\locvar{PDIV})$.
+\item
+If $\locvar{P}[0]$, $\locvar{P}[1]$, and $\locvar{P}[2]$ are all non-zero:
+\begin{enumerate}
+\item
+If $|\bitvar{DCPRED}-\bitvar{COEFFS}[\locvar{PBI}[2]][0]|$ is greater than
+ $128$, assign \bitvar{DCPRED} the value $\bitvar{COEFFS}[\locvar{PBI}[2]][0]$.
+\item
+Otherwise, if $|\bitvar{DCPRED}-\bitvar{COEFFS}[\locvar{PBI}[0]][0]|$ is
+ greater than $128$, assign \bitvar{DCPRED} the value
+ $\bitvar{COEFFS}[\locvar{PBI}[0]][0]$.
+\item
+Otherwise, if $|\bitvar{DCPRED}-\bitvar{COEFFS}[\locvar{PBI}[1]][0]|$ is
+ greater than $128$, assign \bitvar{DCPRED} the value
+ $\bitvar{COEFFS}[\locvar{PBI}[1]][0]$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\subsection{Inverting the DC Prediction Process}
+\label{sub:dc-pred-undo}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{BCODED} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 1 & No & An \bitvar{NBS}-element array of flags
+ indicating which blocks are coded. \\
+\bitvar{MBMODES} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 3 & No & An \bitvar{NMBS}-element array of
+ coding modes for each macro block. \\
+\bitvar{COEFFS} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{COEFFS} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. The DC
+ value of each block will be updated. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{LASTDC} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 16 & Yes & A 3-element array containing the
+ most recently decoded DC value, one for inter mode and for each reference
+ frame. \\
+\locvar{DCPRED} & Integer & 11 & Yes & The predicted DC value for the current
+ block. \\
+\locvar{DC} & Integer & 17 & Yes & The actual DC value for the current
+ block. \\
+\locvar{\bi} & Integer & 36 & No & The index of the current block in
+ coded order. \\
+\locvar{\mbi} & Integer & 32 & No & The index of the macro block
+ containing block \locvar{\bi}. \\
+\locvar{\rfi} & Integer & 2 & No & The index of the reference frame
+ indicated by the coding mode for macro block \locvar{\mbi}. \\
+\locvar{\pli} & Integer & 2 & No & A color plane index. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure describes the complete process of undoing the DC prediction to
+ recover the original DC values.
+Because it is possible to add a value as large as $580$ to the predicted DC
+ coefficient value at every block, which will then be used to increase the
+ predictor for the next block, the reconstructed DC value could overflow a
+ 16-bit integer.
+This is handled by truncating the result to a 16-bit signed representation,
+ simply throwing away any higher bits in the two's complement representation of
+ the number.
+
+\begin{enumerate}
+\item
+For each consecutive value of \locvar{\pli} from $0$ to $2$:
+\begin{enumerate}
+\item
+Assign $\locvar{LASTDC}[0]$ the value zero.
+\item
+Assign $\locvar{LASTDC}[1]$ the value zero.
+\item
+Assign $\locvar{LASTDC}[2]$ the value zero.
+\item
+For each block of color plane \locvar{\pli} in {\em raster} order, with
+ coded-order index \locvar{\bi}:
+\begin{enumerate}
+\item
+If $\bitvar{BCODED}[\locvar{\bi}]$ is non-zero:
+\begin{enumerate}
+\item
+Compute the value \locvar{DCPRED} using the procedure outlined in
+ Section~\ref{sub:dc-pred}.
+\item
+Assign \locvar{DC} the value
+ $(\bitvar{COEFFS}[\locvar{\bi}][0]+\locvar{DCPRED})$.
+\item
+Truncate \locvar{DC} to a 16-bit representation by dropping any higher-order
+ bits.
+\item
+Assign $\bitvar{COEFFS}[\locvar{\bi}][0]$ the value \locvar{DC}.
+\item
+Assign \locvar{\mbi} the index of the macro block containing block
+ \locvar{\bi}.
+\item
+Assign \locvar{\rfi} the value of the Reference Frame Index column of
+ Table~\ref{tab:cm-refs} corresponding to $\bitvar{MBMODES}[\locvar{\mbi}]$.
+\item
+Assign $\locvar{LASTDC}[\rfi]$ the value $\locvar{DC}$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\section{Reconstruction}
+
+At this stage, the complete contents of the data packet have been decoded.
+All that remains is to reconstruct the contents of the new frame.
+This is applied on a block by block basis, and as each block is independent,
+ the order they are processed in does not matter.
+
+\subsection{Predictors}
+\label{sec:predictors}
+
+For each block, a predictor is formed based on its coding mode and motion
+ vector.
+There are three basic types of predictors: the intra predictor, the whole-pixel
+ predictor, and the half-pixel predictor.
+The former is used for all blocks coded in INTRA mode, while all other blocks
+ use one of the latter two.
+The whole-pixel predictor is used if the fractional part of both motion vector
+ components is zero, otherwise the half-pixel predictor is used.
+
+\subsubsection{The Intra Predictor}
+\label{sub:predintra}
+
+\paragraph{Input parameters:} None.
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{PRED} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & An $8\times 8$ array of predictor
+ values to use for INTRA coded blocks. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\idx{bx}} & Integer & 3 & No & The horizontal pixel index in the
+ block. \\
+\locvar{\idx{by}} & Integer & 3 & No & The vertical pixel index in the
+ block. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The intra predictor is nothing more than the constant value $128$.
+This is applied for the sole purpose of centering the range of possible DC
+ values for INTRA blocks around zero.
+
+\begin{enumerate}
+\item
+For each value of \locvar{\idx{by}} from $0$ to $7$, inclusive:
+\begin{enumerate}
+\item
+For each value of \locvar{\idx{bx}} from $0$ to $7$, inclusive:
+\begin{enumerate}
+\item
+Assign $\bitvar{PRED}[\locvar{\idx{by}}][\locvar{\idx{bx}}]$ the value $128$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\subsubsection{The Whole-Pixel Predictor}
+\label{sub:predfullpel}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RPW} & Integer & 20 & No & The width of the current plane of the
+ reference frame in pixels. \\
+\bitvar{RPH} & Integer & 20 & No & The height of the current plane of the
+ reference frame in pixels. \\
+\bitvar{REFP} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPH}\times\bitvar{RPW}$
+ array containing the contents of the current plane of the reference frame. \\
+\bitvar{BX} & Integer & 20 & No & The horizontal pixel index of the
+ lower-left corner of the current block. \\
+\bitvar{BY} & Integer & 20 & No & The vertical pixel index of the
+ lower-left corner of the current block. \\
+\bitvar{MVX} & Integer & 5 & No & The horizontal component of the block
+ motion vector.
+This is always a whole-pixel value. \\
+\bitvar{MVY} & Integer & 5 & No & The vertical component of the block
+ motion vector.
+This is always a whole-pixel value. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{PRED} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & An $8\times 8$ array of predictor
+ values to use for INTER coded blocks. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\idx{bx}} & Integer & 3 & Yes & The horizontal pixel index in the
+ block. \\
+\locvar{\idx{by}} & Integer & 3 & Yes & The vertical pixel index in the
+ block. \\
+\locvar{\idx{rx}} & Integer & 20 & No & The horizontal pixel index in the
+ reference frame. \\
+\locvar{\idx{ry}} & Integer & 20 & No & The vertical pixel index in the
+ reference frame. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The whole pixel predictor simply copies verbatim the contents of the reference
+ frame pointed to by the block's motion vector.
+If the vector points outside the reference frame, then the closest value on the
+ edge of the reference frame is used instead.
+In practice, this is usually implemented by expanding the size of the reference
+ frame by $8$ or $16$ pixels on each side---depending on whether or not the
+ corresponding axis is subsampled in the current plane---and copying the border
+ pixels into this region.
+
+\begin{enumerate}
+\item
+For each value of \locvar{\idx{by}} from $0$ to $7$, inclusive:
+\begin{enumerate}
+\item
+Assign \locvar{\idx{ry}} the value
+ $(\bitvar{BY}+\bitvar{MVY}+\locvar{\idx{by}})$.
+\item
+If \locvar{\idx{ry}} is greater than $(\bitvar{RPH}-1)$, assign
+ \locvar{\idx{ry}} the value $(\bitvar{RPH}-1)$.
+\item
+If \locvar{\idx{ry}} is less than zero, assign \locvar{\idx{ry}} the value
+ zero.
+\item
+For each value of \locvar{\idx{bx}} from $0$ to $7$, inclusive:
+\begin{enumerate}
+\item
+Assign \locvar{\idx{rx}} the value
+ $(\bitvar{BX}+\bitvar{MVX}+\locvar{\idx{bx}})$.
+\item
+If \locvar{\idx{rx}} is greater than $(\bitvar{RPW}-1)$, assign
+ \locvar{\idx{rx}} the value $(\bitvar{RPW}-1)$.
+\item
+If \locvar{\idx{rx}} is less than zero, assign \locvar{\idx{rx}} the value
+ zero.
+\item
+Assign $\bitvar{PRED}[\locvar{\idx{by}}][\locvar{\idx{bx}}]$ the value
+ $\bitvar{REFP}[\locvar{\idx{ry}}][\locvar{\idx{rx}}]$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\subsubsection{The Half-Pixel Predictor}
+\label{sub:predhalfpel}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RPW} & Integer & 20 & No & The width of the current plane of the
+ reference frame in pixels. \\
+\bitvar{RPH} & Integer & 20 & No & The height of the current plane of the
+ reference frame in pixels. \\
+\bitvar{REFP} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPH}\times\bitvar{RPW}$
+ array containing the contents of the current plane of the reference frame. \\
+\bitvar{BX} & Integer & 20 & No & The horizontal pixel index of the
+ lower-left corner of the current block. \\
+\bitvar{BY} & Integer & 20 & No & The vertical pixel index of the
+ lower-left corner of the current block. \\
+\bitvar{MVX} & Integer & 5 & No & The horizontal component of the first
+ whole-pixel motion vector. \\
+\bitvar{MVY} & Integer & 5 & No & The vertical component of the first
+ whole-pixel motion vector. \\
+\bitvar{MVX2} & Integer & 5 & No & The horizontal component of the second
+ whole-pixel motion vector. \\
+\bitvar{MVY2} & Integer & 5 & No & The vertical component of the second
+ whole-pixel motion vector. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{PRED} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & An $8\times 8$ array of predictor
+ values to use for INTER coded blocks. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\idx{bx}} & Integer & 3 & Yes & The horizontal pixel index in the
+ block. \\
+\locvar{\idx{by}} & Integer & 3 & Yes & The vertical pixel index in the
+ block. \\
+\locvar{\idx{rx1}} & Integer & 20 & No & The first horizontal pixel index in
+ the reference frame. \\
+\locvar{\idx{ry1}} & Integer & 20 & No & The first vertical pixel index in the
+ reference frame. \\
+\locvar{\idx{rx2}} & Integer & 20 & No & The second horizontal pixel index in
+ the reference frame. \\
+\locvar{\idx{ry2}} & Integer & 20 & No & The second vertical pixel index in
+ the reference frame. \\
+\bottomrule\end{tabularx}
+\medskip
+
+If one or both of the components of the block motion vector is not a
+ whole-pixel value, then the half-pixel predictor is used.
+The half-pixel predictor converts the fractional motion vector into two
+ whole-pixel motion vectors.
+The first is formed by truncating the values of each component towards zero,
+ and the second is formed by truncating them away from zero.
+The contributions from the reference frame at the locations pointed to by each
+ vector are averaged, truncating towards negative infinity.
+
+Only two samples from the reference frame contribute to each predictor value,
+ even if both components of the motion vector have non-zero fractional
+ components.
+Motion vector components with quarter-pixel accuracy in the chroma planes are
+ treated exactly the same as those with half-pixel accuracy.
+Any non-zero fractional part gets rounded one way in the first vector, and the
+ other way in the second.
+
+\begin{enumerate}
+\item
+For each value of \locvar{\idx{by}} from $0$ to $7$, inclusive:
+\begin{enumerate}
+\item
+Assign \locvar{\idx{ry1}} the value
+ $(\bitvar{BY}+\bitvar{MVY1}+\locvar{\idx{by}})$.
+\item
+If \locvar{\idx{ry1}} is greater than $(\bitvar{RPH}-1)$, assign
+ \locvar{\idx{ry1}} the value $(\bitvar{RPH}-1)$.
+\item
+If \locvar{\idx{ry1}} is less than zero, assign \locvar{\idx{ry1}} the value
+ zero.
+\item
+Assign \locvar{\idx{ry2}} the value
+ $(\bitvar{BY}+\bitvar{MVY2}+\locvar{\idx{by}})$.
+\item
+If \locvar{\idx{ry2}} is greater than $(\bitvar{RPH}-1)$, assign
+ \locvar{\idx{ry2}} the value $(\bitvar{RPH}-1)$.
+\item
+If \locvar{\idx{ry2}} is less than zero, assign \locvar{\idx{ry2}} the value
+ zero.
+\item
+For each value of \locvar{\idx{bx}} from $0$ to $7$, inclusive:
+\begin{enumerate}
+\item
+Assign \locvar{\idx{rx1}} the value
+ $(\bitvar{BX}+\bitvar{MVX1}+\locvar{\idx{bx}})$.
+\item
+If \locvar{\idx{rx1}} is greater than $(\bitvar{RPW}-1)$, assign
+ \locvar{\idx{rx1}} the value $(\bitvar{RPW}-1)$.
+\item
+If \locvar{\idx{rx1}} is less than zero, assign \locvar{\idx{rx1}} the value
+ zero.
+\item
+Assign \locvar{\idx{rx2}} the value
+ $(\bitvar{BX}+\bitvar{MVX2}+\locvar{\idx{bx}})$.
+\item
+If \locvar{\idx{rx2}} is greater than $(\bitvar{RPW}-1)$, assign
+ \locvar{\idx{rx2}} the value $(\bitvar{RPW}-1)$.
+\item
+If \locvar{\idx{rx2}} is less than zero, assign \locvar{\idx{rx2}} the value
+ zero.
+\item
+Assign $\bitvar{PRED}[\locvar{\idx{by}}][\locvar{\idx{bx}}]$ the value
+\begin{equation*}
+ (\bitvar{REFP}[\locvar{\idx{ry1}}][\locvar{\idx{rx1}}]+
+ \bitvar{REFP}[\locvar{\idx{ry2}}][\locvar{\idx{rx2}}])>>1.
+\end{equation*}
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\subsection{Dequantization}
+\label{sub:dequant}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{COEFFS} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bitvar{ACSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 16 & No & A 64-element array of scale values for
+ AC coefficients for each \qi\ value. \\
+\bitvar{DCSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 16 & No & A 64-element array of scale values for
+ the DC coefficient for each \qi\ value. \\
+\bitvar{BMS} & \multicolumn{1}{p{50pt}}{2D Integer array} &
+ 8 & No & A $\bitvar{NBMS}\times 64$ array
+ containing the base matrices. \\
+\bitvar{NQRS} & \multicolumn{1}{p{50pt}}{2D Integer array} &
+ 6 & No & A $2\times 3$ array containing the
+ number of quant ranges for a given \qti\ and \pli, respectively.
+This is at most $63$. \\
+\bitvar{QRSIZES} & \multicolumn{1}{p{50pt}}{3D Integer array} &
+ 6 & No & A $2\times 3\times 63$ array of the
+ sizes of each quant range for a given \qti\ and \pli, respectively.
+Only the first $\bitvar{NQRS}[\qti][\pli]$ values are used. \\
+\bitvar{QRBMIS} & \multicolumn{1}{p{50pt}}{3D Integer array} &
+ 9 & No & A $2\times 3\times 64$ array of the
+ \bmi's used for each quant range for a given \qti\ and \pli, respectively.
+Only the first $(\bitvar{NQRS}[\qti][\pli]+1)$ values are used. \\
+\bitvar{\qti} & Integer & 1 & No & A quantization type index.
+See Table~\ref{tab:quant-types}.\\
+\bitvar{\pli} & Integer & 2 & No & A color plane index.
+See Table~\ref{tab:color-planes}.\\
+\bitvar{\idx{qi0}} & Integer & 6 & No & The quantization index of the DC
+ coefficient. \\
+\bitvar{\qi} & Integer & 6 & No & The quantization index of the AC
+ coefficients. \\
+\bitvar{\bi} & Integer & 36 & No & The index of the current block in
+ coded order. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{DQC} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 14 & Yes & A $64$-element array of dequantized
+ DCT coefficients in natural order (cf. Section~\ref{sec:dct-coeffs}). \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{QMAT} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 16 & No & A 64-element array of quantization
+ values for each DCT coefficient in natural order. \\
+\locvar{\ci} & Integer & 6 & No & The DCT coefficient index in natural
+ order. \\
+\locvar{\zzi} & Integer & 6 & No & The DCT coefficient index in zig-zag
+ order. \\
+\locvar{C} & Integer & 29 & Yes & A single dequantized coefficient. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure takes the quantized DCT coefficient values in zig-zag order for
+ a single block---after DC prediction has been undone---and returns the
+ dequantized values in natural order.
+If large coefficient values are decoded for coarsely quantized coefficients,
+ the resulting dequantized value can be significantly larger than 16 bits.
+Such a coefficient is truncated to a signed 16-bit representation by discarding
+ the higher-order bits of its twos-complement representation.
+
+Although this procedure recomputes the quantization matrices from the
+ parameters in the setup header for each block, there are at most six different
+ ones used for each color plane.
+An efficient implementation could compute them once in advance.
+
+\begin{enumerate}
+\item
+Using \bitvar{ACSCALE}, \bitvar{DCSCALE}, \bitvar{BMS}, \bitvar{NQRS},
+ \bitvar{QRSIZES}, \bitvar{QRBMIS}, \bitvar{\qti}, \bitvar{\pli}, and
+ \bitvar{\idx{qi0}}, use the procedure given in Section~\ref{sub:quant-mat} to
+ compute the DC quantization matrix \locvar{QMAT}.
+\item
+Assign \locvar{C} the value
+ $\bitvar{COEFFS}[\bitvar{\bi}][0]*\locvar{QMAT}[0]$.
+\item
+Truncate \locvar{C} to a 16-bit representation by dropping any higher-order
+ bits.
+\item
+Assign $\bitvar{DQC}[0]$ the value \locvar{C}.
+\item
+Using \bitvar{ACSCALE}, \bitvar{DCSCALE}, \bitvar{BMS}, \bitvar{NQRS},
+ \bitvar{QRSIZES}, \bitvar{QRBMIS}, \bitvar{\qti}, \bitvar{\pli}, and
+ \bitvar{\qi}, use the procedure given in Section~\ref{sub:quant-mat} to
+ compute the AC quantization matrix \locvar{QMAT}.
+\item
+For each value of \locvar{\ci} from 1 to 63, inclusive:
+\begin{enumerate}
+\item
+Assign \locvar{\zzi} the index in zig-zag order corresponding to \locvar{\ci}.
+E.g., the value at row $(\locvar{\ci}//8)$ and column $(\locvar{\ci}\%8)$ in
+ Figure~\ref{tab:zig-zag}
+\item
+Assign \locvar{C} the value
+ $\bitvar{COEFFS}[\bitvar{\bi}][\locvar{\zzi}]*\locvar{QMAT}[\locvar{\ci}]$.
+\item
+Truncate \locvar{C} to a 16-bit representation by dropping any higher-order
+ bits.
+\item
+Assign $\bitvar{DQC}[\locvar{\ci}]$ the value \locvar{C}.
+\end{enumerate}
+\end{enumerate}
+
+\subsection{The Inverse DCT}
+
+The 2D inverse DCT is separated into two applications of the 1D inverse DCT.
+The transform is first applied to each row, and then applied to each column of
+ the result.
+
+Each application of the 1D inverse DCT scales the values by a factor of two
+ relative to the orthonormal version of the transform, for a total scale factor
+ of four for the 2D transform.
+It is assumed that a similar scale factor is applied during the forward DCT
+ used in the encoder, so that a division by 16 is required after the transform
+ has been applied in both directions.
+The inclusion of this scale factor allows the integerized transform to operate
+ with increased precision.
+All divisions throughout the transform are implemented with right shifts.
+Only the final division by $16$ is rounded, with ties rounded towards positive
+ infinity.
+
+All intermediate values are truncated to a 32-bit signed representation by
+ discarding any higher-order bits in their two's complement representation.
+The final output of each 1D transform is truncated to a 16-bit signed value in
+ the same manner.
+In practice, if the high word of a $16\times 16$ bit multiplication can be
+ obtained directly, 16 bits is sufficient for every calculation except scaling
+ by $C4$.
+Thus we truncate to 16 bits before that multiplication to allow an
+ implementation entirely in 16-bit registers.
+Implementations using larger registers must sign-extend the 16-bit value to
+ maintain compatibility.
+
+Note that if 16-bit register are used, overflow in the additions and
+ subtractions should be handled using \textit{unsaturated} arithmetic.
+That is, the high-order bits should be discarded and the low-order bits
+ retained, instead of clamping the result to the maximum or minimum value.
+This allows the maximum flexibility in re-ordering these instructions without
+ deviating from this specification.
+
+The 1D transform can only overflow if input coefficients larger than $\pm 6201$
+ are present.
+However, the result of applying the 2D forward transform on pixel values in the
+ range $-255\ldots 255$ can be as large as $\pm 8157$ due to the scale factor
+ of four that is applied, and quantization errors could make this even larger.
+Therefore, the coefficients cannot simply be clamped into a valid range before
+ the transform.
+
+\subsubsection{The 1D Inverse DCT}
+\label{sub:1d-idct}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{Y} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 16 & Yes & An 8-element array of DCT
+ coefficients. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{X} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 16 & Yes & An 8-element array of output values. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{T} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 32 & Yes & An 8-element array containing the
+ current value of each signal line. \\
+\locvar{R} & Integer & 32 & Yes & A temporary value. \\
+\bottomrule\end{tabularx}
+\medskip
+
+A compliant decoder MUST use the exact implementation of the inverse DCT
+ defined in this specification.
+Some operations may be re-ordered, but the result must be precisely equivalent.
+This is a design decision that limits some avenues of decoder optimization, but
+ prevents any drift in the prediction loop.
+The full inverse DCT described in this section is only used when there is at
+ least one non-zero AC coefficient.
+Otherwise, a special DC-only case is used, which is described below in
+ step~\ref{step:dc-only-idct} of Section~\ref{sub:recon}.
+The DC-only special case is not exactly equivalent to applying the full inverse
+ transform, because it avoids the intermediate multiplications and truncation,
+ and it MUST be used in place of the full transform to ensure bit-exact decode.
+
+Theora uses a 16-bit integerized approximation of of the 8-point 1D inverse DCT
+ based on the Chen factorization \cite{CSF77}.
+It requires 16 multiplications and 26 additions and subtractions.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[width=\textwidth]{idct}
+\end{center}
+\caption{Signal Flow Graph for the 1D Inverse DCT}
+\label{fig:idct}
+\end{figure}
+
+A signal flow graph of the transformation is presented in
+ Figure~\ref{fig:idct}.
+This graph provides a good visualization of which parts of the transform are
+ parallelizable.
+Time increases from left to right.
+
+Each signal line is involved in an operation where the line is marked with a
+ dot $\cdot$ or a circled plus sign $\oplus$.
+The constants $\locvar{C}i$ and $\locvar{S}j$ are the 16-bit integer
+ approximations of $\cos(\frac{i\pi}{16})$ and $\sin(\frac{j\pi}{16})$ listed
+ in Table~\ref{tab:dct-consts}.
+When they appear next to a signal line, the value on that line is scaled by the
+ given constant.
+A circled minus sign $\ominus$ next to a signal line indicates that the value
+ on that line is negated.
+
+Operations on a single signal path through the graph cannot be reordered, but
+ operations on different paths may be, or may be executed in parallel.
+Different graphs may be obtainable using the associative, commutative, and
+ distributive properties of unsaturated arithmetic.
+The column of numbers on the left represents an initial permutation of the
+ input DCT coefficients.
+The column on the right represents the unpermuted output.
+One can be obtained by bit-reversing the 3-bit binary representation of the
+ other.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{llr}\toprule
+$\locvar{C}i$ & $\locvar{S}j$ & Value \\\midrule
+$\locvar{C1}$ & $\locvar{S7}$ & $64277$ \\
+$\locvar{C2}$ & $\locvar{S6}$ & $60547$ \\
+$\locvar{C3}$ & $\locvar{S5}$ & $54491$ \\
+$\locvar{C4}$ & $\locvar{S4}$ & $46341$ \\
+$\locvar{C5}$ & $\locvar{S3}$ & $36410$ \\
+$\locvar{C6}$ & $\locvar{S2}$ & $25080$ \\
+$\locvar{C7}$ & $\locvar{S1}$ & $12785$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{16-bit Approximations of Sines and Cosines}
+\label{tab:dct-consts}
+\end{table}
+
+\begin{enumerate}
+\item
+Assign $\locvar{T}[0]$ the value $\bitvar{Y}[0]+\bitvar{Y}[4]$.
+\item
+Truncate $\locvar{T}[0]$ to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\locvar{T}[0]$ the value
+ $\locvar{C4}*\locvar{T}[0]>>16$.
+\item
+Assign $\locvar{T}[1]$ the value $\bitvar{Y}[0]-\bitvar{Y}[4]$.
+\item
+Truncate $\locvar{T}[1]$ to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\locvar{T}[1]$ the value $\locvar{C4}*\locvar{T}[1]>>16$.
+\item
+Assign $\locvar{T}[2]$ the value $(\locvar{C6}*\bitvar{Y}[2]>>16)-
+ (\locvar{S6}*\bitvar{Y}[6]>>16)$.
+\item
+Assign $\locvar{T}[3]$ the value $(\locvar{S6}*\bitvar{Y}[2]>>16)+
+ (\locvar{C6}*\bitvar{Y}[6]>>16)$.
+\item
+Assign $\locvar{T}[4]$ the value $(\locvar{C7}*\bitvar{Y}[1]>>16)-
+ (\locvar{S7}*\bitvar{Y}[7]>>16)$.
+\item
+Assign $\locvar{T}[5]$ the value $(\locvar{C3}*\bitvar{Y}[5]>>16)-
+ (\locvar{S3}*\bitvar{Y}[3]>>16)$.
+\item
+Assign $\locvar{T}[6]$ the value $(\locvar{S3}*\bitvar{Y}[5]>>16)+
+ (\locvar{C3}*\bitvar{Y}[3]>>16)$.
+\item
+Assign $\locvar{T}[7]$ the value $(\locvar{S7}*\bitvar{Y}[1]>>16)+
+ (\locvar{C7}*\bitvar{Y}[7]>>16)$.
+\item
+Assign \locvar{R} the value $\locvar{T}[4]+\locvar{T}[5]$.
+\item
+Assign $\locvar{T}[5]$ the value $\locvar{T}[4]-\locvar{T}[5]$.
+\item
+Truncate $\locvar{T}[5]$ to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\locvar{T}[5]$ the value $\locvar{C4}*\locvar{T}[5]>>16$.
+\item
+Assign $\locvar{T}[4]$ the value $\locvar{R}$.
+\item
+Assign \locvar{R} the value $\locvar{T}[7]+\locvar{T}[6]$.
+\item
+Assign $\locvar{T}[6]$ the value $\locvar{T}[7]-\locvar{T}[6]$.
+\item
+Truncate $\locvar{T}[6]$ to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\locvar{T}[6]$ the value $\locvar{C4}*\locvar{T}[6]>>16$.
+\item
+Assign $\locvar{T}[7]$ the value $\locvar{R}$.
+\item
+Assign \locvar{R} the value $\locvar{T}[0]+\locvar{T}[3]$.
+\item
+Assign $\locvar{T}[3]$ the value $\locvar{T}[0]-\locvar{T}[3]$.
+\item
+Assign $\locvar{T}[0]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[1]+\locvar{T}[2]$
+\item
+Assign $\locvar{T}[2]$ the value $\locvar{T}[1]-\locvar{T}[2]$
+\item
+Assign $\locvar{T}[1]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[6]+\locvar{T}[5]$.
+\item
+Assign $\locvar{T}[5]$ the value $\locvar{T}[6]-\locvar{T}[5]$.
+\item
+Assign $\locvar{T}[6]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[0]+\locvar{T}[7]$.
+\item
+Truncate \locvar{R} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\bitvar{X}[0]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[1]+\locvar{T}[6]$.
+\item
+Truncate \locvar{R} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\bitvar{X}[1]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[2]+\locvar{T}[5]$.
+\item
+Truncate \locvar{R} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\bitvar{X}[2]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[3]+\locvar{T}[4]$.
+\item
+Truncate \locvar{R} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\bitvar{X}[3]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[3]-\locvar{T}[4]$.
+\item
+Truncate \locvar{R} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\bitvar{X}[4]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[2]-\locvar{T}[5]$.
+\item
+Truncate \locvar{R} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\bitvar{X}[5]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[1]-\locvar{T}[6]$.
+\item
+Truncate \locvar{R} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\bitvar{X}[6]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[0]-\locvar{T}[7]$.
+\item
+Truncate \locvar{R} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+Assign $\bitvar{X}[7]$ the value \locvar{R}.
+\end{enumerate}
+
+\subsubsection{The 2D Inverse DCT}
+\label{sub:2d-idct}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{DQC} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 14 & Yes & A $64$-element array of dequantized
+ DCT coefficients in natural order (cf. Section~\ref{sec:dct-coeffs}). \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RES} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 16 & Yes & An $8\times 8$ array containing the
+ decoded residual for the current block. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{\ci} & Integer & 3 & No & The column index. \\
+\locvar{\ri} & Integer & 3 & No & The row index. \\
+\locvar{Y} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 16 & Yes & An 8-element array of 1D iDCT input
+ values. \\
+\locvar{X} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 16 & Yes & An 8-element array of 1D iDCT output
+ values. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure applies the 1D inverse DCT transform 16 times to a block of
+ dequantized coefficients: once for each of the 8 rows, and once for each of
+ the 8 columns of the result.
+Note that the coordinate system used for the columns is the same right-handed
+ coordinate system used by the rest of Theora.
+Thus, the column is indexed from bottom to top, not top to bottom.
+The final values are divided by sixteen, rounding with ties rounded towards
+ postive infinity.
+
+\begin{enumerate}
+\item
+For each value of \locvar{\ri} from 0 to 7:
+\begin{enumerate}
+\item
+For each value of \locvar{\ci} from 0 to 7:
+\begin{enumerate}
+\item
+Assign $\locvar{Y}[\locvar{\ci}]$ the value
+ $\bitvar{DQC}[\locvar{\ri}*8+\locvar{\ci}]$.
+\end{enumerate}
+\item
+Compute \locvar{X}, the 1D inverse DCT of \locvar{Y} using the procedure
+ described in Section~\ref{sub:1d-idct}.
+\item
+For each value of $\locvar{\ci}$ from 0 to 7:
+\begin{enumerate}
+\item
+Assign $\bitvar{RES}[\locvar{\ri}][\locvar{\ci}]$ the value
+ $\locvar{X}[\locvar{\ci}]$.
+\end{enumerate}
+\end{enumerate}
+\item
+For each value of \locvar{\ci} from 0 to 7:
+\begin{enumerate}
+\item
+For each value of \locvar{\ri} from 0 to 7:
+\begin{enumerate}
+\item
+Assign $\locvar{Y}[\locvar{\ri}]$ the value
+ $\bitvar{RES}[\locvar{\ri}][\locvar{\ci}]$.
+\end{enumerate}
+\item
+Compute \locvar{X}, the 1D inverse DCT of \locvar{Y} using the procedure
+ described in Section~\ref{sub:1d-idct}.
+\item
+For each value of \locvar{\ri} from 0 to 7:
+\begin{enumerate}
+\item
+Assign $\bitvar{RES}[\locvar{\ri}][\locvar{\ci}]$ the value
+ $(\locvar{X}[\locvar{\ri}]+8)>>4$.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\subsubsection{The 1D Forward DCT (Non-Normative)}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{X} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 14 & Yes & An 8-element array of input values. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{Y} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 16 & Yes & An 8-element array of DCT
+ coefficients. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{T} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 16 & Yes & An 8-element array containing the
+ current value of each signal line. \\
+\locvar{R} & Integer & 16 & Yes & A temporary value. \\
+\bottomrule\end{tabularx}
+\medskip
+
+The forward transform used in the encoder is not mandated by this standard as
+ the inverse one is.
+Precise equivalence in the inverse transform alone is all that is required to
+ guarantee that there is no mismatch in the prediction loop between encoder and
+ any compliant decoder implementation.
+However, a forward transform is provided here as a convenience for implementing
+ an encoder.
+This is the version of the transform used by Xiph.Org's Theora encoder, which
+ is the same as that used by VP3.
+Like the inverse DCT, it is first applied to each row, and then applied to each
+ column of the result.
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics[width=\textwidth]{fdct}
+\end{center}
+\caption{Signal Flow Graph for the 1D Forward DCT}
+\label{fig:fdct}
+\end{figure}
+
+The signal flow graph for the forward transform is given in
+ Figure~\ref{fig:fdct}.
+It is largely the reverse of the flow graph given for the inverse DCT.
+It is important to note that the signs on the constants in the rotations have
+ changed, and the \locvar{C4} scale factors on one of the lower butterflies now
+ appear on the opposite side.
+The column of numbers on the left represents the unpermuted input, and the
+ column on the right the permuted output DCT coefficients.
+
+A proper division by $2^{16}$ is done after the multiplications instead of a
+ shift in the forward transform.
+This can be implemented quickly by adding an offset of $\hex{FFFF}$ if the
+ number is negative, and then shifting as before.
+This slightly increases the computational complexity of the transform.
+Unlike the inverse DCT, 16-bit registers and a $16\times16\rightarrow32$ bit
+ multiply are sufficient to avoid any overflow, so long as the input is in the
+ range $-6270\ldots 6270$, which is larger than required.
+
+\begin{enumerate}
+\item
+Assign $\locvar{T}[0]$ the value $\bitvar{X}[0]+\bitvar{X}[7]$.
+\item
+Assign $\locvar{T}[1]$ the value $\bitvar{X}[1]+\bitvar{X}[6]$.
+\item
+Assign $\locvar{T}[2]$ the value $\bitvar{X}[2]+\bitvar{X}[5]$.
+\item
+Assign $\locvar{T}[3]$ the value $\bitvar{X}[3]+\bitvar{X}[4]$.
+\item
+Assign $\locvar{T}[4]$ the value $\bitvar{X}[3]-\bitvar{X}[4]$.
+\item
+Assign $\locvar{T}[5]$ the value $\bitvar{X}[2]-\bitvar{X}[5]$.
+\item
+Assign $\locvar{T}[6]$ the value $\bitvar{X}[1]-\bitvar{X}[6]$.
+\item
+Assign $\locvar{T}[7]$ the value $\bitvar{X}[0]-\bitvar{X}[7]$.
+\item
+Assign \locvar{R} the value $\locvar{T}[0]+\locvar{T}[3]$.
+\item
+Assign $\locvar{T}[3]$ the value $\locvar{T}[0]-\locvar{T}[3]$.
+\item
+Assign $\locvar{T}[0]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[1]+\locvar{T}[2]$.
+\item
+Assign $\locvar{T}[2]$ the value $\locvar{T}[1]-\locvar{T}[2]$.
+\item
+Assign $\locvar{T}[1]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[6]-\locvar{T}[5]$.
+\item
+Assign $\locvar{T}[6]$ the value
+ $(\locvar{C4}*(\locvar{T}[6]+\locvar{T}[5]))//16$.
+\item
+Assign $\locvar{T}[5]$ the value $(\locvar{C4}*\locvar{R})//16$.
+\item
+Assign \locvar{R} the value $\locvar{T}[4]+\locvar{T}[5]$.
+\item
+Assign $\locvar{T}[5]$ the value $\locvar{T}[4]-\locvar{T}[5]$.
+\item
+Assign $\locvar{T}[4]$ the value \locvar{R}.
+\item
+Assign \locvar{R} the value $\locvar{T}[7]+\locvar{T}[6]$.
+\item
+Assign $\locvar{T}[6]$ the value $\locvar{T}[7]-\locvar{T}[6]$.
+\item
+Assign $\locvar{T}[7]$ the value \locvar{R}.
+\item
+Assign $\bitvar{Y}[0]$ the value
+ $(\locvar{C4}*(\locvar{T}[0]+\locvar{T}[1]))//16$.
+\item
+Assign $\bitvar{Y}[4]$ the value
+ $(\locvar{C4}*(\locvar{T}[0]-\locvar{T}[1]))//16$.
+\item
+Assign $\bitvar{Y}[2]$ the value
+ $((\locvar{S6}*\locvar{T}[3])//16)+
+ ((\locvar{C6}*\locvar{T}[2])//16)$.
+\item
+Assign $\bitvar{Y}[6]$ the value
+ $((\locvar{C6}*\locvar{T}[3])//16)-
+ ((\locvar{S6}*\locvar{T}[2])//16)$.
+\item
+Assign $\bitvar{Y}[1]$ the value
+ $((\locvar{S7}*\locvar{T}[7])//16)+
+ ((\locvar{C7}*\locvar{T}[4])//16)$.
+\item
+Assign $\bitvar{Y}[5]$ the value
+ $((\locvar{S3}*\locvar{T}[6])//16)+
+ ((\locvar{C3}*\locvar{T}[5])//16)$.
+\item
+Assign $\bitvar{Y}[3]$ the value
+ $((\locvar{C3}*\locvar{T}[6])//16)-
+ ((\locvar{S3}*\locvar{T}[5])//16)$.
+\item
+Assign $\bitvar{Y}[7]$ the value
+ $((\locvar{C7}*\locvar{T}[7])//16)-
+ ((\locvar{S7}*\locvar{T}[4])//16)$.
+\end{enumerate}
+
+\subsection{The Complete Reconstruction Algorithm}
+\label{sub:recon}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{ACSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 16 & No & A 64-element array of scale values
+ for AC coefficients for each \qi\ value. \\
+\bitvar{DCSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 16 & No & A 64-element array of scale values
+ for the DC coefficient for each \qi\ value. \\
+\bitvar{BMS} & \multicolumn{1}{p{50pt}}{2D Integer array} &
+ 8 & No & A $\bitvar{NBMS}\times 64$ array
+ containing the base matrices. \\
+\bitvar{NQRS} & \multicolumn{1}{p{50pt}}{2D Integer array} &
+ 6 & No & A $2\times 3$ array containing the
+ number of quant ranges for a given \qti\ and \pli, respectively.
+This is at most $63$. \\
+\bitvar{QRSIZES} & \multicolumn{1}{p{50pt}}{3D Integer array} &
+ 6 & No & A $2\times 3\times 63$ array of the
+ sizes of each quant range for a given \qti\ and \pli, respectively.
+Only the first $\bitvar{NQRS}[\qti][\pli]$ values are used. \\
+\bitvar{QRBMIS} & \multicolumn{1}{p{50pt}}{3D Integer array} &
+ 9 & No & A $2\times 3\times 64$ array of the
+ \bmi's used for each quant range for a given \qti\ and \pli, respectively.
+Only the first $(\bitvar{NQRS}[\qti][\pli]+1)$ values are used. \\
+\bitvar{RPYW} & Integer & 20 & No & The width of the $Y'$ plane of the
+ reference frames in pixels. \\
+\bitvar{RPYH} & Integer & 20 & No & The height of the $Y'$ plane of the
+ reference frames in pixels. \\
+\bitvar{RPCW} & Integer & 20 & No & The width of the $C_b$ and $C_r$
+ planes of the reference frames in pixels. \\
+\bitvar{RPCH} & Integer & 20 & No & The height of the $C_b$ and $C_r$
+ planes of the reference frames in pixels. \\
+\bitvar{GOLDREFY} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the golden reference
+ frame. \\
+\bitvar{GOLDREFCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the golden reference
+ frame. \\
+\bitvar{GOLDREFCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the golden reference
+ frame. \\
+\bitvar{PREVREFY} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the previous reference
+ frame. \\
+\bitvar{PREVREFCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the previous reference
+ frame. \\
+\bitvar{PREVREFCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the previous reference
+ frame. \\
+\bitvar{NBS} & Integer & 36 & No & The total number of blocks in a
+ frame. \\
+\bitvar{BCODED} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 1 & No & An \bitvar{NBS}-element array of
+ flags indicating which blocks are coded. \\
+\bitvar{MBMODES} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 3 & No & An \bitvar{NMBS}-element array of
+ coding modes for each macro block. \\
+\bitvar{MVECTS} & \multicolumn{1}{p{50pt}}{Array of 2D Integer Vectors} &
+ 6 & Yes & An \bitvar{NBS}-element array of
+ motion vectors for each block. \\
+\bitvar{COEFFS} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\bitvar{NCOEFFS} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 7 & No & An \bitvar{NBS}-element array of the
+ coefficient count for each block. \\
+\bitvar{QIS} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 6 & No & An \bitvar{NQIS}-element array of
+ \qi\ values. \\
+\bitvar{QIIS} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 2 & No & An \bitvar{NBS}-element array of
+ \locvar{\qii} values for each block. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RECY} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the reconstructed frame. \\
+\bitvar{RECCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the reconstructed frame. \\
+\bitvar{RECCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the reconstructed frame. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{RPW} & Integer & 20 & No & The width of the current plane of the
+ current reference frame in pixels. \\
+\locvar{RPH} & Integer & 20 & No & The height of the current plane of
+ the current reference frame in pixels. \\
+\locvar{REFP} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPH}\times\bitvar{RPW}$
+ array containing the contents of the current plane of the current reference
+ frame. \\
+\locvar{BX} & Integer & 20 & No & The horizontal pixel index of the
+ lower-left corner of the current block. \\
+\locvar{BY} & Integer & 20 & No & The vertical pixel index of the
+ lower-left corner of the current block. \\
+\locvar{MVX} & Integer & 5 & No & The horizontal component of the first
+ whole-pixel motion vector. \\
+\locvar{MVY} & Integer & 5 & No & The vertical component of the first
+ whole-pixel motion vector. \\
+\locvar{MVX2} & Integer & 5 & No & The horizontal component of the second
+ whole-pixel motion vector. \\
+\locvar{MVY2} & Integer & 5 & No & The vertical component of the second
+ whole-pixel motion vector. \\
+\locvar{PRED} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & An $8\times 8$ array of predictor
+ values to use for the current block. \\
+\locvar{RES} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 16 & Yes & An $8\times 8$ array containing the
+ decoded residual for the current block. \\
+\locvar{QMAT} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 16 & No & A 64-element array of quantization
+ values for each DCT coefficient in natural order. \\
+\locvar{DC} & Integer & 29 & Yes & The dequantized DC coefficient of a
+ block. \\
+\locvar{P} & Integer & 17 & Yes & A reconstructed pixel value. \\
+\locvar{\bi} & Integer & 36 & No & The index of the current block in
+ coded order. \\
+\locvar{\mbi} & Integer & 32 & No & The index of the macro block
+ containing block \locvar{\bi}. \\
+\locvar{\pli} & Integer & 2 & No & The color plane index of the current
+ block. \\
+\locvar{\rfi} & Integer & 2 & No & The index of the reference frame
+ indicated by the coding mode for macro block \locvar{\mbi}. \\
+\locvar{\idx{bx}} & Integer & 3 & No & The horizontal pixel index in the
+ block. \\
+\locvar{\idx{by}} & Integer & 3 & No & The vertical pixel index in the
+ block. \\
+\locvar{\qti} & Integer & 1 & No & A quantization type index.
+See Table~\ref{tab:quant-types}.\\
+\locvar{\idx{qi0}} & Integer & 6 & No & The quantization index of the DC
+ coefficient. \\
+\locvar{\qi} & Integer & 6 & No & The quantization index of the AC
+ coefficients. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This section takes the decoded packet data and uses the previously defined
+ procedures to reconstruct each block of the current frame.
+For coded blocks, a predictor is formed using the coding mode and, if
+ applicable, the motion vector, and then the residual is computed from the
+ quantized DCT coefficients.
+For uncoded blocks, the contents of the co-located block are copied from the
+ previous frame and the residual is cleared to zero.
+Then the predictor and residual are added, and the result clamped to the range
+ $0\ldots 255$ and stored in the current frame.
+
+In the special case that a block contains only a DC coefficient, the
+ dequantization and inverse DCT transform is skipped.
+Instead the constant pixel value for the entire block is computed in one step.
+Note that the truncation of intermediate operations is omitted and the final
+ rounding is slightly different in this case.
+The check for whether or not the block contains only a DC coefficient is based
+ on the coefficient count returned from the token decode procedure of
+ Section~\ref{sec:dct-decode}, and not by checking to see if the remaining
+ coefficient values are zero.
+Also note that even when the coefficient count indicates the block contains
+ zero coefficients, the DC coefficient is still processed, as undoing DC
+ prediction might have made it non-zero.
+
+After this procedure, the frame is completely reconstructed, but before it can
+ be used as a reference frame, a loop filter must be run over it to help reduce
+ blocking artifacts.
+This is detailed in Section~\ref{sec:loopfilter}.
+
+\begin{enumerate}
+\item
+Assign \locvar{\idx{qi0}} the value $\bitvar{QIS}[0]$.
+\item
+For each value of \locvar{\bi} from 0 to $(\bitvar{NBS}-1)$:
+\begin{enumerate}
+\item
+Assign \locvar{\pli} the index of the color plane block \locvar{\bi} belongs
+ to.
+\item
+Assign \locvar{BX} the horizontal pixel index of the lower-left corner of block
+ \locvar{\bi}.
+\item
+Assign \locvar{BY} the vertical pixel index of the lower-left corner of block
+ \locvar{\bi}.
+\item
+If $\bitvar{BCODED}[\locvar{\bi}]$ is non-zero:
+\begin{enumerate}
+\item
+Assign \locvar{\mbi} the index of the macro block containing block
+ \locvar{\bi}.
+\item
+If $\bitvar{MBMODES}[\locvar{\mbi}]$ is 1 (INTRA), assign \locvar{\qti} the
+ value $0$.
+\item
+Otherwise, assign \locvar{\qti} the value $1$.
+\item
+Assign \locvar{\rfi} the value of the Reference Frame Index column of
+ Table~\ref{tab:cm-refs} corresponding to $\bitvar{MBMODES}[\locvar{\mbi}]$.
+\item
+If \locvar{\rfi} is zero, compute \locvar{PRED} using the procedure given in
+ Section~\ref{sub:predintra}.
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Assign \locvar{REFP}, \locvar{RPW}, and \locvar{RPH} the values given in
+ Table~\ref{tab:refp} corresponding to current value of \locvar{\rfi} and
+ \locvar{\pli}.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{cclll}\toprule
+\locvar{\rfi} & \locvar{\pli} &
+\locvar{REFP} & \locvar{RPW} & \locvar{RPH} \\\midrule
+$1$ & $0$ & \bitvar{PREVREFY} & \bitvar{RPYW} & \bitvar{RPYH} \\
+$1$ & $1$ & \bitvar{PREVREFCB} & \bitvar{RPCW} & \bitvar{RPCH} \\
+$1$ & $2$ & \bitvar{PREVREFCR} & \bitvar{RPCW} & \bitvar{RPCH} \\
+$2$ & $0$ & \bitvar{GOLDREFY} & \bitvar{RPYW} & \bitvar{RPYH} \\
+$2$ & $1$ & \bitvar{GOLDREFCB} & \bitvar{RPCW} & \bitvar{RPCH} \\
+$2$ & $2$ & \bitvar{GOLDREFCR} & \bitvar{RPCW} & \bitvar{RPCH} \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Reference Planes and Sizes for Each \locvar{\rfi} and \locvar{\pli}}
+\label{tab:refp}
+\end{table}
+
+\item
+Assign \locvar{MVX} the value
+\begin{equation*}
+ \left\lfloor\lvert\bitvar{MVECTS}[\locvar{\bi}]_x\rvert\right\rfloor*
+ \sign(\bitvar{MVECTS}[\locvar{\bi}]_x).
+\end{equation*}
+\item
+Assign \locvar{MVY} the value
+\begin{equation*}
+ \left\lfloor\lvert\bitvar{MVECTS}[\locvar{\bi}]_y\rvert\right\rfloor*
+ \sign(\bitvar{MVECTS}[\locvar{\bi}]_y).
+\end{equation*}
+\item
+Assign \locvar{MVX2} the value
+\begin{equation*}
+ \left\lceil\lvert\bitvar{MVECTS}[\locvar{\bi}]_x\rvert\right\rceil*
+ \sign(\bitvar{MVECTS}[\locvar{\bi}]_x).
+\end{equation*}
+\item
+Assign \locvar{MVY2} the value
+\begin{equation*}
+ \left\lceil\lvert\bitvar{MVECTS}[\locvar{\bi}]_y\rvert\right\rceil*
+ \sign(\bitvar{MVECTS}[\locvar{\bi}]_y).
+\end{equation*}
+\item
+If \locvar{MVX} equals \locvar{MVX2} and \locvar{MVY} equals \locvar{MVY2},
+ use the values \locvar{REFP}, \locvar{RPW}, \locvar{RPH}, \locvar{BX},
+ \locvar{BY}, \locvar{MVX}, and \locvar{MVY}, compute \locvar{PRED} using the
+ procedure given in Section~\ref{sub:predfullpel}.
+\item
+Otherwise, use the values \locvar{REFP}, \locvar{RPW}, \locvar{RPH},
+ \locvar{BX}, \locvar{BY}, \locvar{MVX}, \locvar{MVY}, \locvar{MVX2}, and
+ \locvar{MVY2} to compute \locvar{PRED} using the procedure given in
+ Section~\ref{sub:predhalfpel}.
+\end{enumerate}
+\item
+\label{step:dc-only-idct}
+If $\bitvar{NCOEFFS}[\locvar{\bi}]$ is less than 2:
+\begin{enumerate}
+\item
+Using \bitvar{ACSCALE}, \bitvar{DCSCALE}, \bitvar{BMS}, \bitvar{NQRS}, \\
+ \bitvar{QRSIZES}, \bitvar{QRBMIS}, \locvar{\qti}, \locvar{\pli}, and
+ \locvar{\idx{qi0}}, use the procedure given in Section~\ref{sub:quant-mat} to
+ compute the DC quantization matrix \locvar{QMAT}.
+\item
+Assign \locvar{DC} the value
+\begin{equation*}
+ (\bitvar{COEFFS}[\bitvar{\bi}][0]*\locvar{QMAT}[0]+15)>>5.
+\end{equation*}
+\item
+Truncate \locvar{DC} to a 16-bit signed representation by dropping any
+ higher-order bits.
+\item
+For each value of \locvar{\idx{by}} from 0 to 7, and each value of
+ \locvar{\idx{bx}} from 0 to 7, assign
+ $\locvar{RES}[\locvar{\idx{by}}][\locvar{\idx{bx}}]$ the value \locvar{DC}.
+\end{enumerate}
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Assign \locvar{\qi} the value $\bitvar{QIS}[\bitvar{QIIS}[\locvar{\bi}]]$.
+\item
+Using \bitvar{ACSCALE}, \bitvar{DCSCALE}, \bitvar{BMS}, \bitvar{NQRS}, \\
+ \bitvar{QRSIZES}, \bitvar{QRBMIS}, \locvar{\qti}, \locvar{\pli},
+ \locvar{\idx{qi0}}, and \locvar{\qi}, compute \locvar{DQC} using the procedure
+ given in Section~\ref{sub:dequant}.
+\item
+Using \locvar{DQC}, compute \locvar{RES} using the procedure given in
+ Section~\ref{sub:2d-idct}.
+\end{enumerate}
+\end{enumerate}
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Assign \locvar{\rfi} the value 1.
+\item
+Assign \locvar{REFP}, \locvar{RPW}, and \locvar{RPH} the values given in
+ Table~\ref{tab:refp} corresponding to current value of \locvar{\rfi} and
+ \locvar{\pli}.
+\item
+Assign \locvar{MVX} the value 0.
+\item
+Assign \locvar{MVY} the value 0.
+\item
+Using the values \locvar{REFP}, \locvar{RPW}, \locvar{RPH}, \locvar{BX},
+ \locvar{BY}, \locvar{MVX}, and \locvar{MVY}, compute \locvar{PRED} using the
+ procedure given in Section~\ref{sub:predfullpel}.
+This is simply a copy of the co-located block in the previous reference frame.
+\item
+For each value of \locvar{\idx{by}} from 0 to 7, and each value of
+ \locvar{\idx{bx}} from 0 to 7, assign
+ $\locvar{RES}[\locvar{\idx{by}}][\locvar{\idx{bx}}]$ the value 0.
+\end{enumerate}
+\item
+For each value of \locvar{\idx{by}} from 0 to 7, and each value of
+ \locvar{\idx{bx}} from 0 to 7:
+\begin{enumerate}
+\item
+Assign \locvar{P} the value
+ $(\locvar{PRED}[\locvar{\idx{by}}][\locvar{\idx{bx}}]+
+ \locvar{RES}[\locvar{\idx{by}}][\locvar{\idx{bx}}])$.
+\item
+If \locvar{P} is greater than $255$, assign \locvar{P} the value $255$.
+\item
+If \locvar{P} is less than $0$, assign \locvar{P} the value $0$.
+\item
+If \locvar{\pli} equals 0, assign
+ $\bitvar{RECY}[\locvar{BY}+\locvar{\idx{by}}][\locvar{BX}+\locvar{\idx{bx}}]$
+ the value \locvar{P}.
+\item
+Otherwise, if \locvar{\pli} equals 1, assign
+ $\bitvar{RECB}[\locvar{BY}+\locvar{\idx{by}}][\locvar{BX}+\locvar{\idx{bx}}]$
+ the value \locvar{P}.
+\item
+Otherwise, \locvar{\pli} equals 2, so assign
+ $\bitvar{RECR}[\locvar{BY}+\locvar{\idx{by}}][\locvar{BX}+\locvar{\idx{bx}}]$
+ the value \locvar{P}.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\section{Loop Filtering}
+\label{sec:loopfilter}
+
+\begin{figure}[htbp]
+\begin{center}
+\includegraphics{lflim}
+\end{center}
+\caption{The loop filter response function.}
+\label{fig:lflim}
+\end{figure}
+
+The loop filter is a simple deblocking filter that is based on running a small
+ edge detecting filter over the coded block edges and adjusting the pixel
+ values by a tapered response.
+The filter response is modulated by the following non-linear function:
+\begin{align*}
+\lflim(\locvar{R},\bitvar{L})&=\left\{\begin{array}{ll}
+0, & \locvar{R}\le-2*\bitvar{L} \\
+-\locvar{R}-2*\bitvar{L}, & -2*\bitvar{L}<\locvar{R}\le-\bitvar{L} \\
+\locvar{R}, & -\bitvar{L}<\locvar{R}<\bitvar{L} \\
+-\locvar{R}+2*\bitvar{L}, & \bitvar{L}\le\locvar{R}<2*\bitvar{L} \\
+0, & 2*\bitvar{L}\le\locvar{R}
+\end{array}\right.
+\end{align*}
+Here \bitvar{L} is a limiting value equal to $\bitvar{LFLIMS}[\idx{qi0}]$.
+It defines the peaks of the function, illustrated in Figure~\ref{fig:lflim}.
+\bitvar{LFLIMS} is an array of values specified in the setup header and is
+ indexed by \idx{qi0}, the first quantization index for the frame, the one used
+ for all the DC coefficients.
+Larger values of \bitvar{L} indicate a stronger filter.
+
+\subsection{Horizontal Filter}
+\label{sub:filth}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RECP} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPH}\times\bitvar{RPW}$
+ array containing the contents of a plane of the reconstructed frame. \\
+\bitvar{FX} & Integer & 20 & No & The horizontal pixel index of the
+ lower-left corner of the area to be filtered. \\
+\bitvar{FY} & Integer & 20 & No & The vertical pixel index of the
+ lower-left corner of the area to be filtered. \\
+\bitvar{L} & Integer & 7 & No & The loop filter limit value. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RECP} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPH}\times\bitvar{RPW}$
+ array containing the contents of a plane of the reconstructed frame. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{R} & Integer & 9 & Yes & The edge detector response. \\
+\locvar{P} & Integer & 9 & Yes & A filtered pixel value. \\
+\locvar{\idx{by}} & Integer & 20 & No & The vertical pixel index in the
+ block. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure applies a $4$-tap horizontal filter to each row of a vertical
+ block edge.
+
+\begin{enumerate}
+\item
+For each value of \locvar{\idx{by}} from $0$ to $7$:
+\begin{enumerate}
+\item
+Assign \locvar{R} the value
+\begin{multline*}
+(\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}]-
+ 3*\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+1]+\\
+ 3*\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+2]-
+ \bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+3]+4)>>3
+\end{multline*}
+\item
+Assign \locvar{P} the value
+ $(\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+1]+
+ \lflim(\locvar{R},\bitvar{L}))$.
+\item
+If \locvar{P} is less than zero, assign
+ $\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+1]$ the value zero.
+\item
+Otherwise, if \locvar{P} is greater than $255$, assign
+ $\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+1]$ the value $255$.
+\item
+Otherwise, assign
+ $\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+1]$ the value
+ \locvar{P}.
+\item
+Assign \locvar{P} the value
+ $(\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+2]-
+ \lflim(\locvar{R},\bitvar{L}))$.
+\item
+If \locvar{P} is less than zero, assign
+ $\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+2]$ the value zero.
+\item
+Otherwise, if \locvar{P} is greater than $255$, assign
+ $\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+2]$ the value $255$.
+\item
+Otherwise, assign
+ $\bitvar{RECP}[\bitvar{FY}+\locvar{\idx{by}}][\bitvar{FX}+2]$ the value
+ \locvar{P}.
+\end{enumerate}
+\end{enumerate}
+
+\subsection{Vertical Filter}
+\label{sub:filtv}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RECP} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPH}\times\bitvar{RPW}$
+ array containing the contents of a plane of the reconstructed frame. \\
+\bitvar{FX} & Integer & 20 & No & The horizontal pixel index of the
+ lower-left corner of the area to be filtered. \\
+\bitvar{FY} & Integer & 20 & No & The vertical pixel index of the
+ lower-left corner of the area to be filtered. \\
+\bitvar{L} & Integer & 7 & No & The loop filter limit value. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RECP} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPH}\times\bitvar{RPW}$
+ array containing the contents of a plane of the reconstructed frame. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{R} & Integer & 9 & Yes & The edge detector response. \\
+\locvar{P} & Integer & 9 & Yes & A filtered pixel value. \\
+\locvar{\idx{bx}} & Integer & 20 & No & The horizontal pixel index in the
+ block. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure applies a $4$-tap vertical filter to each column of a horizontal
+ block edge.
+
+\begin{enumerate}
+\item
+For each value of \locvar{\idx{bx}} from $0$ to $7$:
+\begin{enumerate}
+\item
+Assign \locvar{R} the value
+\begin{multline*}
+(\bitvar{RECP}[\bitvar{FY}][\bitvar{FX}+\locvar{\idx{bx}}]-
+ 3*\bitvar{RECP}[\bitvar{FY}+1][\bitvar{FX}+\locvar{\idx{bx}}]+\\
+ 3*\bitvar{RECP}[\bitvar{FY}+2][\bitvar{FX}+\locvar{\idx{bx}}]-
+ \bitvar{RECP}[\bitvar{FY}+3][\bitvar{FX}+\locvar{\idx{bx}}]+4)>>3
+\end{multline*}
+\item
+Assign \locvar{P} the value
+ $(\bitvar{RECP}[\bitvar{FY}+1][\bitvar{FX}+\locvar{\idx{bx}}]+
+ \lflim(\locvar{R},\bitvar{L}))$.
+\item
+If \locvar{P} is less than zero, assign
+ $\bitvar{RECP}[\bitvar{FY}+1][\bitvar{FX}+\locvar{\idx{bx}}]$ the value zero.
+\item
+Otherwise, if \locvar{P} is greater than $255$, assign
+ $\bitvar{RECP}[\bitvar{FY}+1][\bitvar{FX}+\locvar{\idx{bx}}]$ the value $255$.
+\item
+Otherwise, assign
+ $\bitvar{RECP}[\bitvar{FY}+1][\bitvar{FX}+\locvar{\idx{bx}}]$ the value
+ \locvar{P}.
+\item
+Assign \locvar{P} the value
+ $(\bitvar{RECP}[\bitvar{FY}+2][\bitvar{FX}+\locvar{\idx{bx}}]-
+ \lflim(\locvar{R},\bitvar{L}))$.
+\item
+If \locvar{P} is less than zero, assign
+ $\bitvar{RECP}[\bitvar{FY}+2][\bitvar{FX}+\locvar{\idx{bx}}]$ the value zero.
+\item
+Otherwise, if \locvar{P} is greater than $255$, assign
+ $\bitvar{RECP}[\bitvar{FY}+2][\bitvar{FX}+\locvar{\idx{bx}}]$ the value $255$.
+\item
+Otherwise, assign
+ $\bitvar{RECP}[\bitvar{FY}+2][\bitvar{FX}+\locvar{\idx{bx}}]$ the value
+ \locvar{P}.
+\end{enumerate}
+\end{enumerate}
+
+\subsection{Complete Loop Filter}
+\label{sub:loop-filt}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{LFLIMS} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 7 & No & A 64-element array of loop filter limit
+ values. \\
+\bitvar{RPYW} & Integer & 20 & No & The width of the $Y'$ plane of the
+ reconstruced frame in pixels. \\
+\bitvar{RPYH} & Integer & 20 & No & The height of the $Y'$ plane of the
+ reconstruced frame in pixels. \\
+\bitvar{RPCW} & Integer & 20 & No & The width of the $C_b$ and $C_r$
+ planes of the reconstruced frame in pixels. \\
+\bitvar{RPCH} & Integer & 20 & No & The height of the $C_b$ and $C_r$
+ planes of the reconstruced frame in pixels. \\
+\bitvar{NBS} & Integer & 36 & No & The total number of blocks in a
+ frame. \\
+\bitvar{BCODED} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 1 & No & An \bitvar{NBS}-element array of
+ flags indicating which blocks are coded. \\
+\bitvar{QIS} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 6 & No & An \bitvar{NQIS}-element array of
+ \qi\ values. \\
+\bitvar{RECY} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the reconstructed frame. \\
+\bitvar{RECCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the reconstructed frame. \\
+\bitvar{RECCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the reconstructed frame. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RECY} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the reconstructed frame. \\
+\bitvar{RECCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the reconstructed frame. \\
+\bitvar{RECCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the reconstructed frame. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{RPW} & Integer & 20 & No & The width of the current plane of the
+ reconstructed frame in pixels. \\
+\locvar{RPH} & Integer & 20 & No & The height of the current plane of
+ the reconstructed frame in pixels. \\
+\locvar{RECP} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPH}\times\bitvar{RPW}$
+ array containing the contents of the current plane of the reconstruced
+ frame. \\
+\locvar{BX} & Integer & 20 & No & The horizontal pixel index of the
+ lower-left corner of the current block. \\
+\locvar{BY} & Integer & 20 & No & The vertical pixel index of the
+ lower-left corner of the current block. \\
+\locvar{FX} & Integer & 20 & No & The horizontal pixel index of the
+ lower-left corner of the area to be filtered. \\
+\locvar{FY} & Integer & 20 & No & The vertical pixel index of the
+ lower-left corner of the area to be filtered. \\
+\locvar{L} & Integer & 7 & No & The loop filter limit value. \\
+\locvar{\bi} & Integer & 36 & No & The index of the current block in
+ coded order. \\
+\locvar{\bj} & Integer & 36 & No & The index of a neighboring block in
+ coded order. \\
+\locvar{\pli} & Integer & 2 & No & The color plane index of the current
+ block. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure defines the order that the various block edges are filtered.
+Because each application of one of the two filters above destructively modifies
+ the contents of the reconstructed image, the precise output obtained differs
+ depending on the order that horizontal and vertical filters are applied to the
+ edges of a single block.
+The order defined here conforms to that used by VP3.
+
+\begin{enumerate}
+\item
+Assign \locvar{L} the value $\bitvar{LFLIMS}[\bitvar{QIS}[0]]$.
+\item
+For each block in {\em raster} order, with coded-order index \locvar{\bi}:
+\begin{enumerate}
+\item
+If $\bitvar{BCODED}[\locvar{\bi}]$ is non-zero:
+\begin{enumerate}
+\item
+Assign \locvar{\pli} the index of the color plane block \locvar{\bi} belongs
+ to.
+\item
+Assign \locvar{RECP}, \locvar{RPW}, and \locvar{RPH} the values given in
+ Table~\ref{tab:recp} corresponding to the value of \locvar{\pli}.
+
+\begin{table}[htbp]
+\begin{center}
+\begin{tabular}{clll}\toprule
+\locvar{\pli} & \locvar{RECP} & \locvar{RPW} & \locvar{RPH} \\\midrule
+$0$ & \bitvar{RECY} & \bitvar{RPYW} & \bitvar{RPYH} \\
+$1$ & \bitvar{RECCB} & \bitvar{RPCW} & \bitvar{RPCH} \\
+$2$ & \bitvar{RECCR} & \bitvar{RPCW} & \bitvar{RPCH} \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Reconstructed Planes and Sizes for Each \locvar{\pli}}
+\label{tab:recp}
+\end{table}
+
+\item
+Assign \locvar{BX} the horizontal pixel index of the lower-left corner of the
+ block \locvar{\bi}.
+\item
+Assign \locvar{BY} the vertical pixel index of the lower-left corner of the
+ block \locvar{\bi}.
+\item
+If \locvar{BX} is greater than zero:
+\begin{enumerate}
+\item
+Assign \locvar{FX} the value $(\locvar{BX}-2)$.
+\item
+Assign \locvar{FY} the value \locvar{BY}.
+\item
+Using \locvar{RECP}, \locvar{FX}, \locvar{FY}, and \locvar{L}, apply the
+ horizontal block filter to the left edge of block \locvar{\bi} with the
+ procedure described in Section~\ref{sub:filth}.
+\end{enumerate}
+\item
+If \locvar{BY} is greater than zero:
+\begin{enumerate}
+\item
+Assign \locvar{FX} the value \locvar{BX}.
+\item
+Assign \locvar{FY} the value $(\locvar{BY}-2)$
+\item
+Using \locvar{RECP}, \locvar{FX}, \locvar{FY}, and \locvar{L}, apply the
+ vertical block filter to the bottom edge of block \locvar{\bi} with the
+ procedure described in Section~\ref{sub:filtv}.
+\end{enumerate}
+\item
+If $(\locvar{BX}+8)$ is less than \locvar{RPW} and
+ $\bitvar{BCODED}[\locvar{\bj}]$ is zero, where \locvar{\bj} is the coded-order
+ index of the block adjacent to \locvar{\bi} on the right:
+\begin{enumerate}
+\item
+Assign \locvar{FX} the value $(\locvar{BX}+6)$.
+\item
+Assign \locvar{FY} the value \locvar{BY}.
+\item
+Using \locvar{RECP}, \locvar{FX}, \locvar{FY}, and \locvar{L}, apply the
+ horizontal block filter to the right edge of block \locvar{\bi} with the
+ procedure described in Section~\ref{sub:filth}.
+\end{enumerate}
+\item
+If $(\locvar{BY}+8)$ is less than \locvar{RPH} and
+ $\bitvar{BCODED}[\locvar{\bj}]$ is zero, where \locvar{\bj} is the coded-order
+ index of the block adjacent to \locvar{\bi} above:
+\begin{enumerate}
+\item
+Assign \locvar{FX} the value \locvar{BX}.
+\item
+Assign \locvar{FY} the value $(\locvar{BY}+6)$
+\item
+Using \locvar{RECP}, \locvar{FX}, \locvar{FY}, and \locvar{L}, apply the
+ vertical block filter to the top edge of block \locvar{\bi} with the
+ procedure described in Section~\ref{sub:filtv}.
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+\end{enumerate}
+
+\paragraph{VP3 Compatibility}
+
+The original VP3 decoder implemented unrestricted motion vectors by enlarging
+ the reconstructed frame buffers and repeating the pixels on its edges into the
+ padding region.
+However, for the previous reference frame this padding ocurred before the loop
+ filter was applied, but for the golden reference frame it occurred afterwards.
+
+This means that for the previous reference frame, the padding values were
+ required to be stored separately from the main image values.
+Furthermore, even if the previous and golden reference frames were in fact the
+ same frame, they could have different padding values.
+Finally, the encoder did not apply the loop filter at all, which resulted in
+ artifacts, particularly in near-static scenes, due to prediction-loop
+ mismatch.
+This last can only be considered a bug in the VP3 encoder.
+
+Given all these things, Theora now uniformly applies the loop filter before
+ the reference frames are padded.
+This means it is possible to use the same buffer for the previous and golden
+ reference frames when they do indeed refer to the same frame.
+It also means that on architectures where memory bandwidth is limited, it is
+ possible to avoid storing padding values, and simply clamp the motion vectors
+ applied to each pixel as described in Sections~\ref{sub:predfullpel}
+ and~\ref{sub:predhalfpel}.
+This means that the predicted pixel values along the edges of the frame might
+ differ slightly between VP3 and Theora, but since the VP3 encoder did not
+ apply the loop filter in the first place, this is not likely to impose any
+ serious compatibility issues.
+
+\section{Complete Frame Decode}
+
+\paragraph{Input parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{FMBW} & Integer & 16 & No & The width of the frame in macro
+ blocks. \\
+\bitvar{FMBH} & Integer & 16 & No & The height of the frame in macro
+ blocks. \\
+\bitvar{NSBS} & Integer & 32 & No & The total number of super blocks in a
+ frame. \\
+\bitvar{NBS} & Integer & 36 & No & The total number of blocks in a
+ frame. \\
+\bitvar{NMBS} & Integer & 32 & No & The total number of macro blocks in a
+ frame. \\
+\bitvar{FRN} & Integer & 32 & No & The frame-rate numerator. \\
+\bitvar{FRD} & Integer & 32 & No & The frame-rate denominator. \\
+\bitvar{PARN} & Integer & 24 & No & The pixel aspect-ratio numerator. \\
+\bitvar{PARD} & Integer & 24 & No & The pixel aspect-ratio
+ denominator. \\
+\bitvar{CS} & Integer & 8 & No & The color space. \\
+\bitvar{PF} & Integer & 2 & No & The pixel format. \\
+\bitvar{NOMBR} & Integer & 24 & No & The nominal bitrate of the stream, in
+ bits per second. \\
+\bitvar{QUAL} & Integer & 6 & No & The quality hint. \\
+\bitvar{KFGSHIFT} & Integer & 5 & No & The amount to shift the key frame
+ number by in the granule position. \\
+\bitvar{LFLIMS} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 7 & No & A 64-element array of loop filter
+ limit values. \\
+\bitvar{ACSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 16 & No & A 64-element array of scale values
+ for AC coefficients for each \qi\ value. \\
+\bitvar{DCSCALE} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 16 & No & A 64-element array of scale values
+ for the DC coefficient for each \qi\ value. \\
+\bitvar{NBMS} & Integer & 10 & No & The number of base matrices. \\
+\bitvar{BMS} & \multicolumn{1}{p{50pt}}{2D Integer array} &
+ 8 & No & A $\bitvar{NBMS}\times 64$ array
+ containing the base matrices. \\
+\bitvar{NQRS} & \multicolumn{1}{p{50pt}}{2D Integer array} &
+ 6 & No & A $2\times 3$ array containing the
+ number of quant ranges for a given \qti\ and \pli, respectively.
+This is at most $63$. \\
+\bitvar{QRSIZES} & \multicolumn{1}{p{50pt}}{3D Integer array} &
+ 6 & No & A $2\times 3\times 63$ array of the
+ sizes of each quant range for a given \qti\ and \pli, respectively.
+Only the first $\bitvar{NQRS}[\qti][\pli]$ values will be used. \\
+\bitvar{QRBMIS} & \multicolumn{1}{p{50pt}}{3D Integer array} &
+ 9 & No & A $2\times 3\times 64$ array of the
+ \bmi's used for each quant range for a given \qti\ and \pli, respectively.
+Only the first $(\bitvar{NQRS}[\qti][\pli]+1)$ values will be used. \\
+\bitvar{HTS} & \multicolumn{3}{l}{Huffman table array}
+ & An 80-element array of Huffman tables
+ with up to 32 entries each. \\
+\bitvar{GOLDREFY} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the golden reference
+ frame. \\
+\bitvar{GOLDREFCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the golden reference
+ frame. \\
+\bitvar{GOLDREFCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the golden reference
+ frame. \\
+\bitvar{PREVREFY} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the previous reference
+ frame. \\
+\bitvar{PREVREFCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the previous reference
+ frame. \\
+\bitvar{PREVREFCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the previous reference
+ frame. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Output parameters:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\bitvar{RECY} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the reconstructed frame. \\
+\bitvar{RECCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the reconstructed
+ frame. \\
+\bitvar{RECCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the reconstructed
+ frame. \\
+\bitvar{GOLDREFY} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the golden reference
+ frame. \\
+\bitvar{GOLDREFCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the golden reference
+ frame. \\
+\bitvar{GOLDREFCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the golden reference
+ frame. \\
+\bitvar{PREVREFY} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPYH}\times\bitvar{RPYW}$
+ array containing the contents of the $Y'$ plane of the previous reference
+ frame. \\
+\bitvar{PREVREFCB} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_b$ plane of the previous reference
+ frame. \\
+\bitvar{PREVREFCR} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 8 & No & A $\bitvar{RPCH}\times\bitvar{RPCW}$
+ array containing the contents of the $C_r$ plane of the previous reference
+ frame. \\
+\bottomrule\end{tabularx}
+
+\paragraph{Variables used:}\hfill\\*
+\begin{tabularx}{\textwidth}{@{}llrcX@{}}\toprule
+\multicolumn{1}{c}{Name} &
+\multicolumn{1}{c}{Type} &
+\multicolumn{1}{p{30pt}}{\centering Size (bits)} &
+\multicolumn{1}{c}{Signed?} &
+\multicolumn{1}{c}{Description and restrictions} \\\midrule\endhead
+\locvar{FTYPE} & Integer & 1 & No & The frame type. \\
+\locvar{NQIS} & Integer & 2 & No & The number of \qi\ values. \\
+\locvar{QIS} & \multicolumn{1}{p{40pt}}{Integer array} &
+ 6 & No & An \locvar{NQIS}-element array of
+ \qi\ values. \\
+\locvar{BCODED} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 1 & No & An \bitvar{NBS}-element array of flags
+ indicating which blocks are coded. \\
+\locvar{MBMODES} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 3 & No & An \bitvar{NMBS}-element array of
+ coding modes for each macro block. \\
+\locvar{MVECTS} & \multicolumn{1}{p{50pt}}{Array of 2D Integer Vectors} &
+ 6 & Yes & An \bitvar{NBS}-element array of motion
+ vectors for each block. \\
+\locvar{QIIS} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 2 & No & An \bitvar{NBS}-element array of
+ \locvar{\qii} values for each block. \\
+\locvar{COEFFS} & \multicolumn{1}{p{50pt}}{2D Integer Array} &
+ 16 & Yes & An $\bitvar{NBS}\times 64$ array of
+ quantized DCT coefficient values for each block in zig-zag order. \\
+\locvar{NCOEFFS} & \multicolumn{1}{p{40pt}}{Integer Array} &
+ 7 & No & An \bitvar{NBS}-element array of the
+ coefficient count for each block. \\
+\bitvar{RPYW} & Integer & 20 & No & The width of the $Y'$ plane of the
+ reference frames in pixels. \\
+\bitvar{RPYH} & Integer & 20 & No & The height of the $Y'$ plane of the
+ reference frames in pixels. \\
+\bitvar{RPCW} & Integer & 20 & No & The width of the $C_b$ and $C_r$
+ planes of the reference frames in pixels. \\
+\bitvar{RPCH} & Integer & 20 & No & The height of the $C_b$ and $C_r$
+ planes of the reference frames in pixels. \\
+\locvar{\bi} & Integer & 36 & No & The index of the current block in coded
+ order. \\
+\bottomrule\end{tabularx}
+\medskip
+
+This procedure uses all the procedures defined in the previous section of this
+ chapter to decode and reconstruct a complete frame.
+It takes as input values decoded from the headers, as well as the current
+ reference frames.
+As output, it gives the uncropped, reconstructed frame.
+This should be cropped to picture region before display.
+As a special case, a 0-byte packet is treated exactly like an inter frame with
+ no coded blocks.
+
+\begin{enumerate}
+\item
+If the size of the data packet is non-zero:
+\begin{enumerate}
+\item
+Decode the frame header values \locvar{FTYPE}, \locvar{NQIS}, and \locvar{QIS}
+ using the procedure given in Section~\ref{sub:frame-header}.
+\item
+Using \locvar{FTYPE}, \bitvar{NSBS}, and \bitvar{NBS}, decode the list of coded
+ block flags into \locvar{BCODED} using the procedure given in
+ Section~\ref{sub:coded-blocks}.
+\item
+Using \locvar{FTYPE}, \bitvar{NMBS}, \bitvar{NBS}, and \bitvar{BCODED}, decode
+ the macro block coding modes into \locvar{MBMODES} using the procedure given
+ in Section~\ref{sub:mb-modes}.
+\item
+If \locvar{FTYPE} is non-zero (inter frame), using \bitvar{PF}, \bitvar{NMBS},
+ \locvar{MBMODES}, \bitvar{NBS}, and \locvar{BCODED}, decode the motion vectors
+ into \locvar{MVECTS} using the procedure given in
+ Section~\ref{sub:mb-mv-decode}.
+\item
+Using \bitvar{NBS}, \locvar{BCODED}, and \locvar{NQIS}, decode the block-level
+ \qi\ values into \locvar{QIIS} using the procedure given in
+ Section~\ref{sub:block-qis}.
+\item
+Using \bitvar{NBS}, \bitvar{NMBS}, \locvar{BCODED}, and \bitvar{HTS}, decode
+ the DCT coefficients into \locvar{NCOEFFS} and \locvar{NCOEFFS} using the
+ procedure given in Section~\ref{sub:dct-coeffs}.
+\item
+Using \locvar{BCODED} and \locvar{MBMODES}, undo the DC prediction on the DC
+ coefficients stored in \locvar{COEFFS} using the procedure given in
+ Section~\ref{sub:dc-pred-undo}.
+\end{enumerate}
+\item
+Otherwise:
+\begin{enumerate}
+\item
+Assign \locvar{FTYPE} the value 1 (inter frame).
+\item
+Assign \locvar{NQIS} the value 1.
+\item
+Assign $\locvar{QIS}[0]$ the value 63.
+\item
+For each value of \locvar{\bi} from 0 to $(\bitvar{NBS}-1)$, assign
+ $\locvar{BCODED}[\locvar{\bi}]$ the value zero.
+\end{enumerate}
+\item
+Assign \locvar{RPYW} and \locvar{RPYH} the values $(16*\bitvar{FMBW})$ and
+ $(16*\bitvar{FMBH})$, respectively.
+\item
+Assign \locvar{RPCW} and \locvar{RPCH} the values from the row of
+ Table~\ref{tab:rpcwh-for-pf} corresponding to \bitvar{PF}.
+
+\begin{table}[tb]
+\begin{center}
+\begin{tabular}{crr}\toprule
+\bitvar{PF} & \multicolumn{1}{c}{\locvar{RPCW}}
+ & \multicolumn{1}{c}{\locvar{RPCH}} \\\midrule
+$0$ & $8*\bitvar{FMBW}$ & $8*\bitvar{FMBH}$ \\
+$2$ & $8*\bitvar{FMBW}$ & $16*\bitvar{FMBH}$ \\
+$3$ & $16*\bitvar{FMBW}$ & $16*\bitvar{FMBH}$ \\
+\bottomrule\end{tabular}
+\end{center}
+\caption{Width and Height of Chroma Planes for each Pixel Format}
+\label{tab:rpcwh-for-pf}
+\end{table}
+
+\item
+Using \bitvar{ACSCALE}, \bitvar{DCSCALE}, \bitvar{BMS}, \bitvar{NQRS},
+ \bitvar{QRSIZES}, \bitvar{QRBMIS}, \bitvar{NBS}, \locvar{BCODED},
+ \locvar{MBMODES}, \locvar{MVECTS}, \locvar{COEFFS}, \locvar{NCOEFFS},
+ \locvar{QIS}, \locvar{QIIS}, \locvar{RPYW}, \locvar{RPYH}, \locvar{RPCW},
+ \locvar{RPCH}, \bitvar{GOLDREFY}, \bitvar{GOLDREFCB}, \bitvar{GOLDREFCR},
+ \bitvar{PREVREFY}, \bitvar{PREVREFCB}, and \bitvar{PREVREFCR}, reconstruct the
+ complete frame into \bitvar{RECY}, \bitvar{RECCB}, and \bitvar{RECCR} using
+ the procedure given in Section~\ref{sub:recon}.
+\item
+Using \bitvar{LFLIMS}, \locvar{RPYW}, \locvar{RPYH}, \locvar{RPCW},
+ \locvar{RPCH}, \bitvar{NBS}, \locvar{BCODED}, and \locvar{QIS}, apply the loop
+ filter to the reconstructed frame in \bitvar{RECY}, \bitvar{RECCB}, and
+ \bitvar{RECCR} using the procedure given in Section~\ref{sub:loop-filt}.
+\item
+If \locvar{FTYPE} is zero (intra frame), assign \bitvar{GOLDREFY},
+ \bitvar{GOLDREFCB}, and \bitvar{GOLDREFCR} the values \bitvar{RECY},
+ \bitvar{RECCB}, and \bitvar{RECCR}, respectively.
+\item
+Assign \bitvar{PREVREFY}, \bitvar{PREVREFCB}, and \bitvar{PREVREFCR} the values
+ \bitvar{RECY}, \bitvar{RECCB}, and \bitvar{RECCR}, respectively.
+\end{enumerate}
+
+%\backmatter
+\appendix
+
+\chapter{Ogg Bitstream Encapsulation}
+\label{app:oggencapsulation}
+
+\section{Overview}
+
+This document specifies the embedding or encapsulation of Theora packets
+ in an Ogg transport stream.
+
+Ogg is a stream oriented wrapper for coded, linear time-based data.
+It provides syncronization, multiplexing, framing, error detection and
+ seeking landmarks for the decoder and complements the raw packet format
+ used by the Theora codec.
+
+This document assumes familiarity with the details of the Ogg standard.
+The Xiph.Org documentation provides an overview of the Ogg transport stream
+ format at \url{http://www.xiph.org/ogg/doc/oggstream.html} and a detailed
+ description at \url{http://www.xiph.org/ogg/doc/framing.html}.
+The format is also defined in RFC~3533 \cite{rfc3533}.
+While Theora packets can be embedded in a wide variety of media
+ containers and streaming mechanisms, the Xiph.Org Foundation
+ recommends Ogg as the native format for Theora video in file-oriented
+ storage and transmission contexts.
+
+\subsection{MIME type}
+
+The generic MIME type of any Ogg file is {\tt application/ogg}.
+The specific MIME type for the Ogg Theora profile documented here
+is {\tt video/ogg}. This is the MIME type recommended for files
+conforming to this appendix. The recommended filename extension
+is {\tt .ogv}.
+
+Outside of an encapsulation, the mime type {\tt video/theora} may
+ be used to refer specifically to the Theora compressed video stream.
+
+\section{Embedding in a logical bitstream}
+
+Ogg separates the concept of a {\em logical bitstream} consisting of the
+ framing of a particular sequence of packets and complete within itself
+ from the {\em physical bitstream} which may consist either of a single
+ logical bitstream or a number of logical bitstreams multiplexed
+ together.
+This section specifies the embedding of Theora packets in a logical Ogg
+ bitstream.
+The mapping of Ogg Theora logical bitstreams into a multiplexed physical Ogg
+ stream is described in the next section.
+
+\subsection{Headers}
+
+The initial identification header packet appears by itself in a
+ single Ogg page.
+This page defines the start of the logical stream and MUST have
+ the `beginning of stream' flag set.
+
+The second and third header packets (comment metadata and decoder
+ setup data) can together span one or more Ogg pages.
+If there are additional non-normative header packets, they MUST be
+ included in this sequence of pages as well.
+The comment header packet MUST begin the second Ogg page in the logical
+ bitstream, and there MUST be a page break between the last header
+ packet and the first frame data packet.
+
+These two page break requirements facilitate stream identification and
+ simplify header acquisition for seeking and live streaming applications.
+
+All header pages MUST have their granule position field set to zero.
+
+\subsection{Frame data}
+
+The first frame data packet in a logical bitstream MUST begin a new Ogg
+ page.
+All other data packets are placed one at a time into Ogg pages
+ until the end of the stream.
+Packets can span pages and multiple packets can be placed within any
+ one page.
+The last page in the logical bitstream SHOULD have its
+ 'end of stream' flag set to indicate complete transmission
+ of the available video.
+
+Frame data pages MUST be marked with a granule position corresponding to
+ the end of the display interval of the last frame/packet that finishes
+ in that page. See the next section for details.
+
+\subsection{Granule position}
+
+Data packets are marked by a granulepos derived from the count of decodable
+frames after that packet is processed. The field itself is divided into two
+sections, the width of the less significant section being given by the KFGSHIFT
+parameter decoded from the identification header
+(Section~\ref{sec:idheader}).
+The more significant portion of the field gives the count of coded
+frames after the coding of the last keyframe in stream, and the less
+significant portion gives the count of frames since the last keyframe.
+Thus a stream would begin with a split granulepos of $1|0$ (a keyframe),
+followed by $1|1$, $1|2$, $1|3$, etc. Around a keyframe in the
+middle of the stream the granulepos sequence might be $1234|35$,
+$1234|36$, $1234|37$, $1271|0$ (for the keyframe), $1271|1$, and so
+on. In this way the granulepos field increased monotonically as required
+by the Ogg format, but contains information necessary to efficiently
+find the previous keyframe to continue decoding after a seek.
+
+Prior to bitstream version 3.2.1, data packets were marked by a
+granulepos derived from the index of the frame being decoded,
+rather than the count. That is they marked the beginning of the
+display interval of a frame rather than the end. Such streams
+have the VREV field of the identification header set to `0'
+instead of `1'. They can be interpreted according to the description
+above by adding 1 to the more signification field of the split
+granulepos when VREV is less than 1.
+
+\section{Multiplexed stream mapping}
+
+Applications supporting Ogg Theora must support Theora bitstreams
+ multiplexed with compressed audio data in the Vorbis I and Speex
+ formats, and should support Ogg-encapsulated MNG graphics for overlays.
+
+Multiple audio and video bitstreams may be multiplexed together.
+How playback of multiple/alternate streams is handled is up to the
+ application.
+Some conventions based on included metadata aide interoperability
+ in this respect.
+%TODO: describe multiple vs. alternate streams, language mapping
+% and reference metadata descriptions.
+
+\subsection{Chained streams}
+
+Ogg Theora decoders and playback applications MUST support both grouped
+ streams (multiplexed concurrent logical streams) and chained streams
+ (sequential concatenation of independent physical bitstreams).
+
+The number and codec data types of multiplexed streams and the decoder
+ parameters for those stream types that re-occur can all change at a
+ chaining boundary.
+A playback application MUST be prepared to handle such changes and
+ SHOULD do so smoothly with the minimum possible visible disruption.
+The specification of grouped streams below applies independently to each
+ segment of a chained bitstream.
+
+\subsection{Grouped streams}
+
+At the beginning of a multiplexed stream, the `beginning of stream'
+ pages for each logical bitstream will be grouped together.
+Within these, the first page to occur MUST be the Theora page.
+This facilitates identification of Ogg Theora files among other
+ Ogg-encapsulated content.
+A playback application must nevertheless handle streams where this
+ arrangement is not correct.
+%TBT: Then what's the point of requiring it in the spec?
+
+If there is more than one Theora logical stream, the first page should
+ be from the primary stream.
+That is, the best choice for the stream a generic player should begin
+ displaying without special user direction.
+If there is more than one audio stream, or of any other stream
+ type, the identification page of the primary stream of that type
+ should be placed before the others.
+%TBT: That's all pretty vague.
+
+After the `beginning of stream' pages, the header pages of each of
+ the logical streams MUST be grouped together before any data pages
+ occur.
+
+After all the header pages have been placed,
+ the data pages are multiplexed together.
+They should be placed in the stream in increasing order by the
+ time equivalents of their granule position fields.
+This facilitates seeking while limiting the buffering requirements of the
+ playback demultiplexer.
+%TODO: A lot of this language is encoder-oriented.
+%TODO: We define a decoder-oriented specification.
+%TODO: The language should be changed to match.
+
+\cleardoublepage
+\chapter{VP3}
+
+\section{VP3 Compatibility}
+\label{app:vp3-compat}
+This section lists all of the encoder and decoder issues that may affect VP3
+ compatibly.
+Each is described in more detail in the text itself.
+This list is provided merely for reference.
+
+\begin{itemize}
+\item
+Bitstream headers (Section~\ref{sec:headers}).
+\begin{itemize}
+\item
+Identification header (Section~\ref{sec:idheader}).
+\begin{itemize}
+\item
+Non-multiple of 16 picture sizes.
+\item
+Standardized color spaces.
+\item
+Support for $4:4:4$ and $4:2:2$ pixel formats.
+\end{itemize}
+\item
+Setup header
+\begin{itemize}
+\item
+Loop filter limit values (Section~\ref{sub:loop-filter-limits}).
+\item
+Quantization parameters (Section~\ref{sub:quant-params}).
+\item
+Huffman tables (Section~\ref{sub:huffman-tables}).
+\end{itemize}
+\end{itemize}
+\item
+Frame header format (Section~\ref{sub:frame-header}).
+\item
+Extended long-run bit strings (Section~\ref{sub:long-run}).
+\item
+INTER\_MV\_FOUR handling of uncoded blocks (Section~\ref{sub:mb-mv-decode}).
+\item
+Block-level \qi\ values (Section~\ref{sub:block-qis}).
+\item
+Zero-length EOB runs (Section~\ref{sub:eob-token}).
+\item
+Unrestricted motion vector padding and the loop filter
+ (Section~\ref{sub:loop-filt}).
+\end{itemize}
+
+\section{Loop Filter Limit Values}
+\label{app:vp3-loop-filter-limits}
+
+The hard-coded loop filter limit values used in VP3 are defined as follows:
+\begin{align*}
+\bitvar{LFLIMS} = & \begin{array}[t]{r@{}rrrrrrrr@{}l}
+\{ & 30, & 25, & 20, & 20, & 15, & 15, & 14, & 14, & \\
+ & 13, & 13, & 12, & 12, & 11, & 11, & 10, & 10, & \\
+ & 9, & 9, & 8, & 8, & 7, & 7, & 7, & 7, & \\
+ & 6, & 6, & 6, & 6, & 5, & 5, & 5, & 5, & \\
+ & 4, & 4, & 4, & 4, & 3, & 3, & 3, & 3, & \\
+ & 2, & 2, & 2, & 2, & 2, & 2, & 2, & 2, & \\
+ & 0, & 0, & 0, & 0, & 0, & 0, & 0, & 0, & \\
+ & 0, & 0, & 0, & 0, & 0, & 0, & 0, & 0\;\ & \!\} \\
+\end{array}
+\end{align*}
+
+\section{Quantization Parameters}
+\label{app:vp3-quant-params}
+
+The hard-coded quantization parameters used by VP3 are defined as follows:
+
+\begin{align*}
+\bitvar{ACSCALE} = & \begin{array}[t]{r@{}rrrrrrrr@{}l}
+\{ & 500, & 450, & 400, & 370, & 340, & 310, & 285, & 265, & \\
+ & 245, & 225, & 210, & 195, & 185, & 180, & 170, & 160, & \\
+ & 150, & 145, & 135, & 130, & 125, & 115, & 110, & 107, & \\
+ & 100, & 96, & 93, & 89, & 85, & 82, & 75, & 74, & \\
+ & 70, & 68, & 64, & 60, & 57, & 56, & 52, & 50, & \\
+ & 49, & 45, & 44, & 43, & 40, & 38, & 37, & 35, & \\
+ & 33, & 32, & 30, & 29, & 28, & 25, & 24, & 22, & \\
+ & 21, & 19, & 18, & 17, & 15, & 13, & 12, & 10\;\ & \!\} \\
+\end{array} \\
+\bitvar{DCSCALE} = & \begin{array}[t]{r@{}rrrrrrrr@{}l}
+\{ & 220, & 200, & 190, & 180, & 170, & 170, & 160, & 160, & \\
+ & 150, & 150, & 140, & 140, & 130, & 130, & 120, & 120, & \\
+ & 110, & 110, & 100, & 100, & 90, & 90, & 90, & 80, & \\
+ & 80, & 80, & 70, & 70, & 70, & 60, & 60, & 60, & \\
+ & 60, & 50, & 50, & 50, & 50, & 40, & 40, & 40, & \\
+ & 40, & 40, & 30, & 30, & 30, & 30, & 30, & 30, & \\
+ & 30, & 20, & 20, & 20, & 20, & 20, & 20, & 20, & \\
+ & 20, & 10, & 10, & 10, & 10, & 10, & 10, & 10\;\ & \!\} \\
+\end{array}
+\end{align*}
+
+VP3 defines only a single quantization range for each quantization type and
+ color plane, and the base matrix used is constant throughout the range.
+There are three base matrices defined.
+The first is used for the $Y'$ channel of INTRA mode blocks, and the second for
+ both the $C_b$ and $C_r$ channels of INTRA mode blocks.
+The last is used for INTER mode blocks of all channels.
+
+\begin{align*}
+\bitvar{BMS} = \{ & \begin{array}[t]{r@{}rrrrrrrr@{}l}
+\{ & 16, & 11, & 10, & 16, & 24, & 40, & 51, & 61, & \\
+ & 12, & 12, & 14, & 19, & 26, & 58, & 60, & 55, & \\
+ & 14, & 13, & 16, & 24, & 40, & 57, & 69, & 56, & \\
+ & 14, & 17, & 22, & 29, & 51, & 87, & 80, & 62, & \\
+ & 18, & 22, & 37, & 58, & 68, & 109, & 103, & 77, & \\
+ & 24, & 35, & 55, & 64, & 81, & 104, & 113, & 92, & \\
+ & 49, & 64, & 78, & 87, & 103, & 121, & 120, & 101, & \\
+ & 72, & 92, & 95, & 98, & 112, & 100, & 103, & 99\;\ & \!\}, \\
+%\end{array} \\
+%& \begin{array}[t]{r@{}rrrrrrrr@{}l}
+\{ & 17, & 18, & 24, & 47, & 99, & 99, & 99, & 99, & \\
+ & 18, & 21, & 26, & 66, & 99, & 99, & 99, & 99, & \\
+ & 24, & 26, & 56, & 99, & 99, & 99, & 99, & 99, & \\
+ & 47, & 66, & 99, & 99, & 99, & 99, & 99, & 99, & \\
+ & 99, & 99, & 99, & 99, & 99, & 99, & 99, & 99, & \\
+ & 99, & 99, & 99, & 99, & 99, & 99, & 99, & 99, & \\
+ & 99, & 99, & 99, & 99, & 99, & 99, & 99, & 99, & \\
+ & 99, & 99, & 99, & 99, & 99, & 99, & 99, & 99\;\ & \!\}, \\
+%\end{array} \\
+%& \begin{array}[t]{r@{}rrrrrrrr@{}l}
+\{ & 16, & 16, & 16, & 20, & 24, & 28, & 32, & 40, & \\
+ & 16, & 16, & 20, & 24, & 28, & 32, & 40, & 48, & \\
+ & 16, & 20, & 24, & 28, & 32, & 40, & 48, & 64, & \\
+ & 20, & 24, & 28, & 32, & 40, & 48, & 64, & 64, & \\
+ & 24, & 28, & 32, & 40, & 48, & 64, & 64, & 64, & \\
+ & 28, & 32, & 40, & 48, & 64, & 64, & 64, & 96, & \\
+ & 32, & 40, & 48, & 64, & 64, & 64, & 96, & 128, & \\
+ & 40, & 48, & 64, & 64, & 64, & 96, & 128, & 128\;\ & \!\}\;\;\} \\
+\end{array}
+\end{align*}
+
+The remaining parameters simply assign these matrices to the proper quant
+ ranges.
+
+\begin{align*}
+\bitvar{NQRS} = & \{ \{1, 1, 1\}, \{1, 1, 1\} \} \\
+\bitvar{QRSIZES} = &
+ \{ \{ \{63\}, \{63\}, \{63\} \}, \{ \{63\}, \{63\}, \{63\} \} \} \\
+\bitvar{QRBMIS} = &
+ \{ \{ \{0, 0\}, \{1, 1\}, \{1, 1\} \}, \{ \{2, 2\}, \{2, 2\}, \{2, 2\} \} \} \\
+\end{align*}
+
+\section{Huffman Tables}
+\label{app:vp3-huffman-tables}
+
+The following tables contain the hard-coded Huffman codes used by VP3.
+There are 80 tables in all, each with a Huffman code for all 32 token values.
+The tokens are sorted by the most significant bits of their Huffman code.
+This is the same order in which they will be decoded from the setup header.
+
+\include{vp3huff}
+
+\cleardoublepage
+\chapter{Colophon}
+
+Ogg is a \href{http://www.xiph.org}{Xiph.Org Foundation} effort to protect
+ essential tenets of Internet multimedia from corporate hostage-taking; Open
+ Source is the net's greatest tool to keep everyone honest.
+See \href{http://www.xiph.org/about.html}{About the Xiph.Org Foundation} for
+ details.
+
+Ogg Theora is the first Ogg video codec.
+Anyone may freely use and distribute the Ogg and Theora specifications, whether
+ in private, public, or corporate capacity.
+However, the Xiph.Org Foundation and the Ogg project reserve the right to set
+ the Ogg Theora specification and certify specification compliance.
+
+Xiph.Org's Theora software codec implementation is distributed under a BSD-like
+ license.
+This does not restrict third parties from distributing independent
+ implementations of Theora software under other licenses.
+
+\begin{wrapfigure}{l}{0pt}
+\includegraphics[width=2.5cm]{xifish}
+\end{wrapfigure}
+
+These pages are Copyright \textcopyright{} 2004-2007 Xiph.Org Foundation.
+All rights reserved.
+Ogg, Theora, Vorbis, Xiph.Org Foundation and their logos are trademarks
+ (\texttrademark) of the \href{http://www.xiph.org}{Xiph.Org Foundation}.
+
+This document is set in \LaTeX.
+
+
+
+\cleardoublepage
+\bibliography{spec}
+
+\end{document}
diff --git a/libs/libtheora-1.1/doc/spec/superblock.fig b/libs/libtheora-1.1/doc/spec/superblock.fig
new file mode 100644
index 00000000..082c31f1
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/superblock.fig
@@ -0,0 +1,72 @@
+#FIG 3.2 Produced by xfig version 3.2.5-alpha4
+Landscape
+Center
+Metric
+A4
+100.00
+Single
+-2
+1200 2
+6 270 180 5905 4860
+6 387 3531 1542 4687
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 387 4687 675 4687 675 4397 387 4397 387 4687
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 675 4687 963 4687 963 4397 675 4397 675 4687
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 963 4687 1252 4687 1252 4397 963 4397 963 4687
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1252 4397 1542 4397 1542 4109 1252 4109 1252 4397
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 387 4397 675 4397 675 4109 387 4109 387 4397
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 387 4109 675 4109 675 3820 387 3820 387 4109
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 963 4109 1252 4109 1252 3820 963 3820 963 4109
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1252 4109 1542 4109 1542 3820 1252 3820 1252 4109
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1252 3820 1542 3820 1542 3531 1252 3531 1252 3820
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 675 3820 963 3820 963 3531 675 3531 675 3820
+-6
+6 387 3531 1542 4687
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1252 4687 1542 4687 1542 4397 1252 4397 1252 4687
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 963 4397 1252 4397 1252 4109 963 4109 963 4397
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 963 3820 1252 3820 1252 3531 963 3531 963 3820
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 387 3820 675 3820 675 3531 387 3531 387 3820
+-6
+6 357 3502 1570 4715
+6 675 3820 963 4397
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 675 4397 963 4397 963 4109 675 4109 675 4397
+2 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 675 4109 963 4109 963 3820 675 3820 675 4109
+-6
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 387 3531 1542 3531 1542 4687 387 4687 387 3531
+-6
+2 2 1 2 0 7 50 -1 -1 6.000 0 0 -1 0 0 5
+ 387 353 5876 353 5876 4687 387 4687 387 353
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1542 3531 2697 3531 2697 4687 1542 4687 1542 3531
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 2697 3531 3854 3531 3854 4687 2697 4687 2697 3531
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 387 2375 1542 2375 1542 3531 387 3531 387 2375
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 1542 2375 2697 2375 2697 3531 1542 3531 1542 2375
+2 2 0 2 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+ 387 1220 1542 1220 1542 2375 387 2375 387 1220
+4 0 0 50 -1 0 7 0.0000 4 125 270 270 4831 (0,0)\001
+4 0 0 50 -1 0 7 0.0000 4 96 367 473 297 Frame\001
+4 0 0 50 -1 0 7 0.0000 4 125 1002 501 3474 Super Block (4x4)\001
+4 0 0 50 -1 0 7 0.0000 4 96 203 415 4657 8x8\001
+4 0 0 50 -1 0 7 0.0000 4 96 318 357 4513 Block\001
+4 0 0 50 -1 0 13 0.0000 4 20 145 4085 4081 ...\001
+4 0 0 50 -1 0 13 4.7124 4 20 145 848 815 ...\001
+-6
diff --git a/libs/libtheora-1.1/doc/spec/vp3huff.c b/libs/libtheora-1.1/doc/spec/vp3huff.c
new file mode 100644
index 00000000..87c93b40
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/vp3huff.c
@@ -0,0 +1,918 @@
+/********************************************************************
+ * *
+ * THIS FILE IS PART OF THE OggTheora SOFTWARE CODEC SOURCE CODE. *
+ * USE, DISTRIBUTION AND REPRODUCTION OF THIS LIBRARY SOURCE IS *
+ * GOVERNED BY A BSD-STYLE SOURCE LICENSE INCLUDED WITH THIS SOURCE *
+ * IN 'COPYING'. PLEASE READ THESE TERMS BEFORE DISTRIBUTING. *
+ * *
+ * THE Theora SOURCE CODE IS COPYRIGHT (C) 2002-2007 *
+ * by the Xiph.Org Foundation http://www.xiph.org/ *
+ * *
+ ********************************************************************
+ function: dump the VP3.1 huffman tables in a form suitable for
+ inclusion in the spec.
+ last mod: $Id: vp3huff.c 14078 2007-10-31 21:24:44Z giles $
+
+ ********************************************************************/
+
+#include
+#include
+#include
+
+
+
+typedef struct{
+ unsigned long pattern;
+ int nbits;
+}theora_huff_code;
+
+
+
+/*The default Huffman codes used for VP3.1.
+ These tables were generated by /experimental/derf/theora-exp/tools/huffgen.c
+ using the same algorithm and sampled frequency counts used by VP3.*/
+const theora_huff_code TH_VP31_HUFF_CODES[80][32]={
+ {
+ {0x002D, 6},{0x0026, 7},{0x0166, 9},{0x004E, 8},
+ {0x02CE,10},{0x059E,11},{0x027D,11},{0x0008, 5},
+ {0x04F9,12},{0x000F, 4},{0x000E, 4},{0x001B, 5},
+ {0x0006, 4},{0x0008, 4},{0x0005, 4},{0x001A, 5},
+ {0x0015, 5},{0x0007, 4},{0x000C, 4},{0x0001, 3},
+ {0x0000, 3},{0x0009, 4},{0x0017, 5},{0x0029, 6},
+ {0x0028, 6},{0x00B2, 8},{0x04F8,12},{0x059F,11},
+ {0x009E, 9},{0x013F,10},{0x0012, 6},{0x0058, 7}
+ },
+ {
+ {0x0010, 5},{0x0047, 7},{0x01FF, 9},{0x008C, 8},
+ {0x03FC,10},{0x046A,11},{0x0469,11},{0x0022, 6},
+ {0x11A1,13},{0x000E, 4},{0x000D, 4},{0x0004, 4},
+ {0x0005, 4},{0x0009, 4},{0x0006, 4},{0x001E, 5},
+ {0x0016, 5},{0x0007, 4},{0x000C, 4},{0x0001, 3},
+ {0x0000, 3},{0x000A, 4},{0x0017, 5},{0x007D, 7},
+ {0x007E, 7},{0x011B, 9},{0x08D1,12},{0x03FD,10},
+ {0x046B,11},{0x11A0,13},{0x007C, 7},{0x00FE, 8}
+ },
+ {
+ {0x0016, 5},{0x0020, 6},{0x0086, 8},{0x0087, 8},
+ {0x0367,10},{0x06CC,11},{0x06CB,11},{0x006E, 7},
+ {0x366D,14},{0x000F, 4},{0x000E, 4},{0x0004, 4},
+ {0x0005, 4},{0x000A, 4},{0x0006, 4},{0x001A, 5},
+ {0x0011, 5},{0x0007, 4},{0x000C, 4},{0x0001, 3},
+ {0x0000, 3},{0x0009, 4},{0x0017, 5},{0x006F, 7},
+ {0x006D, 7},{0x0364,10},{0x0D9A,12},{0x06CA,11},
+ {0x1B37,13},{0x366C,14},{0x0042, 7},{0x00D8, 8}
+ },
+ {
+ {0x0000, 4},{0x002D, 6},{0x00F7, 8},{0x0058, 7},
+ {0x0167, 9},{0x02CB,10},{0x02CA,10},{0x000E, 6},
+ {0x1661,13},{0x0003, 3},{0x0002, 3},{0x0008, 4},
+ {0x0009, 4},{0x000D, 4},{0x0002, 4},{0x001F, 5},
+ {0x0017, 5},{0x0001, 4},{0x000C, 4},{0x000E, 4},
+ {0x000A, 4},{0x0006, 5},{0x0078, 7},{0x000F, 6},
+ {0x007A, 7},{0x0164, 9},{0x0599,11},{0x02CD,10},
+ {0x0B31,12},{0x1660,13},{0x0079, 7},{0x00F6, 8}
+ },
+ {
+ {0x0003, 4},{0x003C, 6},{0x000F, 7},{0x007A, 7},
+ {0x001D, 8},{0x0020, 9},{0x0072,10},{0x0006, 6},
+ {0x0399,13},{0x0004, 3},{0x0005, 3},{0x0005, 4},
+ {0x0006, 4},{0x000E, 4},{0x0004, 4},{0x0000, 4},
+ {0x0019, 5},{0x0002, 4},{0x000D, 4},{0x0007, 4},
+ {0x001F, 5},{0x0030, 6},{0x0011, 8},{0x0031, 6},
+ {0x0005, 6},{0x0021, 9},{0x00E7,11},{0x0038, 9},
+ {0x01CD,12},{0x0398,13},{0x007B, 7},{0x0009, 7}
+ },
+ {
+ {0x0009, 4},{0x0002, 5},{0x0074, 7},{0x0007, 6},
+ {0x00EC, 8},{0x00D1, 9},{0x01A6,10},{0x0006, 6},
+ {0x0D21,13},{0x0005, 3},{0x0006, 3},{0x0008, 4},
+ {0x0007, 4},{0x000F, 4},{0x0004, 4},{0x0000, 4},
+ {0x001C, 5},{0x0002, 4},{0x0005, 4},{0x0003, 4},
+ {0x000C, 5},{0x0035, 7},{0x01A7,10},{0x001B, 6},
+ {0x0077, 7},{0x01A5,10},{0x0349,11},{0x00D0, 9},
+ {0x0691,12},{0x0D20,13},{0x0075, 7},{0x00ED, 8}
+ },
+ {
+ {0x000A, 4},{0x000C, 5},{0x0012, 6},{0x001B, 6},
+ {0x00B7, 8},{0x016C, 9},{0x0099, 9},{0x005A, 7},
+ {0x16D8,13},{0x0007, 3},{0x0006, 3},{0x0009, 4},
+ {0x0008, 4},{0x0000, 3},{0x0005, 4},{0x0017, 5},
+ {0x000E, 5},{0x0002, 4},{0x0003, 4},{0x000F, 5},
+ {0x001A, 6},{0x004D, 8},{0x2DB3,14},{0x002C, 6},
+ {0x0011, 6},{0x02DA,10},{0x05B7,11},{0x0098, 9},
+ {0x0B6D,12},{0x2DB2,14},{0x0010, 6},{0x0027, 7}
+ },
+ {
+ {0x000D, 4},{0x000F, 5},{0x001D, 6},{0x0008, 5},
+ {0x0051, 7},{0x0056, 8},{0x00AF, 9},{0x002A, 7},
+ {0x148A,13},{0x0007, 3},{0x0000, 2},{0x0008, 4},
+ {0x0009, 4},{0x000C, 4},{0x0006, 4},{0x0017, 5},
+ {0x000B, 5},{0x0016, 5},{0x0015, 5},{0x0009, 5},
+ {0x0050, 7},{0x00AE, 9},{0x2917,14},{0x001C, 6},
+ {0x0014, 6},{0x0290,10},{0x0523,11},{0x0149, 9},
+ {0x0A44,12},{0x2916,14},{0x0053, 7},{0x00A5, 8}
+ },
+ {
+ {0x0001, 4},{0x001D, 6},{0x00F5, 8},{0x00F4, 8},
+ {0x024D,10},{0x0499,11},{0x0498,11},{0x0001, 5},
+ {0x0021, 6},{0x0006, 3},{0x0005, 3},{0x0006, 4},
+ {0x0005, 4},{0x0002, 4},{0x0007, 5},{0x0025, 6},
+ {0x007B, 7},{0x001C, 6},{0x0020, 6},{0x000D, 6},
+ {0x0048, 7},{0x0092, 8},{0x0127, 9},{0x000E, 4},
+ {0x0004, 4},{0x0011, 5},{0x000C, 6},{0x003C, 6},
+ {0x000F, 5},{0x0000, 5},{0x001F, 5},{0x0013, 5}
+ },
+ {
+ {0x0005, 4},{0x003C, 6},{0x0040, 7},{0x000D, 7},
+ {0x0031, 9},{0x0061,10},{0x0060,10},{0x0002, 5},
+ {0x00F5, 8},{0x0006, 3},{0x0005, 3},{0x0007, 4},
+ {0x0006, 4},{0x0002, 4},{0x0009, 5},{0x0025, 6},
+ {0x0007, 6},{0x0021, 6},{0x0024, 6},{0x0010, 6},
+ {0x0041, 7},{0x00F4, 8},{0x0019, 8},{0x000E, 4},
+ {0x0003, 4},{0x0011, 5},{0x0011, 6},{0x003F, 6},
+ {0x003E, 6},{0x007B, 7},{0x0000, 4},{0x0013, 5}
+ },
+ {
+ {0x000A, 4},{0x0007, 5},{0x0001, 6},{0x0009, 6},
+ {0x0131, 9},{0x0261,10},{0x0260,10},{0x0015, 6},
+ {0x0001, 7},{0x0007, 3},{0x0006, 3},{0x0008, 4},
+ {0x0007, 4},{0x0006, 4},{0x0012, 5},{0x002F, 6},
+ {0x0014, 6},{0x0027, 6},{0x002D, 6},{0x0016, 6},
+ {0x004D, 7},{0x0099, 8},{0x0000, 7},{0x0004, 4},
+ {0x0001, 4},{0x0005, 5},{0x0017, 6},{0x002E, 6},
+ {0x002C, 6},{0x0008, 6},{0x0006, 5},{0x0001, 5}
+ },
+ {
+ {0x0000, 3},{0x000E, 5},{0x0017, 6},{0x002A, 6},
+ {0x0010, 7},{0x00F9,10},{0x00F8,10},{0x001E, 7},
+ {0x003F, 8},{0x0007, 3},{0x0006, 3},{0x0009, 4},
+ {0x0008, 4},{0x0006, 4},{0x000F, 5},{0x0005, 5},
+ {0x0016, 6},{0x0029, 6},{0x002B, 6},{0x0015, 6},
+ {0x0050, 7},{0x0011, 7},{0x007D, 9},{0x0004, 4},
+ {0x0017, 5},{0x0006, 5},{0x0014, 6},{0x002C, 6},
+ {0x002D, 6},{0x000E, 6},{0x0009, 6},{0x0051, 7}
+ },
+ {
+ {0x0002, 3},{0x0018, 5},{0x002F, 6},{0x000D, 5},
+ {0x0053, 7},{0x0295,10},{0x0294,10},{0x00A4, 8},
+ {0x007C, 8},{0x0000, 2},{0x0007, 3},{0x0009, 4},
+ {0x0008, 4},{0x001B, 5},{0x000C, 5},{0x0028, 6},
+ {0x006A, 7},{0x001E, 6},{0x001D, 6},{0x0069, 7},
+ {0x00D7, 8},{0x007D, 8},{0x014B, 9},{0x0019, 5},
+ {0x0016, 5},{0x002E, 6},{0x001C, 6},{0x002B, 6},
+ {0x002A, 6},{0x0068, 7},{0x003F, 7},{0x00D6, 8}
+ },
+ {
+ {0x0002, 3},{0x001B, 5},{0x000C, 5},{0x0018, 5},
+ {0x0029, 6},{0x007F, 8},{0x02F0,10},{0x0198, 9},
+ {0x0179, 9},{0x0000, 2},{0x0007, 3},{0x0009, 4},
+ {0x0008, 4},{0x001A, 5},{0x000D, 5},{0x002A, 6},
+ {0x0064, 7},{0x001E, 6},{0x0067, 7},{0x005F, 7},
+ {0x00CD, 8},{0x007E, 8},{0x02F1,10},{0x0016, 5},
+ {0x000E, 5},{0x002E, 6},{0x0065, 7},{0x002B, 6},
+ {0x0028, 6},{0x003E, 7},{0x00BD, 8},{0x0199, 9}
+ },
+ {
+ {0x0002, 3},{0x0007, 4},{0x0016, 5},{0x0006, 4},
+ {0x0036, 6},{0x005C, 7},{0x015D, 9},{0x015C, 9},
+ {0x02BF,10},{0x0000, 2},{0x0007, 3},{0x0009, 4},
+ {0x0008, 4},{0x0018, 5},{0x0034, 6},{0x002A, 6},
+ {0x005E, 7},{0x006A, 7},{0x0064, 7},{0x005D, 7},
+ {0x00CB, 8},{0x00AD, 8},{0x02BE,10},{0x0014, 5},
+ {0x0033, 6},{0x006E, 7},{0x005F, 7},{0x006F, 7},
+ {0x006B, 7},{0x00CA, 8},{0x00AC, 8},{0x015E, 9}
+ },
+ {
+ {0x000F, 4},{0x001D, 5},{0x0018, 5},{0x000B, 4},
+ {0x0019, 5},{0x0029, 6},{0x00D6, 8},{0x0551,11},
+ {0x0AA1,12},{0x0001, 2},{0x0000, 2},{0x0009, 4},
+ {0x0008, 4},{0x001B, 5},{0x0038, 6},{0x0028, 6},
+ {0x0057, 7},{0x006A, 7},{0x0068, 7},{0x0056, 7},
+ {0x00E5, 8},{0x0155, 9},{0x0AA0,12},{0x0073, 7},
+ {0x0069, 7},{0x00D7, 8},{0x00AB, 8},{0x00E4, 8},
+ {0x00A9, 8},{0x0151, 9},{0x0150, 9},{0x02A9,10}
+ },
+ {
+ {0x0008, 5},{0x0025, 7},{0x017A, 9},{0x02F7,10},
+ {0x0BDB,12},{0x17B4,13},{0x2F6B,14},{0x001D, 5},
+ {0x2F6A,14},{0x0008, 4},{0x0007, 4},{0x0001, 4},
+ {0x0002, 4},{0x000A, 4},{0x0006, 4},{0x0000, 4},
+ {0x001C, 5},{0x0009, 4},{0x000D, 4},{0x000F, 4},
+ {0x000C, 4},{0x0003, 4},{0x000A, 5},{0x0016, 5},
+ {0x0013, 6},{0x005D, 7},{0x0024, 7},{0x00BC, 8},
+ {0x005C, 7},{0x05EC,11},{0x000B, 5},{0x005F, 7}
+ },
+ {
+ {0x000F, 5},{0x0010, 6},{0x004B, 8},{0x00C6, 8},
+ {0x031D,10},{0x0C71,12},{0x0C70,12},{0x0001, 4},
+ {0x0C73,12},{0x0008, 4},{0x0009, 4},{0x0002, 4},
+ {0x0003, 4},{0x000B, 4},{0x0006, 4},{0x0000, 4},
+ {0x001C, 5},{0x0005, 4},{0x000D, 4},{0x000F, 4},
+ {0x000A, 4},{0x0019, 5},{0x0013, 6},{0x001D, 5},
+ {0x0030, 6},{0x0062, 7},{0x0024, 7},{0x004A, 8},
+ {0x018F, 9},{0x0C72,12},{0x000E, 5},{0x0011, 6}
+ },
+ {
+ {0x001B, 5},{0x0003, 6},{0x008D, 8},{0x0040, 7},
+ {0x0239,10},{0x0471,11},{0x08E0,12},{0x0003, 4},
+ {0x11C3,13},{0x000A, 4},{0x0009, 4},{0x0004, 4},
+ {0x0005, 4},{0x000E, 4},{0x0007, 4},{0x0001, 4},
+ {0x001E, 5},{0x0006, 4},{0x000C, 4},{0x000B, 4},
+ {0x0002, 4},{0x0000, 5},{0x0041, 7},{0x001F, 5},
+ {0x0022, 6},{0x0002, 6},{0x008F, 8},{0x008C, 8},
+ {0x011D, 9},{0x11C2,13},{0x001A, 5},{0x0021, 6}
+ },
+ {
+ {0x001F, 5},{0x0003, 6},{0x0003, 7},{0x0043, 7},
+ {0x000B, 9},{0x0015,10},{0x0051,12},{0x0003, 4},
+ {0x0050,12},{0x000D, 4},{0x000C, 4},{0x0004, 4},
+ {0x0006, 4},{0x000E, 4},{0x000A, 4},{0x0001, 4},
+ {0x001E, 5},{0x0005, 4},{0x0009, 4},{0x0007, 4},
+ {0x0011, 5},{0x0002, 6},{0x0004, 8},{0x0002, 4},
+ {0x002D, 6},{0x0020, 6},{0x0042, 7},{0x0001, 7},
+ {0x0000, 7},{0x0029,11},{0x0017, 5},{0x002C, 6}
+ },
+ {
+ {0x0003, 4},{0x001F, 6},{0x003A, 7},{0x005D, 7},
+ {0x0173, 9},{0x02E4,10},{0x172D,13},{0x0004, 4},
+ {0x172C,13},{0x000F, 4},{0x000E, 4},{0x0009, 4},
+ {0x0008, 4},{0x000C, 4},{0x000A, 4},{0x0001, 4},
+ {0x0016, 5},{0x0002, 4},{0x0005, 4},{0x001A, 5},
+ {0x002F, 6},{0x0038, 7},{0x05CA,11},{0x0006, 4},
+ {0x0037, 6},{0x001E, 6},{0x003B, 7},{0x0039, 7},
+ {0x00B8, 8},{0x0B97,12},{0x0000, 4},{0x0036, 6}
+ },
+ {
+ {0x0006, 4},{0x0037, 6},{0x005D, 7},{0x000C, 6},
+ {0x00B9, 8},{0x02E3,10},{0x05C4,11},{0x0004, 4},
+ {0x1715,13},{0x0000, 3},{0x000F, 4},{0x0008, 4},
+ {0x0007, 4},{0x000C, 4},{0x0009, 4},{0x001D, 5},
+ {0x0016, 5},{0x001C, 5},{0x001A, 5},{0x000B, 5},
+ {0x005E, 7},{0x0170, 9},{0x1714,13},{0x000A, 4},
+ {0x000A, 5},{0x0036, 6},{0x005F, 7},{0x001B, 7},
+ {0x001A, 7},{0x0B8B,12},{0x0002, 4},{0x0007, 5}
+ },
+ {
+ {0x000C, 4},{0x000B, 5},{0x0079, 7},{0x0022, 6},
+ {0x00F0, 8},{0x0119, 9},{0x0230,10},{0x001D, 5},
+ {0x08C4,12},{0x0001, 3},{0x0000, 3},{0x000A, 4},
+ {0x0009, 4},{0x000B, 4},{0x0007, 4},{0x001C, 5},
+ {0x003D, 6},{0x000D, 5},{0x0008, 5},{0x0015, 6},
+ {0x008D, 8},{0x118B,13},{0x118A,13},{0x000D, 4},
+ {0x0010, 5},{0x0009, 5},{0x0014, 6},{0x0047, 7},
+ {0x00F1, 8},{0x0463,11},{0x001F, 5},{0x000C, 5}
+ },
+ {
+ {0x0000, 3},{0x001A, 5},{0x0033, 6},{0x000C, 5},
+ {0x0046, 7},{0x01E3, 9},{0x03C5,10},{0x0017, 5},
+ {0x1E21,13},{0x0002, 3},{0x0001, 3},{0x0009, 4},
+ {0x000A, 4},{0x0007, 4},{0x001B, 5},{0x003D, 6},
+ {0x001B, 6},{0x0022, 6},{0x0079, 7},{0x00F0, 8},
+ {0x1E20,13},{0x1E23,13},{0x1E22,13},{0x000E, 4},
+ {0x0016, 5},{0x0018, 5},{0x0032, 6},{0x001A, 6},
+ {0x0047, 7},{0x0789,11},{0x001F, 5},{0x0010, 5}
+ },
+ {
+ {0x001D, 5},{0x0061, 7},{0x004E, 8},{0x009E, 9},
+ {0x027C,11},{0x09F5,13},{0x09F4,13},{0x0003, 4},
+ {0x0060, 7},{0x0000, 3},{0x000F, 4},{0x000B, 4},
+ {0x000A, 4},{0x0009, 4},{0x0005, 4},{0x000D, 5},
+ {0x0031, 6},{0x0008, 5},{0x0038, 6},{0x0012, 6},
+ {0x0026, 7},{0x013F,10},{0x04FB,12},{0x000D, 4},
+ {0x0002, 4},{0x000C, 5},{0x0039, 6},{0x001C, 6},
+ {0x000F, 5},{0x001D, 6},{0x0008, 4},{0x0019, 5}
+ },
+ {
+ {0x0007, 4},{0x0019, 6},{0x00AB, 8},{0x00AA, 8},
+ {0x0119,10},{0x0461,12},{0x0460,12},{0x001B, 5},
+ {0x0047, 8},{0x0001, 3},{0x0000, 3},{0x000C, 4},
+ {0x000B, 4},{0x0009, 4},{0x0005, 4},{0x000D, 5},
+ {0x0035, 6},{0x003D, 6},{0x003C, 6},{0x0018, 6},
+ {0x0022, 7},{0x008D, 9},{0x0231,11},{0x000E, 4},
+ {0x001F, 5},{0x0009, 5},{0x002B, 6},{0x0010, 6},
+ {0x0034, 6},{0x0054, 7},{0x0008, 4},{0x0014, 5}
+ },
+ {
+ {0x000C, 4},{0x0005, 5},{0x0008, 6},{0x005B, 7},
+ {0x004D, 9},{0x0131,11},{0x0261,12},{0x001A, 5},
+ {0x0012, 7},{0x0000, 3},{0x000F, 4},{0x000A, 4},
+ {0x0009, 4},{0x0006, 4},{0x001B, 5},{0x0006, 5},
+ {0x001C, 6},{0x002C, 6},{0x0015, 6},{0x005A, 7},
+ {0x0027, 8},{0x0099,10},{0x0260,12},{0x000E, 4},
+ {0x0004, 4},{0x000F, 5},{0x0007, 5},{0x001D, 6},
+ {0x000B, 5},{0x0014, 6},{0x0008, 4},{0x0017, 5}
+ },
+ {
+ {0x000F, 4},{0x0013, 5},{0x0075, 7},{0x0024, 6},
+ {0x0095, 8},{0x0251,10},{0x04A0,11},{0x0010, 5},
+ {0x00C8, 8},{0x0002, 3},{0x0001, 3},{0x0001, 4},
+ {0x0000, 4},{0x001A, 5},{0x0011, 5},{0x002C, 6},
+ {0x0065, 7},{0x0074, 7},{0x004B, 7},{0x00C9, 8},
+ {0x0129, 9},{0x0943,12},{0x0942,12},{0x0003, 3},
+ {0x000A, 4},{0x001C, 5},{0x0018, 5},{0x0033, 6},
+ {0x0017, 5},{0x002D, 6},{0x001B, 5},{0x003B, 6}
+ },
+ {
+ {0x0003, 3},{0x001A, 5},{0x002D, 6},{0x0038, 6},
+ {0x0028, 7},{0x0395,10},{0x0E51,12},{0x0037, 6},
+ {0x00E4, 8},{0x0001, 3},{0x0000, 3},{0x001F, 5},
+ {0x001E, 5},{0x0017, 5},{0x003A, 6},{0x0073, 7},
+ {0x002A, 7},{0x002B, 7},{0x0029, 7},{0x01CB, 9},
+ {0x0729,11},{0x1CA1,13},{0x1CA0,13},{0x0004, 3},
+ {0x000A, 4},{0x0004, 4},{0x0018, 5},{0x0036, 6},
+ {0x000B, 5},{0x002C, 6},{0x0019, 5},{0x003B, 6}
+ },
+ {
+ {0x0004, 3},{0x0004, 4},{0x003F, 6},{0x0017, 5},
+ {0x0075, 7},{0x01F5, 9},{0x07D1,11},{0x0017, 6},
+ {0x01F6, 9},{0x0001, 3},{0x0000, 3},{0x001B, 5},
+ {0x001A, 5},{0x000A, 5},{0x0032, 6},{0x0074, 7},
+ {0x00F8, 8},{0x00F9, 8},{0x01F7, 9},{0x03E9,10},
+ {0x0FA0,12},{0x1F43,13},{0x1F42,13},{0x0003, 3},
+ {0x000A, 4},{0x001E, 5},{0x001C, 5},{0x003B, 6},
+ {0x0018, 5},{0x0016, 6},{0x0016, 5},{0x0033, 6}
+ },
+ {
+ {0x0004, 3},{0x0007, 4},{0x0018, 5},{0x001E, 5},
+ {0x0036, 6},{0x0031, 7},{0x0177, 9},{0x0077, 7},
+ {0x0176, 9},{0x0001, 3},{0x0000, 3},{0x001A, 5},
+ {0x0019, 5},{0x003A, 6},{0x0019, 6},{0x005C, 7},
+ {0x00BA, 8},{0x0061, 8},{0x00C1, 9},{0x0180,10},
+ {0x0302,11},{0x0607,12},{0x0606,12},{0x0002, 3},
+ {0x000A, 4},{0x001F, 5},{0x001C, 5},{0x0037, 6},
+ {0x0016, 5},{0x0076, 7},{0x000D, 5},{0x002F, 6}
+ },
+ {
+ {0x0000, 3},{0x000A, 4},{0x001A, 5},{0x000C, 4},
+ {0x001D, 5},{0x0039, 6},{0x0078, 7},{0x005E, 7},
+ {0x0393,11},{0x0002, 3},{0x0001, 3},{0x0016, 5},
+ {0x000F, 5},{0x002E, 6},{0x005F, 7},{0x0073, 8},
+ {0x00E5, 9},{0x01C8,10},{0x0E4A,13},{0x1C97,14},
+ {0x1C96,14},{0x0E49,13},{0x0E48,13},{0x0004, 3},
+ {0x0006, 4},{0x001F, 5},{0x001B, 5},{0x001D, 6},
+ {0x0038, 6},{0x0038, 7},{0x003D, 6},{0x0079, 7}
+ },
+ {
+ {0x000B, 5},{0x002B, 7},{0x0054, 8},{0x01B7, 9},
+ {0x06D9,11},{0x0DB1,12},{0x0DB0,12},{0x0002, 4},
+ {0x00AB, 9},{0x0009, 4},{0x000A, 4},{0x0007, 4},
+ {0x0008, 4},{0x000F, 4},{0x000C, 4},{0x0003, 4},
+ {0x001D, 5},{0x0004, 4},{0x000B, 4},{0x0006, 4},
+ {0x001A, 5},{0x0003, 6},{0x00AA, 9},{0x0001, 4},
+ {0x0000, 5},{0x0014, 6},{0x006C, 7},{0x00DA, 8},
+ {0x0002, 6},{0x036D,10},{0x001C, 5},{0x0037, 6}
+ },
+ {
+ {0x001D, 5},{0x0004, 6},{0x00B6, 8},{0x006A, 8},
+ {0x05B9,11},{0x16E1,13},{0x16E0,13},{0x0007, 4},
+ {0x016F, 9},{0x000C, 4},{0x000D, 4},{0x0009, 4},
+ {0x0008, 4},{0x000F, 4},{0x000A, 4},{0x0003, 4},
+ {0x0017, 5},{0x0002, 4},{0x0004, 4},{0x001C, 5},
+ {0x002C, 6},{0x006B, 8},{0x0B71,12},{0x0005, 4},
+ {0x0003, 5},{0x001B, 6},{0x005A, 7},{0x0034, 7},
+ {0x0005, 6},{0x02DD,10},{0x0000, 4},{0x000C, 5}
+ },
+ {
+ {0x0003, 4},{0x007F, 7},{0x00A1, 8},{0x00A0, 8},
+ {0x020C,10},{0x0834,12},{0x106B,13},{0x0007, 4},
+ {0x0082, 8},{0x000E, 4},{0x000D, 4},{0x000B, 4},
+ {0x000C, 4},{0x0000, 3},{0x0009, 4},{0x0002, 4},
+ {0x0011, 5},{0x001E, 5},{0x0015, 5},{0x003E, 6},
+ {0x0040, 7},{0x041B,11},{0x106A,13},{0x0006, 4},
+ {0x000A, 5},{0x0029, 6},{0x007E, 7},{0x0051, 7},
+ {0x0021, 6},{0x0107, 9},{0x0004, 4},{0x000B, 5}
+ },
+ {
+ {0x0007, 4},{0x001B, 6},{0x00F6, 8},{0x00E9, 8},
+ {0x03A1,10},{0x0740,11},{0x0E82,12},{0x001F, 5},
+ {0x01EF, 9},{0x0001, 3},{0x0002, 3},{0x000B, 4},
+ {0x000C, 4},{0x000D, 4},{0x0008, 4},{0x001C, 5},
+ {0x0003, 5},{0x0012, 5},{0x0002, 5},{0x0075, 7},
+ {0x01D1, 9},{0x1D07,13},{0x1D06,13},{0x000A, 4},
+ {0x0013, 5},{0x003B, 6},{0x001A, 6},{0x007A, 7},
+ {0x003C, 6},{0x01EE, 9},{0x0000, 4},{0x000C, 5}
+ },
+ {
+ {0x000D, 4},{0x003D, 6},{0x0042, 7},{0x0037, 7},
+ {0x00D9, 9},{0x0362,11},{0x06C6,12},{0x001F, 5},
+ {0x0086, 8},{0x0001, 3},{0x0002, 3},{0x000C, 4},
+ {0x000B, 4},{0x000A, 4},{0x0001, 4},{0x000F, 5},
+ {0x0025, 6},{0x003C, 6},{0x001A, 6},{0x0087, 8},
+ {0x01B0,10},{0x0D8F,13},{0x0D8E,13},{0x000E, 4},
+ {0x0013, 5},{0x000C, 5},{0x0024, 6},{0x0020, 6},
+ {0x0011, 5},{0x006D, 8},{0x0000, 4},{0x000E, 5}
+ },
+ {
+ {0x0000, 3},{0x0012, 5},{0x0076, 7},{0x0077, 7},
+ {0x014D, 9},{0x0533,11},{0x14C9,13},{0x0013, 5},
+ {0x00A5, 8},{0x0002, 3},{0x0003, 3},{0x000B, 4},
+ {0x000C, 4},{0x0008, 4},{0x001A, 5},{0x002B, 6},
+ {0x0075, 7},{0x0074, 7},{0x00A7, 8},{0x0298,10},
+ {0x14C8,13},{0x14CB,13},{0x14CA,13},{0x000F, 4},
+ {0x001C, 5},{0x0007, 5},{0x002A, 6},{0x0028, 6},
+ {0x001B, 5},{0x00A4, 8},{0x0002, 4},{0x0006, 5}
+ },
+ {
+ {0x0002, 3},{0x001A, 5},{0x002B, 6},{0x003A, 6},
+ {0x00ED, 8},{0x0283,10},{0x0A0A,12},{0x0004, 5},
+ {0x00A1, 8},{0x0004, 3},{0x0003, 3},{0x000B, 4},
+ {0x000C, 4},{0x001F, 5},{0x0006, 5},{0x0077, 7},
+ {0x00A3, 8},{0x00A2, 8},{0x0140, 9},{0x1417,13},
+ {0x1416,13},{0x0A09,12},{0x0A08,12},{0x0000, 3},
+ {0x001E, 5},{0x0007, 5},{0x002A, 6},{0x0029, 6},
+ {0x001C, 5},{0x00EC, 8},{0x001B, 5},{0x0005, 5}
+ },
+ {
+ {0x0002, 3},{0x0002, 4},{0x0018, 5},{0x001D, 5},
+ {0x0035, 6},{0x00E4, 8},{0x01CF,11},{0x001D, 7},
+ {0x0072, 9},{0x0004, 3},{0x0005, 3},{0x0006, 4},
+ {0x0007, 4},{0x0006, 5},{0x0073, 7},{0x0038, 8},
+ {0x01CE,11},{0x039B,12},{0x0398,12},{0x0733,13},
+ {0x0732,13},{0x0735,13},{0x0734,13},{0x0000, 3},
+ {0x001F, 5},{0x001B, 5},{0x0034, 6},{0x000F, 6},
+ {0x001E, 5},{0x00E5, 8},{0x0019, 5},{0x0038, 6}
+ },
+ {
+ {0x0016, 5},{0x0050, 7},{0x0172, 9},{0x02E7,10},
+ {0x1732,13},{0x2E67,14},{0x2E66,14},{0x0006, 4},
+ {0x0051, 7},{0x0001, 3},{0x0000, 3},{0x000D, 4},
+ {0x000C, 4},{0x0009, 4},{0x001C, 5},{0x0009, 5},
+ {0x001C, 6},{0x001D, 6},{0x005D, 7},{0x00B8, 8},
+ {0x05CD,11},{0x1731,13},{0x1730,13},{0x000F, 4},
+ {0x0005, 4},{0x000F, 5},{0x0008, 5},{0x0029, 6},
+ {0x001D, 5},{0x002F, 6},{0x0008, 4},{0x0015, 5}
+ },
+ {
+ {0x0009, 4},{0x0021, 6},{0x0040, 7},{0x00AD, 8},
+ {0x02B0,10},{0x1589,13},{0x1588,13},{0x001C, 5},
+ {0x005F, 7},{0x0000, 3},{0x000F, 4},{0x000D, 4},
+ {0x000C, 4},{0x0006, 4},{0x0011, 5},{0x002A, 6},
+ {0x0057, 7},{0x005E, 7},{0x0041, 7},{0x0159, 9},
+ {0x0563,11},{0x158B,13},{0x158A,13},{0x0001, 3},
+ {0x0005, 4},{0x0014, 5},{0x003B, 6},{0x002E, 6},
+ {0x0004, 4},{0x003A, 6},{0x0007, 4},{0x0016, 5}
+ },
+ {
+ {0x000E, 4},{0x0007, 5},{0x0046, 7},{0x0045, 7},
+ {0x0064, 9},{0x032A,12},{0x0657,13},{0x0018, 5},
+ {0x000D, 6},{0x0000, 3},{0x000F, 4},{0x000A, 4},
+ {0x000B, 4},{0x001A, 5},{0x0036, 6},{0x0047, 7},
+ {0x0044, 7},{0x0018, 7},{0x0033, 8},{0x00CB,10},
+ {0x0656,13},{0x0329,12},{0x0328,12},{0x0002, 3},
+ {0x0006, 4},{0x0019, 5},{0x000E, 5},{0x0037, 6},
+ {0x0009, 4},{0x000F, 5},{0x0002, 4},{0x0010, 5}
+ },
+ {
+ {0x0003, 3},{0x0018, 5},{0x0023, 6},{0x0077, 7},
+ {0x0194, 9},{0x1956,13},{0x32AF,14},{0x003A, 6},
+ {0x0076, 7},{0x0002, 3},{0x0001, 3},{0x001F, 5},
+ {0x001E, 5},{0x0014, 5},{0x0022, 6},{0x0064, 7},
+ {0x0197, 9},{0x0196, 9},{0x032B,10},{0x0654,11},
+ {0x32AE,14},{0x1955,13},{0x1954,13},{0x0000, 3},
+ {0x0009, 4},{0x001C, 5},{0x0015, 5},{0x0010, 5},
+ {0x000D, 4},{0x0017, 5},{0x0016, 5},{0x0033, 6}
+ },
+ {
+ {0x0005, 3},{0x0006, 4},{0x003E, 6},{0x0010, 5},
+ {0x0048, 7},{0x093F,12},{0x24FA,14},{0x0032, 6},
+ {0x0067, 7},{0x0002, 3},{0x0001, 3},{0x001B, 5},
+ {0x001E, 5},{0x0034, 6},{0x0066, 7},{0x0092, 8},
+ {0x0126, 9},{0x024E,10},{0x049E,11},{0x49F7,15},
+ {0x49F6,15},{0x24F9,14},{0x24F8,14},{0x0000, 3},
+ {0x0007, 4},{0x0018, 5},{0x0011, 5},{0x003F, 6},
+ {0x000E, 4},{0x0013, 5},{0x0035, 6},{0x0025, 6}
+ },
+ {
+ {0x0005, 3},{0x0008, 4},{0x0012, 5},{0x001C, 5},
+ {0x001C, 6},{0x00EA, 9},{0x1D75,14},{0x001E, 6},
+ {0x0066, 7},{0x0001, 3},{0x0002, 3},{0x001B, 5},
+ {0x001A, 5},{0x001F, 6},{0x003B, 7},{0x0074, 8},
+ {0x01D6,10},{0x03AF,11},{0x1D74,14},{0x1D77,14},
+ {0x1D76,14},{0x0EB9,13},{0x0EB8,13},{0x000F, 4},
+ {0x0006, 4},{0x0013, 5},{0x003B, 6},{0x003A, 6},
+ {0x0000, 3},{0x0018, 5},{0x0032, 6},{0x0067, 7}
+ },
+ {
+ {0x0004, 3},{0x000A, 4},{0x001B, 5},{0x000C, 4},
+ {0x000D, 5},{0x00E6, 8},{0x0684,11},{0x0072, 7},
+ {0x00E7, 8},{0x0002, 3},{0x0001, 3},{0x0017, 5},
+ {0x0016, 5},{0x0018, 6},{0x00D1, 8},{0x01A0, 9},
+ {0x0686,11},{0x0D0F,12},{0x0D0A,12},{0x1A17,13},
+ {0x1A16,13},{0x1A1D,13},{0x1A1C,13},{0x000F, 4},
+ {0x001D, 5},{0x000E, 5},{0x0035, 6},{0x0038, 6},
+ {0x0000, 3},{0x000F, 5},{0x0019, 6},{0x0069, 7}
+ },
+ {
+ {0x0003, 3},{0x000C, 4},{0x001B, 5},{0x0000, 3},
+ {0x0003, 4},{0x002E, 6},{0x0051, 9},{0x00BC, 8},
+ {0x0053, 9},{0x0004, 3},{0x0002, 3},{0x0016, 5},
+ {0x0015, 5},{0x0015, 7},{0x0050, 9},{0x00A4,10},
+ {0x0294,12},{0x052B,13},{0x052A,13},{0x052D,13},
+ {0x052C,13},{0x052F,13},{0x052E,13},{0x000E, 4},
+ {0x001A, 5},{0x0004, 5},{0x0028, 6},{0x0029, 6},
+ {0x000F, 4},{0x000B, 6},{0x005F, 7},{0x00BD, 8}
+ },
+ {
+ {0x0003, 4},{0x0009, 6},{0x00D0, 8},{0x01A3, 9},
+ {0x0344,10},{0x0D14,12},{0x1A2B,13},{0x0004, 4},
+ {0x0015, 7},{0x0000, 3},{0x000F, 4},{0x000B, 4},
+ {0x000C, 4},{0x000E, 4},{0x0009, 4},{0x001B, 5},
+ {0x000A, 5},{0x0014, 5},{0x000D, 5},{0x002A, 6},
+ {0x0014, 7},{0x068B,11},{0x1A2A,13},{0x0008, 4},
+ {0x000B, 5},{0x002B, 6},{0x000B, 6},{0x0069, 7},
+ {0x0035, 6},{0x0008, 6},{0x0007, 4},{0x000C, 5}
+ },
+ {
+ {0x000A, 4},{0x003C, 6},{0x0032, 7},{0x0030, 7},
+ {0x00C5, 9},{0x0621,12},{0x0620,12},{0x001F, 5},
+ {0x0033, 7},{0x0001, 3},{0x0000, 3},{0x000E, 4},
+ {0x000D, 4},{0x000C, 4},{0x0004, 4},{0x000D, 5},
+ {0x0026, 6},{0x0027, 6},{0x0014, 6},{0x0063, 8},
+ {0x0189,10},{0x0623,12},{0x0622,12},{0x000B, 4},
+ {0x0012, 5},{0x003D, 6},{0x0022, 6},{0x0015, 6},
+ {0x000B, 5},{0x0023, 6},{0x0007, 4},{0x0010, 5}
+ },
+ {
+ {0x000F, 4},{0x000C, 5},{0x0043, 7},{0x0010, 6},
+ {0x0044, 8},{0x0114,10},{0x0455,12},{0x0018, 5},
+ {0x0023, 7},{0x0001, 3},{0x0000, 3},{0x000E, 4},
+ {0x000D, 4},{0x0009, 4},{0x0019, 5},{0x0009, 5},
+ {0x0017, 6},{0x0016, 6},{0x0042, 7},{0x008B, 9},
+ {0x0454,12},{0x0457,12},{0x0456,12},{0x000B, 4},
+ {0x0015, 5},{0x000A, 5},{0x0029, 6},{0x0020, 6},
+ {0x000D, 5},{0x0028, 6},{0x0007, 4},{0x0011, 5}
+ },
+ {
+ {0x0001, 3},{0x001A, 5},{0x0029, 6},{0x002A, 6},
+ {0x00A0, 8},{0x0285,10},{0x1425,13},{0x0002, 5},
+ {0x0000, 7},{0x0002, 3},{0x0003, 3},{0x000C, 4},
+ {0x000B, 4},{0x0008, 4},{0x0012, 5},{0x0001, 6},
+ {0x0051, 7},{0x0001, 7},{0x0143, 9},{0x0508,11},
+ {0x1424,13},{0x1427,13},{0x1426,13},{0x000F, 4},
+ {0x001C, 5},{0x0003, 5},{0x0037, 6},{0x002B, 6},
+ {0x0013, 5},{0x0036, 6},{0x001D, 5},{0x0001, 5}
+ },
+ {
+ {0x0004, 3},{0x001F, 5},{0x003D, 6},{0x0006, 5},
+ {0x0016, 7},{0x0053, 9},{0x014A,11},{0x0034, 6},
+ {0x002A, 8},{0x0002, 3},{0x0003, 3},{0x000B, 4},
+ {0x000C, 4},{0x001C, 5},{0x0037, 6},{0x0017, 7},
+ {0x002B, 8},{0x0028, 8},{0x00A4,10},{0x052D,13},
+ {0x052C,13},{0x052F,13},{0x052E,13},{0x0000, 3},
+ {0x001D, 5},{0x0007, 5},{0x0004, 5},{0x0035, 6},
+ {0x0014, 5},{0x0036, 6},{0x0015, 5},{0x003C, 6}
+ },
+ {
+ {0x0004, 3},{0x000A, 4},{0x0007, 5},{0x001D, 5},
+ {0x0009, 6},{0x01F3, 9},{0x07C7,11},{0x0008, 6},
+ {0x01F0, 9},{0x0003, 3},{0x0002, 3},{0x000D, 4},
+ {0x000C, 4},{0x0017, 5},{0x007D, 7},{0x01F2, 9},
+ {0x07C6,11},{0x07C5,11},{0x1F12,13},{0x3E27,14},
+ {0x3E26,14},{0x1F11,13},{0x1F10,13},{0x0000, 3},
+ {0x001E, 5},{0x0006, 5},{0x0039, 6},{0x0038, 6},
+ {0x003F, 6},{0x002C, 6},{0x0005, 5},{0x002D, 6}
+ },
+ {
+ {0x0002, 3},{0x0007, 4},{0x0018, 5},{0x0003, 4},
+ {0x0005, 5},{0x0035, 7},{0x004F, 9},{0x0012, 7},
+ {0x04E5,13},{0x0005, 3},{0x0004, 3},{0x000D, 4},
+ {0x000E, 4},{0x0033, 6},{0x0026, 8},{0x009D,10},
+ {0x04E4,13},{0x04E7,13},{0x04E6,13},{0x04E1,13},
+ {0x04E0,13},{0x04E3,13},{0x04E2,13},{0x0000, 3},
+ {0x001F, 5},{0x000C, 5},{0x003D, 6},{0x003C, 6},
+ {0x0032, 6},{0x0034, 7},{0x001B, 6},{0x0008, 6}
+ },
+ {
+ {0x0000, 3},{0x0004, 4},{0x001C, 5},{0x000F, 4},
+ {0x0002, 4},{0x0007, 5},{0x0075, 7},{0x00E8, 8},
+ {0x1D2A,13},{0x0005, 3},{0x0004, 3},{0x000D, 4},
+ {0x000C, 4},{0x0077, 7},{0x0E96,12},{0x3A57,14},
+ {0x3A56,14},{0x3A5D,14},{0x3A5C,14},{0x3A5F,14},
+ {0x3A5E,14},{0x1D29,13},{0x1D28,13},{0x0003, 3},
+ {0x0006, 5},{0x000A, 5},{0x002C, 7},{0x0017, 6},
+ {0x0076, 7},{0x01D3, 9},{0x03A4,10},{0x002D, 7}
+ },
+ {
+ {0x000A, 4},{0x0024, 6},{0x00BF, 8},{0x0085, 8},
+ {0x0211,10},{0x0842,12},{0x1087,13},{0x0018, 5},
+ {0x0020, 6},{0x0001, 3},{0x0002, 3},{0x000E, 4},
+ {0x000D, 4},{0x0007, 4},{0x0013, 5},{0x0025, 6},
+ {0x005E, 7},{0x0043, 7},{0x00BE, 8},{0x0109, 9},
+ {0x1086,13},{0x0841,12},{0x0840,12},{0x000F, 4},
+ {0x0001, 4},{0x0011, 5},{0x0000, 5},{0x002E, 6},
+ {0x0019, 5},{0x0001, 5},{0x0006, 4},{0x0016, 5}
+ },
+ {
+ {0x0002, 3},{0x000F, 5},{0x006F, 7},{0x0061, 7},
+ {0x0374,10},{0x1BA8,13},{0x3753,14},{0x0012, 5},
+ {0x0036, 6},{0x0000, 3},{0x0001, 3},{0x000A, 4},
+ {0x000B, 4},{0x001A, 5},{0x0031, 6},{0x0060, 7},
+ {0x00DC, 8},{0x01BB, 9},{0x06EB,11},{0x1BAB,13},
+ {0x3752,14},{0x3755,14},{0x3754,14},{0x000E, 4},
+ {0x0006, 4},{0x0013, 5},{0x000E, 5},{0x003E, 6},
+ {0x0008, 4},{0x001E, 5},{0x0019, 5},{0x003F, 6}
+ },
+ {
+ {0x0003, 3},{0x001C, 5},{0x0025, 6},{0x0024, 6},
+ {0x01DA, 9},{0x1DBD,13},{0x3B7C,14},{0x003C, 6},
+ {0x003D, 6},{0x0000, 3},{0x0001, 3},{0x000B, 4},
+ {0x000A, 4},{0x000B, 5},{0x0077, 7},{0x00EC, 8},
+ {0x03B6,10},{0x076E,11},{0x1DBF,13},{0x76FB,15},
+ {0x76FA,15},{0x3B79,14},{0x3B78,14},{0x000D, 4},
+ {0x001F, 5},{0x0013, 5},{0x000A, 5},{0x0008, 5},
+ {0x000C, 4},{0x0008, 4},{0x0009, 5},{0x003A, 6}
+ },
+ {
+ {0x0005, 3},{0x0003, 4},{0x0004, 5},{0x0010, 5},
+ {0x008F, 8},{0x0475,11},{0x11D1,13},{0x0079, 7},
+ {0x0027, 6},{0x0002, 3},{0x0003, 3},{0x0001, 4},
+ {0x0000, 4},{0x0026, 6},{0x0046, 7},{0x011C, 9},
+ {0x0477,11},{0x08ED,12},{0x11D0,13},{0x11D3,13},
+ {0x11D2,13},{0x11D9,13},{0x11D8,13},{0x000D, 4},
+ {0x001F, 5},{0x0012, 5},{0x0005, 5},{0x003D, 6},
+ {0x000C, 4},{0x000E, 4},{0x0022, 6},{0x0078, 7}
+ },
+ {
+ {0x0005, 3},{0x000C, 4},{0x001B, 5},{0x0000, 4},
+ {0x0006, 6},{0x03E2,10},{0x3E3D,14},{0x000F, 7},
+ {0x0034, 6},{0x0003, 3},{0x0002, 3},{0x001E, 5},
+ {0x001D, 5},{0x007D, 7},{0x01F0, 9},{0x07C6,11},
+ {0x3E3C,14},{0x3E3F,14},{0x3E3E,14},{0x3E39,14},
+ {0x3E38,14},{0x3E3B,14},{0x3E3A,14},{0x0008, 4},
+ {0x001C, 5},{0x0002, 5},{0x003F, 6},{0x0035, 6},
+ {0x0009, 4},{0x0001, 3},{0x000E, 7},{0x00F9, 8}
+ },
+ {
+ {0x0004, 3},{0x000B, 4},{0x0001, 4},{0x000A, 4},
+ {0x001E, 6},{0x00E0, 9},{0x0E1E,13},{0x0071, 8},
+ {0x0039, 7},{0x0007, 3},{0x0006, 3},{0x000D, 5},
+ {0x000C, 5},{0x0020, 7},{0x01C2,10},{0x1C3F,14},
+ {0x1C3E,14},{0x0E19,13},{0x0E18,13},{0x0E1B,13},
+ {0x0E1A,13},{0x0E1D,13},{0x0E1C,13},{0x0000, 4},
+ {0x0009, 5},{0x001D, 6},{0x001F, 6},{0x0011, 6},
+ {0x0005, 4},{0x0001, 3},{0x0043, 8},{0x0042, 8}
+ },
+ {
+ {0x0004, 3},{0x000D, 4},{0x0007, 4},{0x0002, 3},
+ {0x0014, 5},{0x016C, 9},{0x16D1,13},{0x02DF,10},
+ {0x016E, 9},{0x0000, 2},{0x0007, 3},{0x002C, 6},
+ {0x002B, 6},{0x02DE,10},{0x16D0,13},{0x16D3,13},
+ {0x16D2,13},{0x2DB5,14},{0x2DB4,14},{0x2DB7,14},
+ {0x2DB6,14},{0x16D9,13},{0x16D8,13},{0x000C, 5},
+ {0x002A, 6},{0x005A, 7},{0x001B, 6},{0x001A, 6},
+ {0x0017, 5},{0x000C, 4},{0x05B7,11},{0x05B5,11}
+ },
+ {
+ {0x0002, 2},{0x000F, 4},{0x001C, 5},{0x000C, 4},
+ {0x003B, 6},{0x01AC, 9},{0x1AD8,13},{0x35B3,14},
+ {0x35B2,14},{0x0001, 2},{0x0000, 2},{0x0069, 7},
+ {0x0068, 7},{0x35BD,14},{0x35BC,14},{0x35BF,14},
+ {0x35BE,14},{0x35B9,14},{0x35B8,14},{0x35BB,14},
+ {0x35BA,14},{0x35B5,14},{0x35B4,14},{0x01A9, 9},
+ {0x01A8, 9},{0x035A,10},{0x00D7, 8},{0x00D5, 8},
+ {0x003A, 6},{0x001B, 5},{0x35B7,14},{0x35B6,14}
+ },
+ {
+ {0x0000, 3},{0x0010, 5},{0x0072, 7},{0x0071, 7},
+ {0x0154, 9},{0x0AAB,12},{0x0AA8,12},{0x0014, 5},
+ {0x0070, 7},{0x0002, 3},{0x0003, 3},{0x000C, 4},
+ {0x000B, 4},{0x0003, 4},{0x0011, 5},{0x0073, 7},
+ {0x0054, 7},{0x00AB, 8},{0x02AB,10},{0x1553,13},
+ {0x1552,13},{0x1555,13},{0x1554,13},{0x000D, 4},
+ {0x001E, 5},{0x0012, 5},{0x003E, 6},{0x002B, 6},
+ {0x0002, 4},{0x003F, 6},{0x001D, 5},{0x0013, 5}
+ },
+ {
+ {0x0003, 3},{0x001F, 5},{0x0029, 6},{0x003D, 6},
+ {0x000C, 7},{0x0069,10},{0x0345,13},{0x0002, 5},
+ {0x0028, 6},{0x0002, 3},{0x0001, 3},{0x000E, 4},
+ {0x000C, 4},{0x0015, 5},{0x0007, 6},{0x001B, 8},
+ {0x006B,10},{0x006A,10},{0x0344,13},{0x0347,13},
+ {0x0346,13},{0x01A1,12},{0x01A0,12},{0x000B, 4},
+ {0x001A, 5},{0x0012, 5},{0x0000, 5},{0x003C, 6},
+ {0x0008, 4},{0x001B, 5},{0x0013, 5},{0x0001, 5}
+ },
+ {
+ {0x0004, 3},{0x0004, 4},{0x003F, 6},{0x0014, 5},
+ {0x0056, 7},{0x015C, 9},{0x15D5,13},{0x003C, 6},
+ {0x002A, 6},{0x0000, 3},{0x0001, 3},{0x000E, 4},
+ {0x000D, 4},{0x000C, 5},{0x00AF, 8},{0x02BB,10},
+ {0x15D4,13},{0x15D7,13},{0x15D6,13},{0x15D1,13},
+ {0x15D0,13},{0x15D3,13},{0x15D2,13},{0x000B, 4},
+ {0x0019, 5},{0x000D, 5},{0x003E, 6},{0x0031, 6},
+ {0x0007, 4},{0x0005, 4},{0x003D, 6},{0x0030, 6}
+ },
+ {
+ {0x0005, 3},{0x0008, 4},{0x001A, 5},{0x0000, 4},
+ {0x0036, 6},{0x0011, 8},{0x0106,12},{0x000A, 7},
+ {0x006E, 7},{0x0002, 3},{0x0003, 3},{0x0003, 4},
+ {0x0002, 4},{0x006F, 7},{0x0021, 9},{0x020F,13},
+ {0x020E,13},{0x0101,12},{0x0100,12},{0x0103,12},
+ {0x0102,12},{0x0105,12},{0x0104,12},{0x000C, 4},
+ {0x001E, 5},{0x0003, 5},{0x003E, 6},{0x003F, 6},
+ {0x0009, 4},{0x000E, 4},{0x000B, 7},{0x0009, 7}
+ },
+ {
+ {0x0002, 3},{0x000E, 4},{0x001E, 5},{0x000C, 4},
+ {0x001F, 5},{0x006E, 7},{0x00AD,10},{0x00AF,10},
+ {0x0014, 7},{0x0004, 3},{0x0003, 3},{0x001A, 5},
+ {0x0017, 5},{0x002A, 8},{0x0576,13},{0x0AEF,14},
+ {0x0AEE,14},{0x0571,13},{0x0570,13},{0x0573,13},
+ {0x0572,13},{0x0575,13},{0x0574,13},{0x0003, 4},
+ {0x0016, 5},{0x0004, 5},{0x0036, 6},{0x000B, 6},
+ {0x000A, 4},{0x0000, 3},{0x006F, 7},{0x00AC,10}
+ },
+ {
+ {0x0004, 3},{0x0005, 4},{0x0003, 3},{0x0001, 3},
+ {0x0004, 4},{0x002F, 6},{0x0526,11},{0x1495,13},
+ {0x00A6, 8},{0x0007, 3},{0x0006, 3},{0x002D, 6},
+ {0x002C, 6},{0x1494,13},{0x1497,13},{0x1496,13},
+ {0x1491,13},{0x1490,13},{0x1493,13},{0x1492,13},
+ {0x293D,14},{0x293C,14},{0x293F,14},{0x0000, 3},
+ {0x0028, 6},{0x00A5, 8},{0x0148, 9},{0x00A7, 8},
+ {0x002E, 6},{0x0015, 5},{0x0A4E,12},{0x293E,14}
+ },
+ {
+ {0x0004, 3},{0x0005, 4},{0x0003, 3},{0x0001, 3},
+ {0x0004, 4},{0x002F, 6},{0x0526,11},{0x1495,13},
+ {0x00A6, 8},{0x0007, 3},{0x0006, 3},{0x002D, 6},
+ {0x002C, 6},{0x1494,13},{0x1497,13},{0x1496,13},
+ {0x1491,13},{0x1490,13},{0x1493,13},{0x1492,13},
+ {0x293D,14},{0x293C,14},{0x293F,14},{0x0000, 3},
+ {0x0028, 6},{0x00A5, 8},{0x0148, 9},{0x00A7, 8},
+ {0x002E, 6},{0x0015, 5},{0x0A4E,12},{0x293E,14}
+ },
+ {
+ {0x0004, 3},{0x0005, 4},{0x0003, 3},{0x0001, 3},
+ {0x0004, 4},{0x002F, 6},{0x0526,11},{0x1495,13},
+ {0x00A6, 8},{0x0007, 3},{0x0006, 3},{0x002D, 6},
+ {0x002C, 6},{0x1494,13},{0x1497,13},{0x1496,13},
+ {0x1491,13},{0x1490,13},{0x1493,13},{0x1492,13},
+ {0x293D,14},{0x293C,14},{0x293F,14},{0x0000, 3},
+ {0x0028, 6},{0x00A5, 8},{0x0148, 9},{0x00A7, 8},
+ {0x002E, 6},{0x0015, 5},{0x0A4E,12},{0x293E,14}
+ },
+ {
+ {0x0003, 3},{0x0011, 5},{0x0020, 6},{0x0074, 7},
+ {0x010D, 9},{0x0863,12},{0x0860,12},{0x000A, 5},
+ {0x0075, 7},{0x0001, 3},{0x0000, 3},{0x000B, 4},
+ {0x000A, 4},{0x0018, 5},{0x0038, 6},{0x0042, 7},
+ {0x010F, 9},{0x010E, 9},{0x0219,10},{0x10C3,13},
+ {0x10C2,13},{0x10C5,13},{0x10C4,13},{0x000F, 4},
+ {0x0004, 4},{0x0019, 5},{0x000B, 5},{0x0039, 6},
+ {0x0009, 4},{0x001B, 5},{0x001A, 5},{0x003B, 6}
+ },
+ {
+ {0x0005, 3},{0x0001, 4},{0x003E, 6},{0x0001, 5},
+ {0x00E2, 8},{0x1C6F,13},{0x38D9,14},{0x0039, 6},
+ {0x001F, 6},{0x0002, 3},{0x0001, 3},{0x0009, 4},
+ {0x0008, 4},{0x0000, 5},{0x0070, 7},{0x01C7, 9},
+ {0x038C,10},{0x071A,11},{0x38D8,14},{0x38DB,14},
+ {0x38DA,14},{0x38DD,14},{0x38DC,14},{0x000D, 4},
+ {0x001D, 5},{0x000E, 5},{0x003F, 6},{0x003C, 6},
+ {0x000C, 4},{0x0006, 4},{0x003D, 6},{0x001E, 6}
+ },
+ {
+ {0x0006, 3},{0x000B, 4},{0x0011, 5},{0x001E, 5},
+ {0x0074, 7},{0x03AA,10},{0x1D5C,13},{0x0001, 6},
+ {0x0021, 6},{0x0001, 3},{0x0002, 3},{0x0007, 4},
+ {0x0006, 4},{0x003E, 6},{0x00EB, 8},{0x01D4, 9},
+ {0x0EAF,12},{0x3ABB,14},{0x3ABA,14},{0x1D59,13},
+ {0x1D58,13},{0x1D5B,13},{0x1D5A,13},{0x000A, 4},
+ {0x001C, 5},{0x0001, 5},{0x003F, 6},{0x003B, 6},
+ {0x0001, 4},{0x0009, 4},{0x0020, 6},{0x0000, 6}
+ },
+ {
+ {0x0004, 3},{0x000A, 4},{0x0017, 5},{0x0004, 4},
+ {0x0016, 6},{0x016A, 9},{0x16B1,13},{0x0017, 7},
+ {0x005B, 7},{0x0006, 3},{0x0007, 3},{0x0001, 4},
+ {0x0000, 4},{0x000A, 6},{0x02D7,10},{0x0B5A,12},
+ {0x16B0,13},{0x16B3,13},{0x16B2,13},{0x2D6D,14},
+ {0x2D6C,14},{0x2D6F,14},{0x2D6E,14},{0x0006, 4},
+ {0x000A, 5},{0x0004, 5},{0x002C, 6},{0x0017, 6},
+ {0x0003, 4},{0x0007, 4},{0x0016, 7},{0x00B4, 8}
+ },
+ {
+ {0x0005, 3},{0x000D, 4},{0x0005, 4},{0x0009, 4},
+ {0x0033, 6},{0x0193, 9},{0x192C,13},{0x0061, 8},
+ {0x0031, 7},{0x0000, 2},{0x0007, 3},{0x0010, 5},
+ {0x0011, 5},{0x00C8, 8},{0x192F,13},{0x325B,14},
+ {0x325A,14},{0x1929,13},{0x1928,13},{0x192B,13},
+ {0x192A,13},{0x325D,14},{0x325C,14},{0x0018, 5},
+ {0x001A, 6},{0x001B, 6},{0x0065, 7},{0x0019, 6},
+ {0x0004, 4},{0x0007, 4},{0x0060, 8},{0x0324,10}
+ },
+ {
+ {0x0006, 3},{0x0000, 3},{0x0002, 4},{0x000F, 4},
+ {0x0039, 6},{0x01D9, 9},{0x1D82,13},{0x0761,11},
+ {0x03BE,10},{0x0001, 2},{0x0002, 2},{0x000F, 6},
+ {0x000E, 6},{0x0762,11},{0x3B07,14},{0x3B06,14},
+ {0x3B1D,14},{0x3B1C,14},{0x3B1F,14},{0x3B1E,14},
+ {0x3B19,14},{0x3B18,14},{0x3B1B,14},{0x0038, 6},
+ {0x01DE, 9},{0x00ED, 8},{0x03BF,10},{0x00EE, 8},
+ {0x003A, 6},{0x0006, 5},{0x0EC0,12},{0x3B1A,14}
+ },
+ {
+ {0x0000, 2},{0x0002, 3},{0x000F, 5},{0x0006, 4},
+ {0x001C, 6},{0x01D0,10},{0x0E8C,13},{0x1D1B,14},
+ {0x1D1A,14},{0x0003, 2},{0x0002, 2},{0x00EA, 9},
+ {0x00E9, 9},{0x0E89,13},{0x0E88,13},{0x0E8B,13},
+ {0x0E8A,13},{0x1D65,14},{0x1D64,14},{0x1D67,14},
+ {0x1D66,14},{0x1D61,14},{0x1D60,14},{0x03AD,11},
+ {0x1D63,14},{0x1D62,14},{0x1D1D,14},{0x1D1C,14},
+ {0x003B, 7},{0x01D7,10},{0x1D1F,14},{0x1D1E,14}
+ },
+ {
+ {0x0002, 2},{0x000F, 4},{0x001C, 5},{0x000C, 4},
+ {0x003B, 6},{0x01AC, 9},{0x1AD8,13},{0x35B3,14},
+ {0x35B2,14},{0x0001, 2},{0x0000, 2},{0x0069, 7},
+ {0x0068, 7},{0x35BD,14},{0x35BC,14},{0x35BF,14},
+ {0x35BE,14},{0x35B9,14},{0x35B8,14},{0x35BB,14},
+ {0x35BA,14},{0x35B5,14},{0x35B4,14},{0x01A9, 9},
+ {0x01A8, 9},{0x035A,10},{0x00D7, 8},{0x00D5, 8},
+ {0x003A, 6},{0x001B, 5},{0x35B7,14},{0x35B6,14}
+ }
+};
+
+
+
+/*A description of a Huffman code value used when encoding the tree.*/
+typedef struct{
+ /*The bit pattern, left-shifted so that the MSB of all patterns is
+ aligned.*/
+ unsigned long pattern;
+ /*The amount the bit pattern was shifted.*/
+ int shift;
+ /*The token this bit pattern represents.*/
+ int token;
+}th_huff_entry;
+
+
+
+/*Compares two th_huff_entry structures by their bit patterns.
+ _c1: The first entry to compare.
+ _c2: The second entry to compare.
+ Return: <0 if _c1<_c2, >0 if _c1>_c2.*/
+static int huff_entry_cmp(const void *_c1,const void *_c2){
+ unsigned long b1;
+ unsigned long b2;
+ b1=((const th_huff_entry *)_c1)->pattern;
+ b2=((const th_huff_entry *)_c2)->pattern;
+ return b1b2?1:0;
+}
+
+int th_huff_codes2latex(const theora_huff_code _codes[80][32]){
+ int i;
+ printf("\\twocolumn\n");
+ for(i=0;i<80;i++){
+ th_huff_entry entries[32];
+ int maxlen;
+ int mask;
+ int j;
+ /*First, find the maximum code length so we can align all the bit
+ patterns.*/
+ maxlen=_codes[i][0].nbits;
+ for(j=1;j<32;j++)if(maxlen<_codes[i][j].nbits)maxlen=_codes[i][j].nbits;
+ mask=(1<entries[j].shift;){
+ printf("%c",(int)(entries[j].pattern>>k&1)+'0');
+ }
+ printf("}");
+ for(;k>=0;k--)printf(" ");
+ printf(" & ");
+ if(entries[j].token<10)printf(" ");
+ printf("$%i$ \\\\\n",entries[j].token);
+ }
+ printf("\\bottomrule\n");
+ printf("\\\\\n");
+ printf("\\multicolumn{2}{c}{VP3.1 Huffman Table Number $%i$}\n",i);
+ printf("\\end{tabular}\n");
+ printf("\\end{center}\n");
+ printf("\\vfill\n");
+ printf("\n");
+ }
+ printf("\\onecolumn\n");
+ return 0;
+}
+
+int main(int _argc,char **_argv){
+ th_huff_codes2latex(TH_VP31_HUFF_CODES);
+ return 0;
+}
diff --git a/libs/libtheora-1.1/doc/spec/xifish.fig b/libs/libtheora-1.1/doc/spec/xifish.fig
new file mode 100644
index 00000000..f044a2b5
--- /dev/null
+++ b/libs/libtheora-1.1/doc/spec/xifish.fig
@@ -0,0 +1,85 @@
+#FIG 3.2
+Landscape
+Center
+Inches
+Letter
+100.00
+Single
+-2
+1200 2
+0 32 #496d9e
+0 33 #304d71
+0 34 #8eb2cf
+1 4 0 6 0 7 1 0 20 0.000 1 0.0000 1470 3255 270 270 1200 3255 1740 3255
+1 3 0 0 0 0 0 0 20 0.000 1 0.0000 1485 3255 75 75 1485 3255 1560 3255
+2 1 0 7 0 3 8 0 20 0.000 0 0 -1 0 0 6
+ 2445 4140 2505 4350 2385 4425 2145 4425 2025 4380 1890 4320
+2 1 0 7 0 3 8 0 20 0.000 0 0 -1 0 0 20
+ 2445 3480 2775 3450 2955 3390 3090 3315 3285 3285 3555 3285
+ 3615 3390 3540 3675 3465 3720 3315 3765 3105 3810 3330 3765
+ 3420 3825 3540 3900 3480 4260 3330 4320 3165 4305 2910 4260
+ 2715 4185 2520 4185
+2 1 0 7 0 3 11 0 20 0.000 0 0 -1 0 0 9
+ 1575 3150 1755 2985 2040 2820 2355 2760 2670 2850 2850 2985
+ 3165 3270 3435 3420 2835 3780
+2 1 0 7 0 6 6 0 20 0.000 0 0 -1 0 0 15
+ 900 3570 1020 3450 1095 3360 1395 3150 1545 3090 1725 3075
+ 2025 3090 2205 3150 2295 3225 2385 3300 2445 3375 2550 3465
+ 2655 3540 2775 3600 2865 3600
+2 1 0 7 0 3 4 0 20 0.000 0 0 -1 0 0 7
+ 1515 4080 1770 4080 1875 3945 1965 3870 2025 3780 1995 3780
+ 1665 3780
+2 1 0 0 -1 6 7 0 20 0.000 0 0 -1 0 0 11
+ 2865 3615 2850 3735 2775 3945 2685 4080 2595 4155 2010 4185
+ 1185 4170 1035 3990 1035 3870 975 3540 1155 3435
+2 1 0 0 0 3 5 0 20 0.000 0 0 -1 0 0 7
+ 1035 3885 1005 4020 1095 4065 1245 4065 1245 3870 1050 3870
+ 1065 3870
+2 1 0 7 0 3 0 0 20 0.000 0 0 -1 0 0 11
+ 1245 3915 1245 3840 1170 3750 1005 3585 930 3510 750 3510
+ 630 3600 645 3690 765 3780 885 3825 1035 3975
+2 1 0 7 0 3 0 0 20 0.000 0 0 -1 0 0 8
+ 1095 3990 945 3990 855 4050 795 4140 885 4200 1095 4200
+ 1155 4140 1245 4050
+2 1 0 7 0 6 6 0 20 0.000 0 0 -1 0 0 8
+ 2685 4185 2400 4185 2220 4215 1920 4305 1695 4335 1485 4320
+ 1245 4215 1155 4125
+2 2 0 0 0 0 3 0 20 0.000 0 0 0 0 0 5
+ 2250 3900 2250 3825 2175 3825 2175 3900 2250 3900
+2 2 0 0 0 0 3 0 20 0.000 0 0 0 0 0 5
+ 2250 3750 2250 3675 2175 3675 2175 3750 2250 3750
+2 1 0 0 -1 3 5 0 20 0.000 0 0 -1 0 0 9
+ 1650 3780 1590 3975 1485 4035 1530 4080 1770 4065 1845 3960
+ 1920 3900 1965 3795 1695 3780
+2 2 0 0 0 0 3 0 20 0.000 0 0 0 0 0 5
+ 1950 3450 1950 3375 1875 3375 1875 3450 1950 3450
+2 2 0 0 0 0 3 0 20 0.000 0 0 0 0 0 5
+ 2400 3900 2400 3825 2325 3825 2325 3900 2400 3900
+2 2 0 0 0 0 3 0 20 0.000 0 0 0 0 0 5
+ 2550 3975 2550 3900 2475 3900 2475 3975 2550 3975
+2 2 0 0 0 0 3 0 20 0.000 0 0 0 0 0 5
+ 2700 3900 2700 3825 2625 3825 2625 3900 2700 3900
+2 2 0 0 0 0 3 0 20 0.000 0 0 0 0 0 5
+ 2700 3750 2700 3675 2625 3675 2625 3750 2700 3750
+2 2 0 0 0 0 3 0 20 0.000 0 0 0 0 0 5
+ 2550 3675 2550 3600 2475 3600 2475 3675 2550 3675
+2 2 0 0 0 0 3 0 20 0.000 0 0 0 0 0 5
+ 2400 3750 2400 3675 2325 3675 2325 3750 2400 3750
+2 2 0 0 0 0 3 0 20 0.000 0 0 0 0 0 5
+ 2400 3600 2400 3525 2325 3525 2325 3600 2400 3600
+2 2 0 0 0 0 3 0 20 0.000 0 0 0 0 0 5
+ 2250 3600 2250 3525 2175 3525 2175 3600 2250 3600
+2 2 0 0 0 0 3 0 20 0.000 0 0 0 0 0 5
+ 2250 3450 2250 3375 2175 3375 2175 3450 2250 3450
+2 2 0 0 0 0 3 0 20 0.000 0 0 0 0 0 5
+ 2100 3525 2100 3450 2025 3450 2025 3525 2100 3525
+2 2 0 0 0 0 3 0 20 0.000 0 0 0 0 0 5
+ 2100 3375 2100 3300 2025 3300 2025 3375 2100 3375
+2 2 0 0 0 0 3 0 20 0.000 0 0 0 0 0 5
+ 2550 3825 2550 3750 2475 3750 2475 3825 2550 3825
+2 3 0 0 -1 32 13 0 20 0.000 0 0 7 0 0 5
+ 2160 2055 3810 3705 2160 5355 510 3705 2160 2055
+2 1 0 0 32 34 12 0 20 0.000 0 0 -1 0 0 3
+ 2160 2055 2160 3705 510 3705
+2 1 0 0 32 33 12 0 20 0.000 0 0 -1 0 0 3
+ 3810 3705 2160 3705 2160 5355
diff --git a/libs/libtheora-1.1/doc/vp3-format.txt b/libs/libtheora-1.1/doc/vp3-format.txt
new file mode 100644
index 00000000..408febe4
--- /dev/null
+++ b/libs/libtheora-1.1/doc/vp3-format.txt
@@ -0,0 +1,1305 @@
+VP3 Bitstream Format and Decoding Process
+by Mike Melanson (mike at multimedia.cx)
+v0.5: December 8, 2004
+
+
+[December 8, 2004: Note that this document is not complete and likely
+will never be completed. However, it helped form the basis of Theora I
+specification available at
+ http://www.theora.org/doc/Theora_I_spec.pdf ]
+
+
+Contents
+--------
+ * Introduction
+ * Underlying Coding Concepts
+ * VP3 Coding Overview
+ * VP3 Chunk Format
+ * Decoding The Frame Header
+ * Initializing The Quantization Matrices
+ * Hilbert Coding Pattern
+ * Unpacking The Block Coding Information
+ * Unpacking The Macroblock Coding Mode Information
+ * Unpacking The Macroblock Motion Vectors
+ * Unpacking The DCT Coefficients
+ * Reversing The DC Prediction
+ * Reconstructing The Frame
+ * Theora Specification
+ * Appendix A: Quantization Matrices And Scale Factors
+ * Appendix B: Macroblock Coding Mode Alphabets
+ * Appendix C: DCT Coefficient VLC Tables
+ * Appendix D: The VP3 IDCT
+ * Acknowledgements
+ * References
+ * Changelog
+
+
+Introduction
+------------
+A company named On2 (http://www.on2.com) created a video codec named
+VP3. Eventually, they decided to open source it. Like any body of code
+that was produced on a deadline, the source code was not particularly
+clean or well-documented. This makes it difficult to understand the
+fundamental operation of the codec.
+
+This document describes the VP3 bitstream format and decoding process at
+a higher level than source code.
+
+
+Underlying Coding Concepts
+--------------------------
+In order to understand the VP3 coding method it is necessary to
+understand the individual steps in the process. Like many multimedia
+compression algorithms VP3 does not consist of a single coding method.
+Rather, it uses a chain of methods to achieve compression.
+
+If you are acquainted with the MPEG video clique then many of VP3's
+coding concepts should look familiar as well. What follows is a list of
+the coding methods used in VP3 and a brief description of each.
+
+* Discrete Cosine Transform (DCT): This is a magical mathematical
+function that takes a group of numbers and turns it into another group
+of numbers. The transformed group of numbers exhibits some curious
+properties. Notably, larger numbers are concentrated in certain areas of
+the transformed group.
+
+A video codec like VP3 often operates on 8x8 blocks of numbers. When
+these 8x8 blocks are transformed using a DCT the larger numbers occur
+mostly in the up and left areas of the block with the largest number
+occurring as the first in the block (up-left corner). This number is
+called the DC coefficient. The other 63 numbers are called the AC
+coefficients.
+
+The DCT and its opposite operation, the inverse DCT, require a lot of
+multiplications. Much research and experimentation is focused of
+optimizing this phase of the coding/decoding process.
+
+* Quantization: This coding step tosses out information by essentially
+dividing a number to be coded by a factor and throwing away the
+remainder. The inverse process (dequantization) involves multiplying by
+the same factor to obtain a number that is close enough to the original.
+
+* Run Length Encoding (RLE): The concept behind RLE is to shorten runs
+of numbers that are the same. For example, the string "88888" is encoded
+as (5, 8), indicating a run of 5 '8' numbers. In VP3 (and MPEG/JPEG),
+RLE is used to record the number of zero-value coefficients that occur
+before a non-zero coefficient. For example:
+
+ 0 0 0 0 5 0 2 0 0 0 9
+
+is encoded as:
+
+ (4, 5), (1, 2), (3, 9)
+
+This indicates that a run of 4 zeroes is followed by a coefficient of 5;
+then a run of 1 zero is followed by 2; then a run of 3 zeroes is
+followed by 9.
+
+* Zigzag Ordering: After transforming and quantizing a block of samples,
+the samples are not in an optimal order for run length encoding. Zigzag
+ordering rearranges the samples to put more zeros between non-zero
+samples.
+
+* Differential (or Delta) Pulse Code Modulation (DPCM): 1 + 1 = 2. Got
+that? Seriously, that is what DPCM means. Rather than encoding absolute
+values, encode the differences between successive values. For example:
+
+ 82 84 81 80 86 88 85
+
+Can be delta-encoded as:
+
+ 82 +2 -3 -1 +6 +2 -3
+
+Most of the numbers turn into smaller numbers which require less
+information to encode.
+
+* Motion Compensation: Simply, this coding method specifies that a block
+from a certain position in the previous frame is to be copied into a new
+position in the current frame. This technique is often combined with DCT
+and DPCM coding, as well as fractional pixel motion.
+
+* Entropy Coding (a.k.a. Huffman Coding): This is the process of coding
+frequently occurring symbols with fewer bits than symbols that are not
+likely to occur as frequently.
+
+* Variable Length Run Length Booleans: An initial Boolean bit is
+extracted from the bitstream. A variable length code (VLC) is extracted
+from the bitstream and converted to a count. This count indicates that
+the next (count) elements are to be set to the Boolean value.
+Afterwards, the Boolean value is toggled, the next VLC is extracted and
+converted to a count, and the process continues until all elements are
+set to either 0 or 1.
+
+* YUV Colorspace: Like many modern video codecs, VP3 operates on a YUV
+colorspace rather than a RGB colorspace. Specifically, VP3 uses YUV
+4:2:0, alias YUV420P, YV12. Note: Throughout the course of this
+document, the U and V planes (a.k.a., Cb and Cr planes) will be
+collectively referred to as C planes (color or chrominance planes).
+
+* Frame Types: VP3 has intra-coded frames, a.k.a. intraframes, I-frames,
+or keyframes. VP3 happens to call these golden frames. VP3 has
+interframes, a.k.a. predicted frames or P-frames. These frames can use
+information from either the previous interframe or from the previous
+golden frame.
+
+
+VP3 Overview
+------------
+The first thing to understand about the VP3 coding method is that it
+encodes all 3 planes upside down. That is, the data is encoded from
+bottom-to-top rather than top-to-bottom as is done with many video
+codecs.
+
+VP3 codes a video frame by first breaking each of the 3 planes (Y, U,
+and V) into a series of 8x8 blocks called fragments. VP3 also has a
+notion of superblocks. Superblocks encapsulate 16 fragments arranged in
+a 4x4 matrix. Each plane has its own set of superblocks. Further, VP3
+also uses the notion of macroblocks which is the same as that found in
+JPEG/MPEG. One macroblock encompasses 4 blocks from the Y plane arranged
+in a 2x2 matrix, 1 block from the U plane, and 1 block from the V plane.
+While a fragment or a superblock applies to 1 and only 1 plane, a
+macroblock extends over all 3 planes.
+
+VP3 compresses golden frames by transforming each fragment with a
+discrete cosine transform. Each transformed sample is then quantized and
+the DC coefficient is reduced via DPCM using a combination of DC
+coefficients from surrounding fragments as predictors. Then, each
+fragment's DC coefficient is entropy-coded in the output bitstream,
+followed by each fragment's first AC coefficient, then each second AC
+coefficient, and so on.
+
+An interframe, naturally, is more complicated. While there is only one
+coding mode available for a golden frame (intra coding), there are 8
+coding modes that the VP3 coder can choose from for interframe
+macroblocks. Intra coding as seen in the keyframe is still available.
+The rest of the modes involve encoding a fragment diff, either from the
+previous frame or the golden frame, from the same coordinate or from the
+same coordinate plus a motion vector. All of the macroblock coding modes
+and motion vectors are encoded in an interframe bitstream.
+
+
+VP3 Chunk Format
+----------------
+The high-level format of a compressed VP3 frame is laid out as:
+
+ * chunk header
+ * block coding information
+ * macroblock coding mode information
+ * motion vectors
+ * DC coefficients
+ * 1st AC coefficients
+ * 2nd AC coefficients
+ * ...
+ * 63rd AC coefficients
+
+
+Decoding The Frame Header
+-------------------------
+The chunk header always contains at least 1 byte which has the following
+format:
+
+ bit 7: 0 = golden frame, 1 = interframe
+ bit 6: unused
+ bits 5-0: Quality index (0..63)
+
+Further, if the frame is a golden frame, there are 2 more bytes in the
+header:
+
+ byte 0: version byte 0
+ byte 1:
+ bits 7-3: VP3 version number (stored)
+ bit 2: key frame coding method (0 = DCT key frame, only type
+ supported)
+ bits 1-0: unused, spare bits
+
+All frame headers are encoded with a quality index. This 6-bit value is
+used to index into 2 dequantizer scaling tables, 1 for DC values and 1
+for AC values. Each of the 3 dequantization tables is modified per these
+scaling values.
+
+
+Initializing The Quantization Matrices
+--------------------------------------
+VP3 has three static matrices for quantizing and dequantizing fragments.
+One matrix is for quantizing golden frame Y fragments, one matrix is for
+quantizing golden frame C fragments, and one matrix is for quantizing both
+golden frame and interframe Y or C fragments. While these matrices are
+static, they are adjusted according to quality index coded in the header.
+
+The quality index is an index into 2 64-element tables:
+dc_scale_factor[] and ac_scale_factor[]. Each quantization factor from
+each of the three quantization matrices is adjusted by the appropriate
+scale factor according to this formula:
+
+ base quantizer * scale factor
+ quantizer = -----------------------------
+ 100
+
+ where scale factor =
+ dc_scale_factor[quality_index] for DC dequantizer
+ ac_scale_factor[quality_index] for AC dequantizer
+
+The quantization matrices need to be recalculated at the beginning of a
+frame decode if the current frame's quality index is different from the
+previous frame's quality index.
+
+See Appendix A for the complete VP3 quantization matrices and scale factor
+tables.
+
+As an example, this is the base quantization matrix for golden frame Y
+fragments:
+
+ 16 11 10 16 24 40 51 61
+ 12 12 14 19 26 58 60 55
+ 14 13 16 24 40 57 69 56
+ 14 17 22 29 51 87 80 62
+ 18 22 37 58 68 109 103 77
+ 24 35 55 64 81 104 113 92
+ 49 64 78 87 103 121 120 101
+ 72 92 95 98 112 100 103 99
+
+If a particular coded frame specifies a quality index of 54. Element 54
+of the dc_scale_factor table is 20, thus:
+
+ 16 * 20
+ DC coefficient quantizer = ------- = 3
+ 100
+
+Element 54 of the ac_scale_factor table is 24. The AC coefficient
+quantizers are each scaled using this factor, e.g.:
+
+ 11 * 24
+ ------- = 2
+ 100
+
+ 100 * 24
+ -------- = 24
+ 100
+
+[not complete; still need to explain how these quantizers are saturated
+and scaled with respect to the DCT process]
+
+
+Hilbert Coding Pattern
+----------------------
+VP3 uses a Hilbert pattern to code fragments within a superblock. A
+Hilbert pattern is a recursive pattern that can grow quite complicated.
+The coding pattern that VP3 uses is restricted to this pattern subset,
+where each fragment in a superblock is represented by a 'X':
+
+ X -> X X -> X
+ | ^
+ v |
+ X <- X X <- X
+ | ^
+ v |
+ X X -> X X
+ | ^ | ^
+ v | v |
+ X -> X X -> X
+
+As an example of this pattern, consider a plane that is 256 samples wide
+and 64 samples high. Each fragment row will be 32 fragments wide. The
+first superblock in the plane will be comprised of these 16 fragments:
+
+ 0 1 2 3 ... 31
+ 32 33 34 35 ... 63
+ 64 65 66 67 ... 95
+ 96 97 98 99 ... 127
+
+The order in which these 16 fragments are coded is:
+
+ 0 | 0 1 14 15
+ 32 | 3 2 13 12
+ 64 | 4 7 8 11
+ 96 | 5 6 9 10
+
+All of the image coding information, including the block coding status
+and modes, the motion vectors, and the DCT coefficients, are all coded
+and decoded using this pattern. Thus, it is rather critical to have the
+pattern and all of its corner cases handled correctly. In the above
+example, if the bottom row and left column were not present due to the
+superblock being in a corner, the pattern proceeds as if the missing
+fragments were present, but the missing fragments are omitted in the
+final coding list. The coding order would be:
+
+ 0, 1, 2, 3, 4, 7, 8, 13, 14
+
+
+Unpacking The Block Coding Information
+--------------------------------------
+After unpacking the frame header, the decoder unpacks the block coding
+information. The only information determined in this phase is whether a
+particular superblock and its fragments are coded in the current frame
+or unchanged from the previous frame. The actual coding method is
+determined in the next phase.
+
+If the frame is a golden frame then every superblock, macroblock, and
+fragment is marked as coded.
+
+If the frame is an interframe, then the block coding information must be
+decoded. This is the phase where a decoder will build a list of coded
+fragments for which coding mode, motion vector, and DCT coefficient data
+must be decoded.
+
+First, a list of partially-coded superblocks is unpacked from the
+stream. This list is coded as a series of variable-length run length
+codes (VLRLC). First, the code is initialized by reading the next bit in
+the stream. Then, while there are still superblocks remaining in the
+list, fetch a VLC from the stream according to this table:
+
+ Codeword Run Length
+ 0 1
+ 10x 2-3
+ 110x 4-5
+ 1110xx 6-9
+ 11110xxx 10-17
+ 111110xxxx 18-33
+ 111111xxxxxxxxxxxx 34-4129
+
+For example, a VLC of 1101 represents a run length of 5. If the VLRLC
+was initialized to 1, then the next 5 superblocks would be set to 1,
+indicating that they are partially coded in the current frame. Then the
+bit value is toggled to 0, another VLC is fetched from the stream and
+the process continues until each superblock has been marked either
+partially coded (1) or not (0).
+
+If any of the superblocks were marked as not partially coded in the
+previous step, then a list of fully-coded superblocks is unpacked next
+using the same VLRLC as the list of partially-coded superblocks.
+Initialize the VLRLC with the next bit in the stream. For each
+superblock that was not marked as partially coded, mark it with either a
+0 or 1 according to the current VLRLC. By the end of this step, each
+superblock will be marked as either not coded, partially coded, or fully
+coded.
+
+Let's work through an example with an image frame that is 256x64 pixels.
+This means that the Y plane contains 4x2 superblocks and each of the C
+planes contains 2 superblocks each. The superblocks are numbered as
+follows:
+
+ Y: 0 1 2 3 U: 8 9
+ 4 5 6 7 V: 10 11
+
+This is the state of the bitstream:
+
+ 1100011001101
+
+Which is interpreted as:
+
+ initial 2 1's 1 0 4 1's 5 0's
+ 1 100 0 1100 1101
+
+Superblocks 0-1 and 3-6 are marked as partially coded. Since there were
+blocks that were not marked, proceed to unpack the list of fully-coded
+superblocks. This is the state of the bitstream:
+
+ 1101101
+
+Which is interpreted as:
+
+ initial 3 1's 3 0's
+ 1 101 100
+
+Superblocks 2, 7, and 8 are marked as fully coded while superblocks 9,
+10, and 11 are marked as not coded.
+
+If any of the superblocks were marked as partially coded, the next data
+in the bitstream will define which fragments inside each partially-coded
+superblock are coded. This is the first place where the Hilbert pattern
+comes into play.
+
+For each partially-coded superblock, iterate through each fragment
+according to the Hilbert pattern. Use the VLRLC method, only with a
+different table, to determine which fragments are coded. The VLRLC table
+for fragment coding runs is:
+
+ Codeword Run Length
+ 0x 1-2
+ 10x 3-4
+ 110x 5-6
+ 1110xx 7-10
+ 11110xx 11-14
+ 11111xxxx 15-30
+
+Continuing with the contrived example, superblocks 0 and 1 are both
+partially coded. This is the state of the bitstream:
+
+ 0011001111010001111010...(not complete)
+
+Which is interpreted as:
+ initial 2 0's 3 1's 13 0's 1 1 13 0's
+ 0 01 100 1111010 00 1111010 ...
+
+This indicates that fragments 2-4 in superblock 0 are coded, while
+fragments 0, 1, and 5-15 are not. Note that the run of 12 0's cascades
+over into the next fragment, indicating that fragment 0 of superblock 1
+is not coded. Fragment 1 of superblock 1 is coded, while the rest of the
+superblock's fragments are not coded. The example ends there (a real
+bitstream should have enough data to describe all of the partially-coded
+superblocks). Superblock 2 is fully coded which means all 16 fragments
+are coded. Thus, superblocks 0-2 have the following coded fragments:
+
+ 0 | x x x x x x x x 0 1 14 15
+ 32 | 3 2 x x x 2 x x 3 2 13 12
+ 64 | 4 x x x x x x x 4 7 8 11
+ 96 | x x x x x x x x 5 6 9 10
+
+This is a good place to generate the list of coded fragment numbers for
+this frame. In this case, the list will begin as:
+
+ 33 32 64 37 8 9 41 40 72 104 105 73 ...
+
+and so on through the remaining 8 fragments of superblock 2 and onto the
+fragments for the remaining superblocks that are either fully or
+partially coded.
+
+
+Unpacking The Macroblock Coding Mode Information
+------------------------------------------------
+After unpacking the block coding information, the decoder unpacks the
+macroblock coding mode information. This process is simple when
+decoding a golden frame-- since the only possible decoding mode is INTRA,
+no macroblock coding mode information is transmitted. However, in an
+interframe, each coded macroblock is encoded with one of 8 methods:
+
+0, INTER_NO_MV:
+ current fragment =
+ (fragment from previous frame @ same coordinates) +
+ (DCT-encoded residual)
+
+1, INTRA:
+ current fragment = DCT-encoded block, just like in a golden frame
+
+2, INTER_PLUS_MV:
+ current fragment =
+ (fragment from previous frame @ (same coords + motion vector)) +
+ (DCT-encoded residual)
+
+3, INTER_LAST_MV:
+ same as INTER_PLUS_MV but using the last motion vector decoded from
+ the bitstream
+
+4, INTER_PRIOR_LAST;
+ same as INTER_PLUS_MV but using the second-to-last motion vector
+ decoded from the bitstream
+
+5, USING_GOLDEN:
+ same as INTER_NO_MV but referencing the golden frame instead of
+ previous interframe
+
+6, GOLDEN_MV:
+ same as INTER_PLUS_MV but referencing the golden frame instead of
+ previous interframe
+
+7, INTER_FOURMV:
+ same as INTER_PLUS_MV except that each of the 4 Y fragments gets its
+ own motion vector, and the U and V fragments share the same motion
+ vector which is the average of the 4 Y fragment vectors
+
+The MB coding mode information is encoded using one of 8 alphabets. The
+first 3 bits of the MB coding mode stream indicate which of the 8
+alphabets, 0..7, to use to decode the MB coding information in this frame.
+The reason for the different alphabets is to minimize the number of bits
+needed to encode this section of information. Each alphabet arranges the
+coding modes in a different order, indexing the 8 modes into 8 index
+slots. Index 0 is encoded with 1 bit (0), index 1 is encoded with 2 bits
+(10), index 2 is encoded with 3 bits (110), and so on up to indices 6 and
+7 which are encoded with 6 bits each (1111110 and 1111111, respectively):
+
+ index encoding
+ ----- --------
+ 0 0
+ 1 10
+ 2 110
+ 3 1110
+ 4 11110
+ 5 111110
+ 6 1111110
+ 7 1111111
+
+For example, the coding modes are arranged in alphabet 1 as follows:
+
+ index coding mode
+ ----- -----------
+ 0 MODE_INTER_LAST_MV
+ 1 MODE_INTER_PRIOR_LAST
+ 2 MODE_INTER_PLUS_MV
+ 3 MODE_INTER_NO_MV
+ 4 MODE_INTRA
+ 5 MODE_USING_GOLDEN,
+ 6 MODE_GOLDEN_MV
+ 7 MODE_INTER_FOURMV
+
+This alphabet arrangement is designed for frames in which motion vectors
+based off of the previous interframe dominate.
+
+When unpacking MB coding mode information for a frame, the decoder first
+reads 3 bits from the stream to determine the alphabet. In this example,
+the 3 bits would be 001 to indicate alphabet 1. Consider this contrived
+bitstream following the alphabet number:
+
+ 1010000011000011111110...
+
+The bits are read as follows:
+
+ 10 10 0 0 0 0 110 0 0 0 1111111 0
+ index: 1 1 0 0 0 0 2 0 0 0 7 0
+
+This arrangement of indices translates to this series of coding modes:
+
+ index coding mode
+ ----- -----------
+ 1 MODE_INTER_PRIOR_LAST
+ 1 MODE_INTER_PRIOR_LAST
+ 0 MODE_INTER_LAST_MV
+ 0 MODE_INTER_LAST_MV
+ 0 MODE_INTER_LAST_MV
+ 0 MODE_INTER_LAST_MV
+ 2 MODE_INTER_PLUS_MV
+ 0 MODE_INTER_LAST_MV
+ 0 MODE_INTER_LAST_MV
+ 0 MODE_INTER_LAST_MV
+ 7 MODE_INTER_FOURMV
+ 0 MODE_INTER_LAST_MV
+
+There are 6 pre-defined alphabets. Consult Appendix B for the complete
+alphabets. What happens if none of the 6 pre-defined alphabets fit? The
+VP3 encoder can choose to use alphabet 0 which indicates a custom
+alphabet. The 3-bit coding mode numbers for each index, 0..7, are stored
+after the alphabet number in the bitstream. For example, the sequence:
+
+ 000 111 110 101 100 011 010 001 000
+
+would indicate coding alphabet 0 (custom alphabet), index 0 corresponds to
+coding mode 7 (INTER_FOURMV), index 1 corresponds to coding mode 6
+(GOLDEN_MV), and so on down to index 7 which would correspond to coding
+mode 0 (INTER_NO_MV).
+
+There is one more possible alphabet: Alphabet 7. This alphabet is
+reserved for when there is such a mixture of coding modes used in a frame
+that using any variable-length coding mode would result in more bits than
+a fixed-length representation. When alphabet 7 is specified, the decoder
+reads 3 bits at a time from the bitstream, and uses those directly as the
+macroblock coding modes.
+
+To recap, this is the general algorithm for decoding macroblock coding
+mode information:
+
+ if (golden frame)
+ all frames are intracoded, there is no MB coding mode information
+ else
+ read 3 bits from bitstream to determine alphabet
+ if alphabet = 0
+ this is a custom alphabet, populate index table with 8 3-bit coding
+ modes read from bitstream
+ foreach coded macroblock, unpack a coding mode:
+ if alphabet = 7
+ read 3 bits from the bitstream as the coding mode for the
+ macroblock
+ else
+ read a VLC from the bitstream
+ use the decoded VLC value to index into the coding mode alphabet
+ selected for this frame and assign the indexed coding mode to
+ this macroblock
+
+
+Unpacking The Macroblock Motion Vectors
+---------------------------------------
+After unpacking the macroblock coding mode information, the decoder
+unpacks the macroblock motion vectors. This phase essentially assigns a
+motion vector to each of the 6 constituent fragments of any coded
+macroblock that requires motion vectors.
+
+If the frame is a golden frame then there is no motion compensation and
+no motion vectors are encoded in the bitstream.
+
+If the frame is an interframe, the next bit is read from the bitstream
+to determine the vector entropy coding method used. If the coding method
+is zero then all of the vectors will be unpacked using a VLC method. If
+the coding method is 1 then all of the vectors will be unpacked using a
+fixed length method.
+
+The VLC unpacking method reads 3 bits from the bitstream. These 3 bits
+comprise a number ranging from 0..7 which indicate the next action:
+
+0, MV component = 0
+1, MV component = 1
+2, MV component = -1
+3, MV component = 2, read next bit for sign
+4, MV component = 3, read next bit for sign
+5, MV component = 4 + (read next 2 bits), read next bit for sign
+ range: (4..7, -4..-7)
+6, MV component = 8 + (read next 3 bits), read next bit for sign
+ range: (8..15, -8..-15)
+7, MV component = 16 + (read next 4 bits), read next bit for sign
+ range: (16..31, -16..-31)
+
+The fixed length vector unpacking method simply reads the next 5 bits
+from the bitstream, reads the next bit for sign, and calls the whole
+thing a motion vector component. This gives a range of (-31..31), which
+is the same range as the VLC method.
+
+For example, consider the following contrived motion vector bitstream:
+
+ 000001011011111000...
+
+The stream is read as:
+
+ 0 (000 010) (110 111 1 100 0)
+
+The first bit indicates the entropy method which, in this example, is
+variable length as opposed to fixed length. The next 3 bits are 0 which
+indicate a X MV component of 0. The next 3 bits are 2 which indicate a Y
+MV component of -1. The first motion vector encoded in this stream is
+(0, -1). The next 3 bits are 6 which indicate 8 + next 3 bits (7) with
+another bit indicating sign (1 in this case, which is negative). Thus,
+the X MV component is -15. The next 3 bits are 4 which indicate a Y MV
+component of 3 with one more bit for the sign (0 is positive). So the
+second motion vector encoded in this stream is (-15, 3).
+
+As an example of the fixed-length entropy method, consider the following
+contrived bitstream:
+
+ 1010101101010...
+
+The stream is read as:
+
+ 1 01010 1 10101 0
+
+The first bit indicates the fixed length entropy method. The first 5 bits
+are 10 followed by a negative sign bit. The next 5 bits are 21 followed by
+a positive sign bit. The first motion vector in this stream is (-10, 21).
+
+During this phase of the decoding process, it is traditional to assign all
+motion vectors for all coded macroblocks that require them, whether they
+are unpacked from the motion vector bitstream or copied from previous
+coded macroblocks. It is necessary to track the motion vectors for both
+the previous macroblock as well as the next-to-last (prior) macroblock.
+The general algorithm for this phase is as follows:
+
+ foreach coded macroblock
+ last MV = 0
+ prior last MV = 0
+ if coding mode = MODE_INTER_PLUS_MV or MODE_GOLDEN_MV
+ read current MV pair from the bitstream and set all fragment motion
+ vectors to that pair
+ prior last MV = last MV
+ last MV = current MV
+
+ if coding mode = MODE_INTER_FOURMV
+ read MV for first Y fragment in macroblock
+ read MV for second Y fragment in macroblock
+ read MV for third Y fragment in macroblock
+ read MV for fourth Y fragment in macroblock
+ set U & V fragment motion vectors to average of 4 Y vectors,
+ calculated as follows:
+ if sum of all 4 X motion components is positive, the X
+ motion component for the U & V fragments is (sum + 2) / 4,
+ otherwise, it is (sum - 2) / 4; repeat the same process for the
+ Y components
+ prior last MV = last MV
+ last MV = MV for fourth Y fragment from this macroblock
+
+ if coding mode = MODE_INTER_LAST_MV
+ motion vectors for this macroblock are the same as last MV; note
+ that in this case, the last MV remains the last MV and the prior
+ last MV remains the prior last MV
+
+ if coding mode = MODE_INTER_PRIOR_LAST
+ motion vectors for this macroblock are the same as prior last MV
+ prior last MV = last MV
+ last MV = current MV (effectively, swap last and prior last vectors)
+
+
+Unpacking The DCT Coefficients
+------------------------------
+After unpacking the macroblock motion vectors, the decoder unpacks the
+fragment DCT coefficient data. Each coded fragment has 64 DCT
+coefficients. Some of the coefficients will be non-zero. Many of the
+coefficients will, or should be 0 as this is where the coding method
+derives much of its compression.
+
+During this phase, the decoder will be unpacking DCT coefficients, zero
+runs, and end-of-block (EOB) codes. The decoder unpacks the the DC
+coefficients for all fragments, then all of the first AC coefficients,
+and so on until all of the 64 DCT coefficients are unpacked from the
+bitstream.
+
+To obtain the DCT coefficients, the decoder unpacks a series of VLCs
+from the bitstream which turn into a series of tokens ranging from
+0..31. Each of these tokens specifies which action to take next. VP3
+defines 80 different 32-element histograms for VLC decoding:
+
+ 16 histograms for DC token decoding
+ 16 histograms for group 1 AC token decoding
+ 16 histograms for group 2 AC token decoding
+ 16 histograms for group 3 AC token decoding
+ 16 histograms for group 4 AC token decoding
+
+The decoder fetches 4 bits from the bitstream that will be used to
+select a DC histogram and 4 bits that will be used to select 4 AC
+histograms, one for each AC group.
+
+The meaning of each of the 32 possible tokens follows. 'EB' stands for
+extra bits read from bitstream directly after the VLC token:
+
+0, DCT_EOB_TOKEN
+set the current block to EOB, meaning that the block is marked as being
+fully unpacked
+
+1, DCT_EOB_PAIR_TOKEN
+set the next 2 blocks to EOB
+
+2. DCT_EOB_TRIPLE_TOKEN
+set the next 3 blocks to EOB
+
+3, DCT_REPEAT_RUN_TOKEN
+set the next (2 EBs + 4) blocks to EOB
+
+4, DCT_REPEAT_RUN2_TOKEN
+set the next (3 EBs + 8) blocks to EOB
+
+5, DCT_REPEAT_RUN3_TOKEN
+set the next (4 EBs + 16) blocks to EOB
+
+6, DCT_REPEAT_RUN4_TOKEN
+set the next (12 EBs) blocks to EOB
+
+7, DCT_SHORT_ZRL_TOKEN
+skip (3 EBs + 1) positions in the output matrix
+
+8, DCT_ZRL_TOKEN
+skip (6 EBs + 1) positions in the output matrix
+
+9, ONE_TOKEN
+output 1 as coefficient
+
+10, MINUS_ONE_TOKEN
+output -1 as coefficient
+
+11, TWO_TOKEN
+output 2 as coefficient
+
+12, MINUS_TWO_TOKEN
+output -2 as coefficient
+
+13, 14, 15, 16, LOW_VAL_TOKENS
+next EB determines coefficient sign; coeff = DCT_VAL_CAT2_MIN (3) +
+(token - 13) (this gives a range of +/- 3..6)
+
+17, DCT_VAL_CATEGORY3
+next EB determines coefficient sign; coeff = DCT_VAL_CAT3_MIN (7) + next
+EB (this gives a range of +/- 7..8)
+
+18, DCT_VAL_CATEGORY4
+next EB determines coefficient sign; coeff = DCT_VAL_CAT4_MIN (9) + next
+2 EBs (this gives a range of +/- 9..12)
+
+19, DCT_VAL_CATEGORY5
+next EB determines coefficient sign; coeff = DCT_VAL_CAT5_MIN (13) +
+next 3 EBs (this gives a range of +/- 13..20)
+
+20, DCT_VAL_CATEGORY6
+next EB determines coefficient sign; coeff = DCT_VAL_CAT6_MIN (21) +
+next 4 EBs (this gives a range of +/- 21..36)
+
+21, DCT_VAL_CATEGORY7
+next EB determines coefficient sign; coeff = DCT_VAL_CAT7_MIN (37) +
+next 5 EBs (this gives a range of +/- 37..68)
+
+22, DCT_VAL_CATEGORY8
+next EB determines coefficient sign; coeff = DCT_VAL_CAT8_MIN (69) +
+next 9 EBs (this gives a range of +/- 69..580)
+
+23, 24, 25, 26, 27, DCT_RUN_CATEGORY1
+coefficient of +/- 1 preceded by a number of 0s; next EB determines sign
+of coefficient; skip (token - 22) 0s in the output matrix before
+placing the final coefficient (this gives a range of 1..5 0s)
+
+28, DCT_RUN_CATEGORY1B
+coefficient of +/- 1 preceded by a number of 0s; next EB determines sign
+of coefficient; skip (next 2 EBs + 6) 0s in the output matrix before
+placing the final coefficient (this gives a range of 6..9 0s)
+
+29, DCT_RUN_CATEGORY1C
+coefficient of +/- 1 preceded by a number of 0s; next EB determines sign
+of coefficient; skip (next 3 EBs + 10) 0s in the output matrix before
+placing the final coefficient (this gives a range of 10..17 0s)
+
+30, DCT_RUN_CATEGORY2
+coefficient of +/- 2..3 preceded by a single zero; next EB determines
+sign of coefficient; coefficient = (next EB + 2)
+
+31, DCT_RUN_CATEGORY2B (not specifically named in VP3 source)
+coefficient of +/- 2..3 preceded by 2 or 3 0s; next EB determines
+sign of coefficient; coefficient = (next EB + 2); skip (next EB + 2) 0s
+before placing coefficient in output matrix
+
+Note: EOB runs can, and often do, cross threshold stages and plane
+boundaries. For example, a decoder may have decoded all of the AC #2
+coefficients for all fragments and still have an EOB run of 2. That
+means that during the AC #3 decode process, the first 2 coded fragments
+that are not already EOB will be set to EOB.
+
+Let's work through a highly contrived example to illustrate the
+coefficient decoding process.
+
+
+
+[not finished]
+
+
+
+
+When the decoder is finished unpacking the DCT coefficients, the entire
+encoded VP3 frame bitstream should be consumed.
+
+
+Reversing The DC Prediction
+---------------------------
+Now that all of the DCT coefficient data has been unpacked, the DC
+coefficients need to be fully reconstructed before the IDCT can be
+performed.
+
+VP3 uses a somewhat involved process for DC prediction which uses up to
+four DC coefficients from surrounding fragments. For each fragment to be
+transformed with the IDCT, the DC coefficient is predicted from weighted
+sum of the DC coefficients in the left (l), up-left (ul), up (u), and
+up-right (ur) fragments, if they are coded (not unchanged from the
+previous frame) in a compatible frame (current, previous, or golden).
+
+In a golden frame, the prediction is quite straightforward since all
+fragments will be coded. A fragment's DC prediction will fall into 1 of
+5 groups:
+
+ abbbbbbbbb
+ cdddddddde
+ cdddddddde
+ cdddddddde
+ cdddddddde
+
+* Group a is the top left corner fragment. There is nothing to predict
+from. This DC coefficient has a lot of energy and requires many bits to
+code.
+
+* Group b is the remainder of the top row of fragments. These fragments
+can only predict from the left fragment.
+
+* Group c is the left column of fragments, not including the top left
+fragment. These fragments have the top and top-right fragments from
+which to predict.
+
+* Group d is the main body of fragments. These fragments have access to
+all 4 predictors.
+
+* Group e is the right column of fragments, not including the top right
+fragment. These fragments can predict from the left, up-left and up
+fragments.
+
+The process of reversing prediction for interframes grows more complex.
+First, the decoder must evaluate which candidate fragments (l, ul, u, or
+ur) are available for as predictors. Then, it can only use fragments
+that are coded within the same frame (current, previous, or golden).
+Further, there are auxiliary predictors for each frame type that are
+initialized to 0 at the start of each video frame decode operation. The
+decoder falls back on these auxiliary predictors when it can not find
+any valid candidate predictors for the current fragment.
+
+To work through some examples, consider the following notation, e.g.:
+
+ ul-C = up-left fragment, coded in the current frame
+ u-P = up fragment, coded as a motion residual from the previous frame
+ ur-C = up-right fragment, coded in the current frame
+ l-G = left fragment, coded as a motion residual from the golden frame
+ x-P = current fragment where DC prediction is being performed, coded
+ as a motion residual from the previous frame
+
+This is a simple case:
+
+ ul-C u-C ur-C
+ l-C x-C
+
+The current fragment predicts from all four of the candidate fragments
+since they are coded in the same frame.
+
+ ul-P u-C ur-C
+ l-P x-P
+
+The current fragment predicts from the left and up-left fragments.
+
+ ul-C u-P ur-G
+ l-P x-G
+
+The current fragment predicts from the up-right fragment.
+
+ ul-C u-C ur-C
+ l-C x-G
+
+The current fragment does not predict from any of the candidate
+fragments since the current fragment is a motion residual from the
+golden frame. Rather, add the auxiliary golden frame predictor to the
+current fragment's DC coefficient. Save the new DC coefficient as the
+new golden frame auxiliary DC predictor.
+
+If the decoder only finds one valid candidate predictor, then it is used
+by itself. When the decoder finds multiple valid candidate fragments
+from which to predict DC, it applies a weighting function to the
+surrounding fragments' DC coefficients. The following table presents all
+16 possible combinations of available/not available predictors and what
+to do in each case:
+
+ ul u ur l
+ -- -- -- --
+ 0 0 0 0 no predictors available:
+ use the last predictor saved for the frame type
+ (either intra, inter, or golden)
+
+ 0 0 0 1 left predictor available:
+ pred = l.dc
+
+ 0 0 1 0 up-right predictor available:
+ pred = ur.dc
+
+ 0 0 1 1 up-right, left predictors available:
+ pred = (53 * ur.dc) + (75 * l.dc)
+ --------------------------
+ 128
+
+ 0 1 0 0 up predictor available:
+ pred = u.dc
+
+ 0 1 0 1 up, left predictors available:
+ pred = (u.dc + l.dc)
+ -------------
+ 2
+
+ 0 1 1 0 up, up-right predictors available:
+ discard up-right predictor
+ pred = u.dc
+
+ 0 1 1 1 up, up-right, left predictors available:
+ discard up predictor
+ pred = (53 * ur.dc) + (75 * l.dc)
+ --------------------------
+ 128
+
+ 1 0 0 0 up-left predictor available:
+ pred = ul.dc
+
+ 1 0 0 1 up-left, left predictors available:
+ discard up-left predictor
+ pred = l.dc
+
+ 1 0 1 0 up-left, up-right predictors available:
+ pred = (ul.dc + ur.dc)
+ ---------------
+ 2
+
+ 1 0 1 1 up-left, up-right, left predictors available:
+ discard up-left predictor
+ pred = (53 * ur.dc) + (75 * l.dc)
+ --------------------------
+ 128
+
+ 1 1 0 0 up-left, up predictors available:
+ discard up-left
+ pred = u.dc
+
+ 1 1 0 1 up-left, up, left predictors available:
+ pred = (-26 * ul.dc + 29 * u.dc + 29 * l.dc)
+ -------------------------------------
+ 32
+
+ 1 1 1 0 up-left, up, up-right predictors available:
+ pred = (3 * ul.dc + 10 * u.dc + 3 * ur.dc)
+ -----------------------------------
+ 16
+
+ 1 1 1 1 all 4 predictors available:
+ discard up-right predictor
+ pred = (-26 * ul.dc + 29 * u.dc + 29 * l.dc)
+ -------------------------------------
+ 32
+
+Note that this final prediction case ([ul u l]) risks outranging. The
+difference of the predicted DC is checked against u.dc, l.dc, and ul.dc,
+in that order, and if the difference is greater than 128 in any case,
+the predictor is assigned as that DC coefficient. In pseudocode:
+
+ if (ABSOLUTE_VALUE(pred - u.dc) > 128)
+ pref = u.dc
+ else if (ABSOLUTE_VALUE(pred - l.dc) > 128)
+ pref = l.dc
+ else if (ABSOLUTE_VALUE(pred - ul.dc) > 128)
+ pref = ul.dc
+
+The predicted value is, at long last, added to the fragment's decoded DC
+coefficient. Finally, the new DC coefficient is saved as the frame
+type's auxiliary predictor. For example, if this fragment is coded as a
+motion residual from the previous frame, save the fragment's DC
+coefficient as the previous frame auxiliary predictor.
+
+
+[still need to mention precise rounding considerations, a.k.a, the
+HIGHTBITDUPPED() macro]
+
+
+
+Reconstructing The Frame
+------------------------
+rough outline:
+ - foreach fragment:
+ - if motion vector
+ - copy motion fragment from appropriate frame into current frame
+ (don't forget to account for unrestricted motion vectors)
+ - dequantize fragment coefficients
+ - run coefficients through inverse DCT
+ - if INTRA coded fragment
+ - output transformed coefficients
+ - else
+ - apply transformed residual to motion fragment
+
+[not finished]
+
+
+Theora Specification
+--------------------
+The Theora project leverages the VP3 codec into a new video coding
+system. The algorithm and bitstream format are the same as VP3 with a
+few minor differences:
+
+1) The frame orientation is reversed-- VP3 is coded from bottom to top
+while Theora video is coded from top to bottom.
+[nope-- only true in the first few alpha releases; final Theora spec will
+be upside-down, the same as VP3]
+
+2) Variable histograms-- VP3 uses a hardcoded set of histograms for DCT
+coefficient coding (described in section "Unpacking The DCT
+Coefficients"). Theora packs the histogram information in the header of
+the transport format (which is meant to be Ogg, but can probably be
+coerced into a variety of other multimedia container formats).
+
+3) Variable quantization-- As with the histograms, Theora codes the
+quantization tables and quality thresholds (described in section
+"Initializing The Quantization Matrices") into the header.
+
+4) [special VLRLC case for encoding unusually large runs of blocks;
+necessary for HD resolutions]
+
+[still need coding format of histogram and quantizer information]
+
+
+Appendix A: VP31 Quantization Matrices And Scale Factors
+--------------------------------------------------------
+The following quantization matrices and scale factor tables are hardcoded
+into the VP31 coding standard. These tables can vary according to the
+setup information transported along with a Theora file.
+
+Base quantization matrix for golden frame Y fragments (note that this
+is the same as JPEG):
+
+ 16 11 10 16 24 40 51 61
+ 12 12 14 19 26 58 60 55
+ 14 13 16 24 40 57 69 56
+ 14 17 22 29 51 87 80 62
+ 18 22 37 58 68 109 103 77
+ 24 35 55 64 81 104 113 92
+ 49 64 78 87 103 121 120 101
+ 72 92 95 98 112 100 103 99
+
+
+Base quantization matrix for golden frame C fragments (note that this
+is the same as JPEG):
+
+ 17 18 24 47 99 99 99 99
+ 18 21 26 66 99 99 99 99
+ 24 26 56 99 99 99 99 99
+ 47 66 99 99 99 99 99 99
+ 99 99 99 99 99 99 99 99
+ 99 99 99 99 99 99 99 99
+ 99 99 99 99 99 99 99 99
+ 99 99 99 99 99 99 99 99
+
+
+Base quantization matrix for interframe Y and C fragments:
+
+ 16 16 16 20 24 28 32 40
+ 16 16 20 24 28 32 40 48
+ 16 20 24 28 32 40 48 64
+ 20 24 28 32 40 48 64 64
+ 24 28 32 40 48 64 64 64
+ 28 32 40 48 64 64 64 96
+ 32 40 48 64 64 64 96 128
+ 40 48 64 64 64 96 128 128
+
+
+DC coefficient scale factor table:
+
+ 220 200 190 180 170 170 160 160
+ 150 150 140 140 130 130 120 120
+ 110 110 100 100 90 90 90 80
+ 80 80 70 70 70 60 60 60
+ 60 50 50 50 50 40 40 40
+ 40 40 30 30 30 30 30 30
+ 30 20 20 20 20 20 20 20
+ 20 10 10 10 10 10 10 10
+
+
+AC coefficient scale factor table:
+
+ 500 450 400 370 340 310 285 265
+ 245 225 210 195 185 180 170 160
+ 150 145 135 130 125 115 110 107
+ 100 96 93 89 85 82 75 74
+ 70 68 64 60 57 56 52 50
+ 49 45 44 43 40 38 37 35
+ 33 32 30 29 28 25 24 22
+ 21 19 18 17 15 13 12 10
+
+
+Appendix B: Macroblock Coding Mode Alphabets
+--------------------------------------------
+These are the 6 pre-defined alphabets used to decode macroblock coding
+mode information:
+
+Alphabet 1:
+ index coding mode
+ ----- -----------
+ 0 MODE_INTER_LAST_MV
+ 1 MODE_INTER_PRIOR_LAST
+ 2 MODE_INTER_PLUS_MV
+ 3 MODE_INTER_NO_MV
+ 4 MODE_INTRA
+ 5 MODE_USING_GOLDEN,
+ 6 MODE_GOLDEN_MV
+ 7 MODE_INTER_FOURMV
+
+Alphabet 2:
+ index coding mode
+ ----- -----------
+ 0 MODE_INTER_LAST_MV
+ 1 MODE_INTER_PRIOR_LAST
+ 2 MODE_INTER_NO_MV
+ 3 MODE_INTER_PLUS_MV
+ 4 MODE_INTRA
+ 5 MODE_USING_GOLDEN
+ 6 MODE_GOLDEN_MV
+ 7 MODE_INTER_FOURMV
+
+Alphabet 3:
+ index coding mode
+ ----- -----------
+ 0 MODE_INTER_LAST_MV
+ 1 MODE_INTER_PLUS_MV
+ 2 MODE_INTER_PRIOR_LAST
+ 3 MODE_INTER_NO_MV
+ 4 MODE_INTRA
+ 5 MODE_USING_GOLDEN
+ 6 MODE_GOLDEN_MV
+ 7 MODE_INTER_FOURMV
+
+Alphabet 4:
+ index coding mode
+ ----- -----------
+ 0 MODE_INTER_LAST_MV
+ 1 MODE_INTER_PLUS_MV
+ 2 MODE_INTER_NO_MV
+ 3 MODE_INTER_PRIOR_LAST
+ 4 MODE_INTRA
+ 5 MODE_USING_GOLDEN
+ 6 MODE_GOLDEN_MV
+ 7 MODE_INTER_FOURMV
+
+Alphabet 5:
+ index coding mode
+ ----- -----------
+ 0 MODE_INTER_NO_MV
+ 1 MODE_INTER_LAST_MV
+ 2 MODE_INTER_PRIOR_LAST
+ 3 MODE_INTER_PLUS_MV
+ 4 MODE_INTRA
+ 5 MODE_USING_GOLDEN
+ 6 MODE_GOLDEN_MV
+ 7 MODE_INTER_FOURMV
+
+Alphabet 6:
+ index coding mode
+ ----- -----------
+ 0 MODE_INTER_NO_MV
+ 1 MODE_USING_GOLDEN
+ 2 MODE_INTER_LAST_MV
+ 3 MODE_INTER_PRIOR_LAST
+ 4 MODE_INTER_PLUS_MV
+ 5 MODE_INTRA
+ 6 MODE_GOLDEN_MV
+ 7 MODE_INTER_FOURMV
+
+
+Appendix C: DCT Coefficient VLC Tables
+--------------------------------------
+- VP31 tables are hardcoded
+- Theora tables are transported with video stream
+
+[not finished]
+
+
+Appendix D: The VP3 IDCT
+------------------------
+
+[not finished]
+
+
+Acknowledgements
+----------------
+Thanks to Michael Niedermayer (michaelni at gmx dot at) for peer review,
+corrections, and recommendations for improvement.
+
+Dan Miller (dan at on2 dot com) for clarifications on pieces of the
+format.
+
+Timothy B. Terriberry (tterribe at vt dot edu) for clarification about the
+differences between VP3 and Theora, detailed explanation of motion
+vector mechanics.
+
+
+References
+----------
+Tables necessary for decoding VP3:
+http://mplayerhq.hu/cgi-bin/cvsweb.cgi/~checkout~/ffmpeg/libavcodec/vp3data.h?content-type=text/x-cvsweb-markup&cvsroot=FFMpeg
+
+Official VP3 site:
+http://www.vp3.com/
+
+Theora, based on VP3:
+http://www.theora.org/
+
+On2, creators of the VP3 format:
+http://www.on2.com/
+
+
+ChangeLog
+---------
+v0.5: December 8, 2004
+- reworked section "Reversing The DC Prediction" to include a tabular
+representation of all 16 prediction modes
+
+v0.4: March 2, 2004
+- renamed and expanded section "Initializing The Quantization Matrices"
+- outlined section "Reconstructing The Frame"
+- moved Theora Differences Appendix to its own section entitled "Theora
+Specification"
+- added Appendix: Quantization Matrices And Scale Factors
+- added Appendix: DCT Coefficient VLC Tables
+
+v0.3: February 29, 2004
+- expanded section "Unpacking The Macroblock Coding Mode Information"
+- expanded section "Unpacking The Macroblock Motion Vectors"
+- added Appendix: Macroblock Coding Mode Alphabets
+
+v0.2: October 9, 2003
+- expanded section "Reversing the DC Prediction"
+- added Appendix: Theora Differences
+
+v0.1: June 17, 2003
+- initial release, nowhere near complete
diff --git a/libs/libtheora-1.1/examples/Makefile.am b/libs/libtheora-1.1/examples/Makefile.am
new file mode 100644
index 00000000..93ff45d3
--- /dev/null
+++ b/libs/libtheora-1.1/examples/Makefile.am
@@ -0,0 +1,41 @@
+## Process this file with automake to produce Makefile.in
+
+INCLUDES = -I$(top_srcdir)/include
+
+noinst_PROGRAMS = dump_video dump_psnr $(BUILDABLE_EXAMPLES)
+
+# possible contents of BUILDABLE_EXAMPLES:
+EXTRA_PROGRAMS = player_example encoder_example png2theora
+
+AM_CFLAGS = $(OGG_CFLAGS)
+LDADD = ../lib/libtheora.la $(OGG_LIBS)
+LDADDDEC = ../lib/libtheoradec.la $(OGG_LIBS)
+LDADDENC = ../lib/libtheoraenc.la ../lib/libtheoradec.la $(OGG_LIBS)
+
+dump_video_SOURCES = dump_video.c
+EXTRA_dump_video_SOURCES = getopt.c getopt1.c getopt.h
+dump_video_LDADD = $(GETOPT_OBJS) $(LDADDDEC)
+
+dump_psnr_SOURCES = dump_psnr.c
+EXTRA_dump_psnr_SOURCES = getopt.c getopt1.c getopt.h
+dump_psnr_LDADD = $(GETOPT_OBJS) $(LDADDDEC) -lm
+
+player_example_SOURCES = player_example.c
+player_example_CFLAGS = $(SDL_CFLAGS) $(OGG_CFLAGS) $(VORBIS_CFLAGS)
+player_example_LDADD = $(LDADDDEC) $(SDL_LIBS) $(VORBIS_LIBS) $(OSS_LIBS)
+
+encoder_example_SOURCES = encoder_example.c
+EXTRA_encoder_example_SOURCES = getopt.c getopt1.c getopt.h
+encoder_example_CFLAGS = $(OGG_CFLAGS) $(VORBIS_CFLAGS)
+encoder_example_LDADD = $(GETOPT_OBJS) $(LDADDENC) $(VORBIS_LIBS) $(VORBISENC_LIBS) -lm
+
+png2theora_SOURCES = png2theora.c
+png2theora_CFLAGS = $(OGG_CFLAGS) $(PNG_CFLAGS)
+png2theora_LDADD = $(GETOPT_OBJS) $(LDADDENC) $(PNG_LIBS) -lm
+
+debug:
+ $(MAKE) all CFLAGS="@DEBUG@"
+
+profile:
+ $(MAKE) all CFLAGS="@PROFILE@"
+
diff --git a/libs/libtheora-1.1/examples/README_SPLAYER b/libs/libtheora-1.1/examples/README_SPLAYER
new file mode 100644
index 00000000..1a32fb46
--- /dev/null
+++ b/libs/libtheora-1.1/examples/README_SPLAYER
@@ -0,0 +1,21 @@
+06/09/03 - by mau (mauricio at xiph.org)
+
+The splayer example is a experimental simple Theora player using SDL and
+Portaudio for cross platform compatibility. To build the windows version
+please use the Visual C++ project available at the
+win32/experimental/splayer directory.
+
+By default this sample will not be built on Linux, unless Portaudio is
+properly installed. Follow these steps to install Portaudio:
+
+1) Get portaudio tar package from www.portaudio.com
+2) Uncompress it to a local directory
+3) Run './configure' in the portaudio directory
+4) Run 'make install'
+
+This will install Portaudio libraries in /usr/local/lib, and the Portaudio
+include file at /usr/local/include. On linux you may need to manually
+execute 'ldconfig' to rebuild the library cache.
+
+Switch to theora's directory, re-run theora's autogen.sh script to
+re-generate the appropriate makefiles, and 'make install' to build.
diff --git a/libs/libtheora-1.1/examples/dump_psnr.c b/libs/libtheora-1.1/examples/dump_psnr.c
new file mode 100644
index 00000000..06f71721
--- /dev/null
+++ b/libs/libtheora-1.1/examples/dump_psnr.c
@@ -0,0 +1,1210 @@
+/********************************************************************
+ * *
+ * THIS FILE IS PART OF THE OggTheora SOFTWARE CODEC SOURCE CODE. *
+ * USE, DISTRIBUTION AND REPRODUCTION OF THIS LIBRARY SOURCE IS *
+ * GOVERNED BY A BSD-STYLE SOURCE LICENSE INCLUDED WITH THIS SOURCE *
+ * IN 'COPYING'. PLEASE READ THESE TERMS BEFORE DISTRIBUTING. *
+ * *
+ * THE Theora SOURCE CODE IS COPYRIGHT (C) 2002-2009 *
+ * by the Xiph.Org Foundation and contributors http://www.xiph.org/ *
+ * *
+ ********************************************************************
+
+ function: example dumpvid application; dumps Theora streams
+ last mod: $Id: dump_psnr.c 17974 2011-05-07 22:31:49Z giles $
+
+ ********************************************************************/
+
+#if !defined(_GNU_SOURCE)
+#define _GNU_SOURCE
+#endif
+#if !defined(_LARGEFILE_SOURCE)
+#define _LARGEFILE_SOURCE
+#endif
+#if !defined(_LARGEFILE64_SOURCE)
+#define _LARGEFILE64_SOURCE
+#endif
+#if !defined(_FILE_OFFSET_BITS)
+#define _FILE_OFFSET_BITS 64
+#endif
+
+#include
+#if !defined(_WIN32)
+#include
+#include
+#else
+#include "getopt.h"
+#endif
+#include
+#include
+#include
+#include
+#include
+/*Yes, yes, we're going to hell.*/
+#if defined(_WIN32)
+#include
+#endif
+#include
+#include
+#include
+#include "theora/theoradec.h"
+
+const char *optstring = "fsy";
+struct option options [] = {
+ {"frame-type",no_argument,NULL,'f'},
+ {"summary",no_argument,NULL,'s'},
+ {"luma-only",no_argument,NULL,'y'},
+ {NULL,0,NULL,0}
+};
+
+static int show_frame_type;
+static int summary_only;
+static int luma_only;
+
+typedef struct y4m_input y4m_input;
+
+/*The function used to perform chroma conversion.*/
+typedef void (*y4m_convert_func)(y4m_input *_y4m,
+ unsigned char *_dst,unsigned char *_aux);
+
+struct y4m_input{
+ int frame_w;
+ int frame_h;
+ int pic_w;
+ int pic_h;
+ int pic_x;
+ int pic_y;
+ int fps_n;
+ int fps_d;
+ int par_n;
+ int par_d;
+ char interlace;
+ int src_c_dec_h;
+ int src_c_dec_v;
+ int dst_c_dec_h;
+ int dst_c_dec_v;
+ char chroma_type[16];
+ /*The size of each converted frame buffer.*/
+ size_t dst_buf_sz;
+ /*The amount to read directly into the converted frame buffer.*/
+ size_t dst_buf_read_sz;
+ /*The size of the auxilliary buffer.*/
+ size_t aux_buf_sz;
+ /*The amount to read into the auxilliary buffer.*/
+ size_t aux_buf_read_sz;
+ y4m_convert_func convert;
+ unsigned char *dst_buf;
+ unsigned char *aux_buf;
+};
+
+
+static int y4m_parse_tags(y4m_input *_y4m,char *_tags){
+ int got_w;
+ int got_h;
+ int got_fps;
+ int got_interlace;
+ int got_par;
+ int got_chroma;
+ char *p;
+ char *q;
+ got_w=got_h=got_fps=got_interlace=got_par=got_chroma=0;
+ for(p=_tags;;p=q){
+ /*Skip any leading spaces.*/
+ while(*p==' ')p++;
+ /*If that's all we have, stop.*/
+ if(p[0]=='\0')break;
+ /*Find the end of this tag.*/
+ for(q=p+1;*q!='\0'&&*q!=' ';q++);
+ /*Process the tag.*/
+ switch(p[0]){
+ case 'W':{
+ if(sscanf(p+1,"%d",&_y4m->pic_w)!=1)return -1;
+ got_w=1;
+ }break;
+ case 'H':{
+ if(sscanf(p+1,"%d",&_y4m->pic_h)!=1)return -1;
+ got_h=1;
+ }break;
+ case 'F':{
+ if(sscanf(p+1,"%d:%d",&_y4m->fps_n,&_y4m->fps_d)!=2){
+ return -1;
+ }
+ got_fps=1;
+ }break;
+ case 'I':{
+ _y4m->interlace=p[1];
+ got_interlace=1;
+ }break;
+ case 'A':{
+ if(sscanf(p+1,"%d:%d",&_y4m->par_n,&_y4m->par_d)!=2){
+ return -1;
+ }
+ got_par=1;
+ }break;
+ case 'C':{
+ if(q-p>16)return -1;
+ memcpy(_y4m->chroma_type,p+1,q-p-1);
+ _y4m->chroma_type[q-p-1]='\0';
+ got_chroma=1;
+ }break;
+ /*Ignore unknown tags.*/
+ }
+ }
+ if(!got_w||!got_h||!got_fps||!got_interlace||!got_par)return -1;
+ /*Chroma-type is not specified in older files, e.g., those generated by
+ mplayer.*/
+ if(!got_chroma)strcpy(_y4m->chroma_type,"420");
+ return 0;
+}
+
+/*All anti-aliasing filters in the following conversion functions are based on
+ one of two window functions:
+ The 6-tap Lanczos window (for down-sampling and shifts):
+ sinc(\pi*t)*sinc(\pi*t/3), |t|<3 (sinc(t)==sin(t)/t)
+ 0, |t|>=3
+ The 4-tap Mitchell window (for up-sampling):
+ 7|t|^3-12|t|^2+16/3, |t|<1
+ -(7/3)|x|^3+12|x|^2-20|x|+32/3, |t|<2
+ 0, |t|>=2
+ The number of taps is intentionally kept small to reduce computational
+ overhead and limit ringing.
+
+ The taps from these filters are scaled so that their sum is 1, and the result
+ is scaled by 128 and rounded to integers to create a filter whose
+ intermediate values fit inside 16 bits.
+ Coefficients are rounded in such a way as to ensure their sum is still 128,
+ which is usually equivalent to normal rounding.*/
+
+#define OC_MINI(_a,_b) ((_a)>(_b)?(_b):(_a))
+#define OC_MAXI(_a,_b) ((_a)<(_b)?(_b):(_a))
+#define OC_CLAMPI(_a,_b,_c) (OC_MAXI(_a,OC_MINI(_b,_c)))
+
+/*420jpeg chroma samples are sited like:
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | BR | | BR |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | BR | | BR |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+
+ 420mpeg2 chroma samples are sited like:
+ Y-------Y-------Y-------Y-------
+ | | | |
+ BR | BR |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ BR | BR |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+
+ We use a resampling filter to shift the site locations one quarter pixel (at
+ the chroma plane's resolution) to the right.
+ The 4:2:2 modes look exactly the same, except there are twice as many chroma
+ lines, and they are vertically co-sited with the luma samples in both the
+ mpeg2 and jpeg cases (thus requiring no vertical resampling).*/
+static void y4m_convert_42xmpeg2_42xjpeg(y4m_input *_y4m,unsigned char *_dst,
+ unsigned char *_aux){
+ int c_w;
+ int c_h;
+ int pli;
+ int y;
+ int x;
+ /*Skip past the luma data.*/
+ _dst+=_y4m->pic_w*_y4m->pic_h;
+ /*Compute the size of each chroma plane.*/
+ c_w=(_y4m->pic_w+_y4m->dst_c_dec_h-1)/_y4m->dst_c_dec_h;
+ c_h=(_y4m->pic_h+_y4m->dst_c_dec_v-1)/_y4m->dst_c_dec_v;
+ for(pli=1;pli<3;pli++){
+ for(y=0;y>7,255);
+ }
+ for(;x>7,255);
+ }
+ for(;x>7,255);
+ }
+ _dst+=c_w;
+ _aux+=c_w;
+ }
+ }
+}
+
+/*This format is only used for interlaced content, but is included for
+ completeness.
+
+ 420jpeg chroma samples are sited like:
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | BR | | BR |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | BR | | BR |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+
+ 420paldv chroma samples are sited like:
+ YR------Y-------YR------Y-------
+ | | | |
+ | | | |
+ | | | |
+ YB------Y-------YB------Y-------
+ | | | |
+ | | | |
+ | | | |
+ YR------Y-------YR------Y-------
+ | | | |
+ | | | |
+ | | | |
+ YB------Y-------YB------Y-------
+ | | | |
+ | | | |
+ | | | |
+
+ We use a resampling filter to shift the site locations one quarter pixel (at
+ the chroma plane's resolution) to the right.
+ Then we use another filter to move the C_r location down one quarter pixel,
+ and the C_b location up one quarter pixel.*/
+static void y4m_convert_42xpaldv_42xjpeg(y4m_input *_y4m,unsigned char *_dst,
+ unsigned char *_aux){
+ unsigned char *tmp;
+ int c_w;
+ int c_h;
+ int c_sz;
+ int pli;
+ int y;
+ int x;
+ /*Skip past the luma data.*/
+ _dst+=_y4m->pic_w*_y4m->pic_h;
+ /*Compute the size of each chroma plane.*/
+ c_w=(_y4m->pic_w+1)/2;
+ c_h=(_y4m->pic_h+_y4m->dst_c_dec_h-1)/_y4m->dst_c_dec_h;
+ c_sz=c_w*c_h;
+ /*First do the horizontal re-sampling.
+ This is the same as the mpeg2 case, except that after the horizontal case,
+ we need to apply a second vertical filter.*/
+ tmp=_aux+2*c_sz;
+ for(pli=1;pli<3;pli++){
+ for(y=0;y>7,255);
+ }
+ for(;x>7,255);
+ }
+ for(;x>7,255);
+ }
+ tmp+=c_w;
+ _aux+=c_w;
+ }
+ switch(pli){
+ case 1:{
+ tmp-=c_sz;
+ /*Slide C_b up a quarter-pel.
+ This is the same filter used above, but in the other order.*/
+ for(x=0;x>7,255);
+ }
+ for(;y>7,255);
+ }
+ for(;y>7,255);
+ }
+ _dst++;
+ tmp++;
+ }
+ _dst+=c_sz-c_w;
+ tmp-=c_w;
+ }break;
+ case 2:{
+ tmp-=c_sz;
+ /*Slide C_r down a quarter-pel.
+ This is the same as the horizontal filter.*/
+ for(x=0;x>7,255);
+ }
+ for(;y>7,255);
+ }
+ for(;y>7,255);
+ }
+ _dst++;
+ tmp++;
+ }
+ }break;
+ }
+ /*For actual interlaced material, this would have to be done separately on
+ each field, and the shift amounts would be different.
+ C_r moves down 1/8, C_b up 3/8 in the top field, and C_r moves down 3/8,
+ C_b up 1/8 in the bottom field.
+ The corresponding filters would be:
+ Down 1/8 (reverse order for up): [3 -11 125 15 -4 0]/128
+ Down 3/8 (reverse order for up): [4 -19 98 56 -13 2]/128*/
+ }
+}
+
+/*422jpeg chroma samples are sited like:
+ Y---BR--Y-------Y---BR--Y-------
+ | | | |
+ | | | |
+ | | | |
+ Y---BR--Y-------Y---BR--Y-------
+ | | | |
+ | | | |
+ | | | |
+ Y---BR--Y-------Y---BR--Y-------
+ | | | |
+ | | | |
+ | | | |
+ Y---BR--Y-------Y---BR--Y-------
+ | | | |
+ | | | |
+ | | | |
+
+ 411 chroma samples are sited like:
+ YBR-----Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+ YBR-----Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+ YBR-----Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+ YBR-----Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+
+ We use a filter to resample at site locations one eighth pixel (at the source
+ chroma plane's horizontal resolution) and five eighths of a pixel to the
+ right.*/
+static void y4m_convert_411_422jpeg(y4m_input *_y4m,unsigned char *_dst,
+ unsigned char *_aux){
+ int c_w;
+ int dst_c_w;
+ int c_h;
+ int pli;
+ int y;
+ int x;
+ /*Skip past the luma data.*/
+ _dst+=_y4m->pic_w*_y4m->pic_h;
+ /*Compute the size of each chroma plane.*/
+ c_w=(_y4m->pic_w+_y4m->src_c_dec_h-1)/_y4m->src_c_dec_h;
+ dst_c_w=(_y4m->pic_w+_y4m->dst_c_dec_h-1)/_y4m->dst_c_dec_h;
+ c_h=(_y4m->pic_h+_y4m->dst_c_dec_v-1)/_y4m->dst_c_dec_v;
+ for(pli=1;pli<3;pli++){
+ for(y=0;y>7,255);
+ _dst[x<<1|1]=(unsigned char)OC_CLAMPI(0,47*_aux[0]+
+ 86*_aux[OC_MINI(1,c_w-1)]-5*_aux[OC_MINI(2,c_w-1)]+64>>7,255);
+ }
+ for(;x>7,255);
+ _dst[x<<1|1]=(unsigned char)OC_CLAMPI(0,-3*_aux[x-1]+50*_aux[x]+
+ 86*_aux[x+1]-5*_aux[x+2]+64>>7,255);
+ }
+ for(;x>7,255);
+ if((x<<1|1)>7,255);
+ }
+ }
+ _dst+=dst_c_w;
+ _aux+=c_w;
+ }
+ }
+}
+
+/*The image is padded with empty chroma components at 4:2:0.
+ This costs about 17 bits a frame to code.*/
+static void y4m_convert_mono_420jpeg(y4m_input *_y4m,unsigned char *_dst,
+ unsigned char *_aux){
+ int c_sz;
+ _dst+=_y4m->pic_w*_y4m->pic_h;
+ c_sz=((_y4m->pic_w+_y4m->dst_c_dec_h-1)/_y4m->dst_c_dec_h)*
+ ((_y4m->pic_h+_y4m->dst_c_dec_v-1)/_y4m->dst_c_dec_v);
+ memset(_dst,128,c_sz*2);
+}
+
+#if 0
+/*Right now just 444 to 420.
+ Not too hard to generalize.*/
+static void y4m_convert_4xxjpeg_42xjpeg(y4m_input *_y4m,unsigned char *_dst,
+ unsigned char *_aux){
+ unsigned char *tmp;
+ int c_w;
+ int c_h;
+ int pic_sz;
+ int tmp_sz;
+ int c_sz;
+ int pli;
+ int y;
+ int x;
+ /*Compute the size of each chroma plane.*/
+ c_w=(_y4m->pic_w+_y4m->dst_c_dec_h-1)/_y4m->dst_c_dec_h;
+ c_h=(_y4m->pic_h+_y4m->dst_c_dec_v-1)/_y4m->dst_c_dec_v;
+ pic_sz=_y4m->pic_w*_y4m->pic_h;
+ tmp_sz=c_w*_y4m->pic_h;
+ c_sz=c_w*c_h;
+ _dst+=pic_sz;
+ for(pli=1;pli<3;pli++){
+ tmp=_aux+pic_sz;
+ /*In reality, the horizontal and vertical steps could be pipelined, for
+ less memory consumption and better cache performance, but we do them
+ separately for simplicity.*/
+ /*First do horizontal filtering (convert to 4:2:2)*/
+ /*Filter: [3 -17 78 78 -17 3]/128, derived from a 6-tap Lanczos window.*/
+ for(y=0;y<_y4m->pic_h;y++){
+ for(x=0;xpic_w,2);x+=2){
+ tmp[x>>1]=OC_CLAMPI(0,64*_aux[0]+78*_aux[OC_MINI(1,_y4m->pic_w-1)]
+ -17*_aux[OC_MINI(2,_y4m->pic_w-1)]
+ +3*_aux[OC_MINI(3,_y4m->pic_w-1)]+64>>7,255);
+ }
+ for(;x<_y4m->pic_w-3;x+=2){
+ tmp[x>>1]=OC_CLAMPI(0,3*(_aux[x-2]+_aux[x+3])-17*(_aux[x-1]+_aux[x+2])+
+ 78*(_aux[x]+_aux[x+1])+64>>7,255);
+ }
+ for(;x<_y4m->pic_w;x+=2){
+ tmp[x>>1]=OC_CLAMPI(0,3*(_aux[x-2]+_aux[_y4m->pic_w-1])-
+ 17*(_aux[x-1]+_aux[OC_MINI(x+2,_y4m->pic_w-1)])+
+ 78*(_aux[x]+_aux[OC_MINI(x+1,_y4m->pic_w-1)])+64>>7,255);
+ }
+ tmp+=c_w;
+ _aux+=_y4m->pic_w;
+ }
+ _aux-=pic_sz;
+ tmp-=tmp_sz;
+ /*Now do the vertical filtering.*/
+ for(x=0;xpic_h,2);y+=2){
+ _dst[(y>>1)*c_w]=OC_CLAMPI(0,64*tmp[0]
+ +78*tmp[OC_MINI(1,_y4m->pic_h-1)*c_w]
+ -17*tmp[OC_MINI(2,_y4m->pic_h-1)*c_w]
+ +3*tmp[OC_MINI(3,_y4m->pic_h-1)*c_w]+64>>7,255);
+ }
+ for(;y<_y4m->pic_h-3;y+=2){
+ _dst[(y>>1)*c_w]=OC_CLAMPI(0,3*(tmp[(y-2)*c_w]+tmp[(y+3)*c_w])-
+ 17*(tmp[(y-1)*c_w]+tmp[(y+2)*c_w])+78*(tmp[y*c_w]+tmp[(y+1)*c_w])+
+ 64>>7,255);
+ }
+ for(;y<_y4m->pic_h;y+=2){
+ _dst[(y>>1)*c_w]=OC_CLAMPI(0,3*(tmp[(y-2)*c_w]
+ +tmp[(_y4m->pic_h-1)*c_w])-17*(tmp[(y-1)*c_w]
+ +tmp[OC_MINI(y+2,_y4m->pic_h-1)*c_w])
+ +78*(tmp[y*c_w]+tmp[OC_MINI(y+1,_y4m->pic_h-1)*c_w])+64>>7,255);
+ }
+ tmp++;
+ _dst++;
+ }
+ _dst-=c_w;
+ }
+}
+#endif
+
+/*No conversion function needed.*/
+static void y4m_convert_null(y4m_input *_y4m,unsigned char *_dst,
+ unsigned char *_aux){
+}
+
+static int y4m_input_open(y4m_input *_y4m,FILE *_fin,char *_skip,int _nskip){
+ char buffer[80];
+ int ret;
+ int i;
+ /*Read until newline, or 80 cols, whichever happens first.*/
+ for(i=0;i<79;i++){
+ if(_nskip>0){
+ buffer[i]=*_skip++;
+ _nskip--;
+ }
+ else{
+ ret=fread(buffer+i,1,1,_fin);
+ if(ret<1)return -1;
+ }
+ if(buffer[i]=='\n')break;
+ }
+ /*We skipped too much header data.*/
+ if(_nskip>0)return -1;
+ if(i==79){
+ fprintf(stderr,"Error parsing header; not a YUV2MPEG2 file?\n");
+ return -1;
+ }
+ buffer[i]='\0';
+ if(memcmp(buffer,"YUV4MPEG",8)){
+ fprintf(stderr,"Incomplete magic for YUV4MPEG file.\n");
+ return -1;
+ }
+ if(buffer[8]!='2'){
+ fprintf(stderr,"Incorrect YUV input file version; YUV4MPEG2 required.\n");
+ }
+ ret=y4m_parse_tags(_y4m,buffer+5);
+ if(ret<0){
+ fprintf(stderr,"Error parsing YUV4MPEG2 header.\n");
+ return ret;
+ }
+ if(_y4m->interlace!='p'){
+ fprintf(stderr,"Input video is interlaced; "
+ "Theora only handles progressive scan.\n");
+ return -1;
+ }
+ if(strcmp(_y4m->chroma_type,"420")==0||
+ strcmp(_y4m->chroma_type,"420jpeg")==0){
+ _y4m->src_c_dec_h=_y4m->dst_c_dec_h=_y4m->src_c_dec_v=_y4m->dst_c_dec_v=2;
+ _y4m->dst_buf_read_sz=_y4m->pic_w*_y4m->pic_h
+ +2*((_y4m->pic_w+1)/2)*((_y4m->pic_h+1)/2);
+ /*Natively supported: no conversion required.*/
+ _y4m->aux_buf_sz=_y4m->aux_buf_read_sz=0;
+ _y4m->convert=y4m_convert_null;
+ }
+ else if(strcmp(_y4m->chroma_type,"420mpeg2")==0){
+ _y4m->src_c_dec_h=_y4m->dst_c_dec_h=_y4m->src_c_dec_v=_y4m->dst_c_dec_v=2;
+ _y4m->dst_buf_read_sz=_y4m->pic_w*_y4m->pic_h;
+ /*Chroma filter required: read into the aux buf first.*/
+ _y4m->aux_buf_sz=_y4m->aux_buf_read_sz=
+ 2*((_y4m->pic_w+1)/2)*((_y4m->pic_h+1)/2);
+ _y4m->convert=y4m_convert_42xmpeg2_42xjpeg;
+ }
+ else if(strcmp(_y4m->chroma_type,"420paldv")==0){
+ _y4m->src_c_dec_h=_y4m->dst_c_dec_h=_y4m->src_c_dec_v=_y4m->dst_c_dec_v=2;
+ _y4m->dst_buf_read_sz=_y4m->pic_w*_y4m->pic_h;
+ /*Chroma filter required: read into the aux buf first.
+ We need to make two filter passes, so we need some extra space in the
+ aux buffer.*/
+ _y4m->aux_buf_sz=3*((_y4m->pic_w+1)/2)*((_y4m->pic_h+1)/2);
+ _y4m->aux_buf_read_sz=2*((_y4m->pic_w+1)/2)*((_y4m->pic_h+1)/2);
+ _y4m->convert=y4m_convert_42xpaldv_42xjpeg;
+ }
+ else if(strcmp(_y4m->chroma_type,"422")==0){
+ _y4m->src_c_dec_h=_y4m->dst_c_dec_h=2;
+ _y4m->src_c_dec_v=_y4m->dst_c_dec_v=1;
+ _y4m->dst_buf_read_sz=_y4m->pic_w*_y4m->pic_h;
+ /*Chroma filter required: read into the aux buf first.*/
+ _y4m->aux_buf_sz=_y4m->aux_buf_read_sz=2*((_y4m->pic_w+1)/2)*_y4m->pic_h;
+ _y4m->convert=y4m_convert_42xmpeg2_42xjpeg;
+ }
+ else if(strcmp(_y4m->chroma_type,"422jpeg")==0){
+ _y4m->src_c_dec_h=_y4m->dst_c_dec_h=2;
+ _y4m->src_c_dec_v=_y4m->dst_c_dec_v=1;
+ _y4m->dst_buf_read_sz=_y4m->pic_w*_y4m->pic_h
+ +2*((_y4m->pic_w+1)/2)*_y4m->pic_h;
+ /*Natively supported: no conversion required.*/
+ _y4m->aux_buf_sz=_y4m->aux_buf_read_sz=0;
+ _y4m->convert=y4m_convert_null;
+ }
+ else if(strcmp(_y4m->chroma_type,"411")==0){
+ _y4m->src_c_dec_h=4;
+ /*We don't want to introduce any additional sub-sampling, so we
+ promote 4:1:1 material to 4:2:2, as the closest format Theora can
+ handle.*/
+ _y4m->dst_c_dec_h=2;
+ _y4m->src_c_dec_v=_y4m->dst_c_dec_v=1;
+ _y4m->dst_buf_read_sz=_y4m->pic_w*_y4m->pic_h;
+ /*Chroma filter required: read into the aux buf first.*/
+ _y4m->aux_buf_sz=_y4m->aux_buf_read_sz=2*((_y4m->pic_w+3)/4)*_y4m->pic_h;
+ _y4m->convert=y4m_convert_411_422jpeg;
+ }
+ else if(strcmp(_y4m->chroma_type,"444")==0){
+ _y4m->src_c_dec_h=_y4m->dst_c_dec_h=_y4m->src_c_dec_v=_y4m->dst_c_dec_v=1;
+ _y4m->dst_buf_read_sz=_y4m->pic_w*_y4m->pic_h*3;
+ /*Natively supported: no conversion required.*/
+ _y4m->aux_buf_sz=_y4m->aux_buf_read_sz=0;
+ _y4m->convert=y4m_convert_null;
+ }
+ else if(strcmp(_y4m->chroma_type,"444alpha")==0){
+ _y4m->src_c_dec_h=_y4m->dst_c_dec_h=_y4m->src_c_dec_v=_y4m->dst_c_dec_v=1;
+ _y4m->dst_buf_read_sz=_y4m->pic_w*_y4m->pic_h*3;
+ /*Read the extra alpha plane into the aux buf.
+ It will be discarded.*/
+ _y4m->aux_buf_sz=_y4m->aux_buf_read_sz=_y4m->pic_w*_y4m->pic_h;
+ _y4m->convert=y4m_convert_null;
+ }
+ else if(strcmp(_y4m->chroma_type,"mono")==0){
+ _y4m->src_c_dec_h=_y4m->src_c_dec_v=0;
+ _y4m->dst_c_dec_h=_y4m->dst_c_dec_v=2;
+ _y4m->dst_buf_read_sz=_y4m->pic_w*_y4m->pic_h;
+ /*No extra space required, but we need to clear the chroma planes.*/
+ _y4m->aux_buf_sz=_y4m->aux_buf_read_sz=0;
+ _y4m->convert=y4m_convert_mono_420jpeg;
+ }
+ else{
+ fprintf(stderr,"Unknown chroma sampling type: %s\n",_y4m->chroma_type);
+ return -1;
+ }
+ /*The size of the final frame buffers is always computed from the
+ destination chroma decimation type.*/
+ _y4m->dst_buf_sz=_y4m->pic_w*_y4m->pic_h
+ +2*((_y4m->pic_w+_y4m->dst_c_dec_h-1)/_y4m->dst_c_dec_h)*
+ ((_y4m->pic_h+_y4m->dst_c_dec_v-1)/_y4m->dst_c_dec_v);
+ /*Scale the picture size up to a multiple of 16.*/
+ _y4m->frame_w=_y4m->pic_w+15&~0xF;
+ _y4m->frame_h=_y4m->pic_h+15&~0xF;
+ /*Force the offsets to be even so that chroma samples line up like we
+ expect.*/
+ _y4m->pic_x=_y4m->frame_w-_y4m->pic_w>>1&~1;
+ _y4m->pic_y=_y4m->frame_h-_y4m->pic_h>>1&~1;
+ _y4m->dst_buf=(unsigned char *)malloc(_y4m->dst_buf_sz);
+ _y4m->aux_buf=(unsigned char *)malloc(_y4m->aux_buf_sz);
+ return 0;
+}
+
+static void y4m_input_get_info(y4m_input *_y4m,th_info *_ti){
+ _ti->frame_width=_y4m->frame_w;
+ _ti->frame_height=_y4m->frame_h;
+ _ti->pic_width=_y4m->pic_w;
+ _ti->pic_height=_y4m->pic_h;
+ _ti->pic_x=_y4m->pic_x;
+ _ti->pic_y=_y4m->pic_y;
+ _ti->fps_numerator=_y4m->fps_n;
+ _ti->fps_denominator=_y4m->fps_d;
+ _ti->aspect_numerator=_y4m->par_n;
+ _ti->aspect_denominator=_y4m->par_d;
+ _ti->pixel_fmt=_y4m->dst_c_dec_h==2?
+ (_y4m->dst_c_dec_v==2?TH_PF_420:TH_PF_422):TH_PF_444;
+}
+
+static int y4m_input_fetch_frame(y4m_input *_y4m,FILE *_fin,
+ th_ycbcr_buffer _ycbcr){
+ char frame[6];
+ int pic_sz;
+ int frame_c_w;
+ int frame_c_h;
+ int c_w;
+ int c_h;
+ int c_sz;
+ int ret;
+ pic_sz=_y4m->pic_w*_y4m->pic_h;
+ frame_c_w=_y4m->frame_w/_y4m->dst_c_dec_h;
+ frame_c_h=_y4m->frame_h/_y4m->dst_c_dec_v;
+ c_w=(_y4m->pic_w+_y4m->dst_c_dec_h-1)/_y4m->dst_c_dec_h;
+ c_h=(_y4m->pic_h+_y4m->dst_c_dec_v-1)/_y4m->dst_c_dec_v;
+ c_sz=c_w*c_h;
+ /*Read and skip the frame header.*/
+ ret=fread(frame,1,6,_fin);
+ if(ret<6)return 0;
+ if(memcmp(frame,"FRAME",5)){
+ fprintf(stderr,"Loss of framing in YUV input data\n");
+ exit(1);
+ }
+ if(frame[5]!='\n'){
+ char c;
+ int j;
+ for(j=0;j<79&&fread(&c,1,1,_fin)&&c!='\n';j++);
+ if(j==79){
+ fprintf(stderr,"Error parsing YUV frame header\n");
+ return -1;
+ }
+ }
+ /*Read the frame data that needs no conversion.*/
+ if(fread(_y4m->dst_buf,1,_y4m->dst_buf_read_sz,_fin)!=_y4m->dst_buf_read_sz){
+ fprintf(stderr,"Error reading YUV frame data.\n");
+ return -1;
+ }
+ /*Read the frame data that does need conversion.*/
+ if(fread(_y4m->aux_buf,1,_y4m->aux_buf_read_sz,_fin)!=_y4m->aux_buf_read_sz){
+ fprintf(stderr,"Error reading YUV frame data.\n");
+ return -1;
+ }
+ /*Now convert the just read frame.*/
+ (*_y4m->convert)(_y4m,_y4m->dst_buf,_y4m->aux_buf);
+ /*Fill in the frame buffer pointers.*/
+ _ycbcr[0].width=_y4m->frame_w;
+ _ycbcr[0].height=_y4m->frame_h;
+ _ycbcr[0].stride=_y4m->pic_w;
+ _ycbcr[0].data=_y4m->dst_buf-_y4m->pic_x-_y4m->pic_y*_y4m->pic_w;
+ _ycbcr[1].width=frame_c_w;
+ _ycbcr[1].height=frame_c_h;
+ _ycbcr[1].stride=c_w;
+ _ycbcr[1].data=_y4m->dst_buf+pic_sz-(_y4m->pic_x/_y4m->dst_c_dec_h)-
+ (_y4m->pic_y/_y4m->dst_c_dec_v)*c_w;
+ _ycbcr[2].width=frame_c_w;
+ _ycbcr[2].height=frame_c_h;
+ _ycbcr[2].stride=c_w;
+ _ycbcr[2].data=_ycbcr[1].data+c_sz;
+ return 1;
+}
+
+static void y4m_input_close(y4m_input *_y4m){
+ free(_y4m->dst_buf);
+ free(_y4m->aux_buf);
+}
+
+
+
+typedef struct th_input th_input;
+
+struct th_input{
+ ogg_sync_state oy;
+ int theora_p;
+ ogg_stream_state to;
+ th_info ti;
+ th_comment tc;
+ th_dec_ctx *td;
+};
+
+
+
+/*Grab some more compressed bitstream and sync it for page extraction.*/
+static int th_input_buffer_data(th_input *_th,FILE *_fin){
+ char *buffer;
+ int bytes;
+ buffer=ogg_sync_buffer(&_th->oy,4096);
+ bytes=fread(buffer,1,4096,_fin);
+ ogg_sync_wrote(&_th->oy,bytes);
+ return bytes;
+}
+
+/*Push a page into the appropriate steam.
+ This can be done blindly; a stream won't accept a page that doesn't belong to
+ it.*/
+static void th_input_queue_page(th_input *_th,ogg_page *_og){
+ if(_th->theora_p)ogg_stream_pagein(&_th->to,_og);
+}
+
+static int th_input_open_impl(th_input *_th,th_setup_info **_ts,FILE *_fin,
+ char *_sig,int _nsig){
+ ogg_packet op;
+ ogg_page og;
+ int nheaders_left;
+ int done_headers;
+ ogg_sync_init(&_th->oy);
+ th_info_init(&_th->ti);
+ th_comment_init(&_th->tc);
+ *_ts=NULL;
+ /*Buffer any initial data read for file ID.*/
+ if(_nsig>0){
+ char *buffer;
+ buffer=ogg_sync_buffer(&_th->oy,_nsig);
+ memcpy(buffer,_sig,_nsig);
+ ogg_sync_wrote(&_th->oy,_nsig);
+ }
+ _th->theora_p=0;
+ nheaders_left=0;
+ for(done_headers=0;!done_headers;){
+ if(th_input_buffer_data(_th,_fin)==0)break;
+ while(ogg_sync_pageout(&_th->oy,&og)>0){
+ ogg_stream_state test;
+ /*Is this a mandated initial header?
+ If not, stop parsing.*/
+ if(!ogg_page_bos(&og)){
+ /*Don't leak the page; get it into the appropriate stream.*/
+ th_input_queue_page(_th,&og);
+ done_headers=1;
+ break;
+ }
+ ogg_stream_init(&test,ogg_page_serialno(&og));
+ ogg_stream_pagein(&test,&og);
+ ogg_stream_packetpeek(&test,&op);
+ /*Identify the codec: try Theora.*/
+ if(!_th->theora_p){
+ nheaders_left=th_decode_headerin(&_th->ti,&_th->tc,_ts,&op);
+ if(nheaders_left>=0){
+ /*It is Theora.*/
+ memcpy(&_th->to,&test,sizeof(test));
+ _th->theora_p=1;
+ /*Advance past the successfully processed header.*/
+ if(nheaders_left>0)ogg_stream_packetout(&_th->to,NULL);
+ continue;
+ }
+ }
+ /*Whatever it is, we don't care about it.*/
+ ogg_stream_clear(&test);
+ }
+ }
+ /*We're expecting more header packets.*/
+ while(_th->theora_p&&nheaders_left>0){
+ int ret;
+ while(nheaders_left>0){
+ ret=ogg_stream_packetpeek(&_th->to,&op);
+ if(ret==0)break;
+ if(ret<0)continue;
+ nheaders_left=th_decode_headerin(&_th->ti,&_th->tc,_ts,&op);
+ if(nheaders_left<0){
+ fprintf(stderr,"Error parsing Theora stream headers; "
+ "corrupt stream?\n");
+ return -1;
+ }
+ /*Advance past the successfully processed header.*/
+ else if(nheaders_left>0)ogg_stream_packetout(&_th->to,NULL);
+ _th->theora_p++;
+ }
+ /*Stop now so we don't fail if there aren't enough pages in a short
+ stream.*/
+ if(!(_th->theora_p&&nheaders_left>0))break;
+ /*The header pages/packets will arrive before anything else we care
+ about, or the stream is not obeying spec.*/
+ if(ogg_sync_pageout(&_th->oy,&og)>0)th_input_queue_page(_th,&og);
+ /*We need more data.*/
+ else if(th_input_buffer_data(_th,_fin)==0){
+ fprintf(stderr,"End of file while searching for codec headers.\n");
+ return -1;
+ }
+ }
+ /*And now we have it all.
+ Initialize the decoder.*/
+ if(_th->theora_p){
+ _th->td=th_decode_alloc(&_th->ti,*_ts);
+ if(_th->td!=NULL){
+ fprintf(stderr,"Ogg logical stream %lx is Theora %ix%i %.02f fps video.\n"
+ "Encoded frame content is %ix%i with %ix%i offset.\n",
+ _th->to.serialno,_th->ti.frame_width,_th->ti.frame_height,
+ (double)_th->ti.fps_numerator/_th->ti.fps_denominator,
+ _th->ti.pic_width,_th->ti.pic_height,_th->ti.pic_x,_th->ti.pic_y);
+ return 1;
+ }
+ }
+ return -1;
+}
+
+static void th_input_close(th_input *_th){
+ if(_th->theora_p){
+ ogg_stream_clear(&_th->to);
+ th_decode_free(_th->td);
+ }
+ th_comment_clear(&_th->tc);
+ th_info_clear(&_th->ti);
+ ogg_sync_clear(&_th->oy);
+}
+
+static int th_input_open(th_input *_th,FILE *_fin,char *_sig,int _nsig){
+ th_input th;
+ th_setup_info *ts;
+ int ret;
+ ret=th_input_open_impl(&th,&ts,_fin,_sig,_nsig);
+ th_setup_free(ts);
+ /*Clean up on failure.*/
+ if(ret<0)th_input_close(&th);
+ else memcpy(_th,&th,sizeof(th));
+ return ret;
+}
+
+static void th_input_get_info(th_input *_th,th_info *_ti){
+ memcpy(_ti,&_th->ti,sizeof(*_ti));
+}
+
+static int th_input_fetch_frame(th_input *_th,FILE *_fin,
+ th_ycbcr_buffer _ycbcr){
+ for(;;){
+ ogg_page og;
+ ogg_packet op;
+ if(ogg_stream_packetout(&_th->to,&op)>0){
+ if(th_decode_packetin(_th->td,&op,NULL)>=0){
+ th_decode_ycbcr_out(_th->td,_ycbcr);
+ if(!summary_only&&show_frame_type){
+ printf("%c",th_packet_iskeyframe(&op)?'K':'D');
+ if(op.bytes>0)printf("%02i ",op.packet[0]&0x3F);
+ else printf("-- ");
+ }
+ return 1;
+ }
+ else return -1;
+ }
+ while(ogg_sync_pageout(&_th->oy,&og)<=0){
+ if(th_input_buffer_data(_th,_fin)==0)return feof(_fin)?0:-1;
+ }
+ th_input_queue_page(_th,&og);
+ }
+}
+
+
+
+typedef struct video_input video_input;
+typedef void (*video_input_get_info_func)(void *_ctx,th_info *_ti);
+typedef int (*video_input_fetch_frame_func)(void *_ctx,FILE *_fin,
+ th_ycbcr_buffer _ycbcr);
+typedef void (*video_input_close_func)(void *_ctx);
+
+struct video_input{
+ FILE *fin;
+ video_input_get_info_func get_info;
+ video_input_fetch_frame_func fetch_frame;
+ video_input_close_func close;
+ union{
+ y4m_input y4m;
+ th_input th;
+ }ctx;
+};
+
+static int video_input_open(video_input *_vid,FILE *_fin){
+ char buffer[4];
+ int ret;
+ /* look for magic */
+ ret=fread(buffer,1,4,_fin);
+ if(ret<4)fprintf(stderr,"EOF determining file type of file.\n");
+ else{
+ if(!memcmp(buffer,"YUV4",4)){
+ if(y4m_input_open(&_vid->ctx.y4m,_fin,buffer,4)>=0){
+ /*fprintf(stderr,"Original %s is %dx%d %.02f fps %s video.\n",
+ f,_y4m->pic_w,_y4m->pic_h,(double)_y4m->fps_n/_y4m->fps_d,_y4m->chroma_type);*/
+ _vid->fin=_fin;
+ _vid->get_info=(video_input_get_info_func)y4m_input_get_info;
+ _vid->fetch_frame=(video_input_fetch_frame_func)y4m_input_fetch_frame;
+ _vid->close=(video_input_close_func)y4m_input_close;
+ return 0;
+ }
+ }
+ else if(!memcmp(buffer,"OggS",4)){
+ if(th_input_open(&_vid->ctx.th,_fin,buffer,4)>=0){
+ _vid->fin=_fin;
+ _vid->get_info=(video_input_get_info_func)th_input_get_info;
+ _vid->fetch_frame=(video_input_fetch_frame_func)th_input_fetch_frame;
+ _vid->close=(video_input_close_func)th_input_close;
+ return 0;
+ }
+ }
+ else fprintf(stderr,"Unknown file type.\n");
+ }
+ return -1;
+}
+
+static void video_input_get_info(video_input *_vid,th_info *_ti){
+ (*_vid->get_info)(&_vid->ctx,_ti);
+}
+
+static int video_input_fetch_frame(video_input *_vid,th_ycbcr_buffer _ycbcr){
+ return (*_vid->fetch_frame)(&_vid->ctx,_vid->fin,_ycbcr);
+}
+
+static void video_input_close(video_input *_vid){
+ (*_vid->close)(&_vid->ctx);
+ fclose(_vid->fin);
+}
+
+
+
+static void usage(char *_argv[]){
+ fprintf(stderr,"Usage: %s [options] \n"
+ " and may be either YUV4MPEG or Ogg Theora files.\n\n"
+ " Options:\n\n"
+ " -f --frame-type Show frame type and QI value for each Theora frame.\n"
+ " -s --summary Only output the summary line.\n"
+ " -y --luma-only Only output values for the luma channel.\n",_argv[0]);
+}
+
+int main(int _argc,char *_argv[]){
+ video_input vid1;
+ th_info ti1;
+ video_input vid2;
+ th_info ti2;
+ ogg_int64_t gsqerr;
+ ogg_int64_t gnpixels;
+ ogg_int64_t gplsqerr[3];
+ ogg_int64_t gplnpixels[3];
+ int frameno;
+ FILE *fin;
+ int long_option_index;
+ int c;
+#ifdef _WIN32
+ /*We need to set stdin/stdout to binary mode on windows.
+ Beware the evil ifdef.
+ We avoid these where we can, but this one we cannot.
+ Don't add any more, you'll probably go to hell if you do.*/
+ _setmode(_fileno(stdin),_O_BINARY);
+#endif
+ /*Process option arguments.*/
+ while((c=getopt_long(_argc,_argv,optstring,options,&long_option_index))!=EOF){
+ switch(c){
+ case 'f':show_frame_type=1;break;
+ case 's':summary_only=1;break;
+ case 'y':luma_only=1;break;
+ default:usage(_argv);break;
+ }
+ }
+ if(optind+2!=_argc){
+ usage(_argv);
+ exit(1);
+ }
+ fin=strcmp(_argv[optind],"-")==0?stdin:fopen(_argv[optind],"rb");
+ if(fin==NULL){
+ fprintf(stderr,"Unable to open '%s' for extraction.\n",_argv[optind]);
+ exit(1);
+ }
+ fprintf(stderr,"Opening %s...\n",_argv[optind]);
+ if(video_input_open(&vid1,fin)<0)exit(1);
+ video_input_get_info(&vid1,&ti1);
+ fin=strcmp(_argv[optind+1],"-")==0?stdin:fopen(_argv[optind+1],"rb");
+ if(fin==NULL){
+ fprintf(stderr,"Unable to open '%s' for extraction.\n",_argv[optind+1]);
+ exit(1);
+ }
+ fprintf(stderr,"Opening %s...\n",_argv[optind+1]);
+ if(video_input_open(&vid2,fin)<0)exit(1);
+ video_input_get_info(&vid2,&ti2);
+ /*Check to make sure these videos are compatible.*/
+ if(ti1.pic_width!=ti2.pic_width||ti1.pic_height!=ti2.pic_height){
+ fprintf(stderr,"Video resolution does not match.\n");
+ exit(1);
+ }
+ if(ti1.pixel_fmt!=ti2.pixel_fmt){
+ fprintf(stderr,"Pixel formats do not match.\n");
+ exit(1);
+ }
+ if((ti1.pic_x&!(ti1.pixel_fmt&1))!=(ti2.pic_x&!(ti2.pixel_fmt&1))||
+ (ti1.pic_y&!(ti1.pixel_fmt&2))!=(ti2.pic_y&!(ti2.pixel_fmt&2))){
+ fprintf(stderr,"Chroma subsampling offsets do not match.\n");
+ exit(1);
+ }
+ if(ti1.fps_numerator*(ogg_int64_t)ti2.fps_denominator!=
+ ti2.fps_numerator*(ogg_int64_t)ti1.fps_denominator){
+ fprintf(stderr,"Warning: framerates do not match.\n");
+ }
+ if(ti1.aspect_numerator*(ogg_int64_t)ti2.aspect_denominator!=
+ ti2.aspect_numerator*(ogg_int64_t)ti1.aspect_denominator){
+ fprintf(stderr,"Warning: aspect ratios do not match.\n");
+ }
+ gsqerr=gplsqerr[0]=gplsqerr[1]=gplsqerr[2]=0;
+ gnpixels=gplnpixels[0]=gplnpixels[1]=gplnpixels[2]=0;
+ for(frameno=0;;frameno++){
+ th_ycbcr_buffer f1;
+ th_ycbcr_buffer f2;
+ ogg_int64_t plsqerr[3];
+ long plnpixels[3];
+ ogg_int64_t sqerr;
+ long npixels;
+ int ret1;
+ int ret2;
+ int pli;
+ ret1=video_input_fetch_frame(&vid1,f1);
+ ret2=video_input_fetch_frame(&vid2,f2);
+ if(ret1==0&&ret2==0)break;
+ else if(ret1<0||ret2<0)break;
+ else if(ret1==0){
+ fprintf(stderr,"%s ended before %s.\n",
+ _argv[optind],_argv[optind+1]);
+ break;
+ }
+ else if(ret2==0){
+ fprintf(stderr,"%s ended before %s.\n",
+ _argv[optind+1],_argv[optind]);
+ break;
+ }
+ /*Okay, we got one frame from each.*/
+ sqerr=0;
+ npixels=0;
+ for(pli=0;pli<3;pli++){
+ int xdec;
+ int ydec;
+ int y1;
+ int y2;
+ xdec=pli&&!(ti1.pixel_fmt&1);
+ ydec=pli&&!(ti1.pixel_fmt&2);
+ plsqerr[pli]=0;
+ plnpixels[pli]=0;
+ for(y1=ti1.pic_y>>ydec,y2=ti2.pic_y>>ydec;
+ y1>ydec;y1++,y2++){
+ int x1;
+ int x2;
+ for(x1=ti1.pic_x>>xdec,x2=ti2.pic_x>>xdec;
+ x1>xdec;x1++,x2++){
+ int d;
+ d=*(f1[pli].data+y1*f1[pli].stride+x1)-
+ *(f2[pli].data+y2*f2[pli].stride+x2);
+ plsqerr[pli]+=d*d;
+ plnpixels[pli]++;
+ }
+ }
+ sqerr+=plsqerr[pli];
+ gplsqerr[pli]+=plsqerr[pli];
+ npixels+=plnpixels[pli];
+ gplnpixels[pli]+=plnpixels[pli];
+ }
+ if(!summary_only){
+ if(!luma_only){
+ printf("%08i: %-7lG (Y': %-7lG Cb: %-7lG Cr: %-7lG)\n",frameno,
+ 10*(log10(255*255)+log10(npixels)-log10(sqerr)),
+ 10*(log10(255*255)+log10(plnpixels[0])-log10(plsqerr[0])),
+ 10*(log10(255*255)+log10(plnpixels[1])-log10(plsqerr[1])),
+ 10*(log10(255*255)+log10(plnpixels[2])-log10(plsqerr[2])));
+ }
+ else{
+ printf("%08i: %-7lG\n",frameno,
+ 10*(log10(255*255)+log10(plnpixels[0])-log10(plsqerr[0])));
+ }
+ }
+ gsqerr+=sqerr;
+ gnpixels+=npixels;
+ }
+ if(!luma_only){
+ printf("Total: %-7lG (Y': %-7lG Cb: %-7lG Cr: %-7lG)\n",
+ 10*(log10(255*255)+log10(gnpixels)-log10(gsqerr)),
+ 10*(log10(255*255)+log10(gplnpixels[0])-log10(gplsqerr[0])),
+ 10*(log10(255*255)+log10(gplnpixels[1])-log10(gplsqerr[1])),
+ 10*(log10(255*255)+log10(gplnpixels[2])-log10(gplsqerr[2])));
+ }
+ else{
+ printf("Total: %-7lG\n",
+ 10*(log10(255*255)+log10(gplnpixels[0])-log10(gplsqerr[0])));
+ }
+ video_input_close(&vid1);
+ video_input_close(&vid2);
+ return 0;
+}
diff --git a/libs/libtheora-1.1/examples/dump_video.c b/libs/libtheora-1.1/examples/dump_video.c
new file mode 100644
index 00000000..1449ec48
--- /dev/null
+++ b/libs/libtheora-1.1/examples/dump_video.c
@@ -0,0 +1,496 @@
+/********************************************************************
+ * *
+ * THIS FILE IS PART OF THE OggTheora SOFTWARE CODEC SOURCE CODE. *
+ * USE, DISTRIBUTION AND REPRODUCTION OF THIS LIBRARY SOURCE IS *
+ * GOVERNED BY A BSD-STYLE SOURCE LICENSE INCLUDED WITH THIS SOURCE *
+ * IN 'COPYING'. PLEASE READ THESE TERMS BEFORE DISTRIBUTING. *
+ * *
+ * THE Theora SOURCE CODE IS COPYRIGHT (C) 2002-2009 *
+ * by the Xiph.Org Foundation http://www.xiph.org/ *
+ * *
+ ********************************************************************
+
+ function: example dumpvid application; dumps Theora streams
+ last mod: $Id: dump_video.c,v 1.2 2004/03/24 19:12:42 derf Exp $
+
+ ********************************************************************/
+
+/* By Mauricio Piacentini (mauricio at xiph.org) */
+/* simply dump decoded YUV data, for verification of theora bitstream */
+
+#if !defined(_REENTRANT)
+#define _REENTRANT
+#endif
+#if !defined(_GNU_SOURCE)
+#define _GNU_SOURCE
+#endif
+#if !defined(_LARGEFILE_SOURCE)
+#define _LARGEFILE_SOURCE
+#endif
+#if !defined(_LARGEFILE64_SOURCE)
+#define _LARGEFILE64_SOURCE
+#endif
+#if !defined(_FILE_OFFSET_BITS)
+#define _FILE_OFFSET_BITS 64
+#endif
+
+#include
+#include
+#include
+#include
+#include
+#include
+/*Yes, yes, we're going to hell.*/
+#if defined(_WIN32)
+#include
+#endif
+#include
+#include
+#include
+#include
+#include "getopt.h"
+#include "theora/theoradec.h"
+
+const char *optstring = "o:rf";
+struct option options [] = {
+ {"output",required_argument,NULL,'o'},
+ {"raw",no_argument, NULL,'r'}, /*Disable YUV4MPEG2 headers:*/
+ {"fps-only",no_argument, NULL, 'f'}, /* Only interested in fps of decode loop */
+ {NULL,0,NULL,0}
+};
+
+/* Helper; just grab some more compressed bitstream and sync it for
+ page extraction */
+int buffer_data(FILE *in,ogg_sync_state *oy){
+ char *buffer=ogg_sync_buffer(oy,4096);
+ int bytes=fread(buffer,1,4096,in);
+ ogg_sync_wrote(oy,bytes);
+ return(bytes);
+}
+
+/* never forget that globals are a one-way ticket to Hell */
+/* Ogg and codec state for demux/decode */
+ogg_sync_state oy;
+ogg_page og;
+ogg_stream_state vo;
+ogg_stream_state to;
+th_info ti;
+th_comment tc;
+th_setup_info *ts;
+th_dec_ctx *td;
+
+int theora_p=0;
+int theora_processing_headers;
+int stateflag=0;
+
+/* single frame video buffering */
+int videobuf_ready=0;
+ogg_int64_t videobuf_granulepos=-1;
+double videobuf_time=0;
+int raw=0;
+
+FILE* outfile = NULL;
+
+int got_sigint=0;
+static void sigint_handler (int signal) {
+ got_sigint = 1;
+}
+
+static th_ycbcr_buffer ycbcr;
+
+static void stripe_decoded(th_ycbcr_buffer _dst,th_ycbcr_buffer _src,
+ int _fragy0,int _fragy_end){
+ int pli;
+ for(pli=0;pli<3;pli++){
+ int yshift;
+ int y_end;
+ int y;
+ yshift=pli!=0&&!(ti.pixel_fmt&2);
+ y_end=_fragy_end<<3-yshift;
+ /*An implemention intending to display this data would need to check the
+ crop rectangle before proceeding.*/
+ for(y=_fragy0<<3-yshift;y>xshift)*(ti.frame_height>>yshift)*sizeof(char));
+ ycbcr[pli].stride=ti.frame_width>>xshift;
+ ycbcr[pli].width=ti.frame_width>>xshift;
+ ycbcr[pli].height=ti.frame_height>>yshift;
+ }
+ /*Similarly, since ycbcr is a global, there's no real reason to pass it as
+ the context.
+ In a more object-oriented decoder, we could pass the "this" pointer
+ instead (though in C++, platform-dependent calling convention differences
+ prevent us from using a real member function pointer).*/
+ cb.ctx=ycbcr;
+ cb.stripe_decoded=(th_stripe_decoded_func)stripe_decoded;
+ th_decode_ctl(td,TH_DECCTL_SET_STRIPE_CB,&cb,sizeof(cb));
+}
+
+/*Write out the planar YUV frame, uncropped.*/
+static void video_write(void){
+ int pli;
+ int i;
+ /*Uncomment the following to do normal, non-striped decoding.
+ th_ycbcr_buffer ycbcr;
+ th_decode_ycbcr_out(td,ycbcr);*/
+ if(outfile){
+ if(!raw)fprintf(outfile, "FRAME\n");
+ for(pli=0;pli<3;pli++){
+ for(i=0;ivendor);
+ if(_tc->comments){
+ fprintf(out,"theora comment header:\n");
+ for(i=0;i<_tc->comments;i++){
+ if(_tc->user_comments[i]){
+ len=_tc->comment_lengths[i]comment_lengths[i]:INT_MAX;
+ fprintf(out,"\t%.*s\n",len,_tc->user_comments[i]);
+ }
+ }
+ }
+ return 0;
+}
+
+/* helper: push a page into the appropriate steam */
+/* this can be done blindly; a stream won't accept a page
+ that doesn't belong to it */
+static int queue_page(ogg_page *page){
+ if(theora_p)ogg_stream_pagein(&to,page);
+ return 0;
+}
+
+static void usage(void){
+ fprintf(stderr,
+ "Usage: dumpvid > outfile\n"
+ "input is read from stdin if no file is passed on the command line\n"
+ "\n"
+ );
+}
+
+int main(int argc,char *argv[]){
+
+ ogg_packet op;
+
+ int long_option_index;
+ int c;
+
+ struct timeb start;
+ struct timeb after;
+ struct timeb last;
+ int fps_only=0;
+ int frames = 0;
+
+ FILE *infile = stdin;
+ outfile = stdout;
+
+#ifdef _WIN32 /* We need to set stdin/stdout to binary mode on windows. */
+ /* Beware the evil ifdef. We avoid these where we can, but this one we
+ cannot. Don't add any more, you'll probably go to hell if you do. */
+ _setmode( _fileno( stdin ), _O_BINARY );
+ _setmode( _fileno( stdout ), _O_BINARY );
+#endif
+
+ /* Process option arguments. */
+ while((c=getopt_long(argc,argv,optstring,options,&long_option_index))!=EOF){
+ switch(c){
+ case 'o':
+ if(strcmp(optarg,"-")!=0){
+ outfile=fopen(optarg,"wb");
+ if(outfile==NULL){
+ fprintf(stderr,"Unable to open output file '%s'\n", optarg);
+ exit(1);
+ }
+ }else{
+ outfile=stdout;
+ }
+ break;
+
+ case 'r':
+ raw=1;
+ break;
+
+ case 'f':
+ fps_only = 1;
+ outfile = NULL;
+ break;
+
+ default:
+ usage();
+ }
+ }
+ if(optind0){
+ int got_packet;
+ ogg_stream_state test;
+
+ /* is this a mandated initial header? If not, stop parsing */
+ if(!ogg_page_bos(&og)){
+ /* don't leak the page; get it into the appropriate stream */
+ queue_page(&og);
+ stateflag=1;
+ break;
+ }
+
+ ogg_stream_init(&test,ogg_page_serialno(&og));
+ ogg_stream_pagein(&test,&og);
+ got_packet = ogg_stream_packetpeek(&test,&op);
+
+ /* identify the codec: try theora */
+ if((got_packet==1) && !theora_p && (theora_processing_headers=
+ th_decode_headerin(&ti,&tc,&ts,&op))>=0){
+ /* it is theora -- save this stream state */
+ memcpy(&to,&test,sizeof(test));
+ theora_p=1;
+ /*Advance past the successfully processed header.*/
+ if(theora_processing_headers)ogg_stream_packetout(&to,NULL);
+ }else{
+ /* whatever it is, we don't care about it */
+ ogg_stream_clear(&test);
+ }
+ }
+ /* fall through to non-bos page parsing */
+ }
+
+ /* we're expecting more header packets. */
+ while(theora_p && theora_processing_headers){
+ int ret;
+
+ /* look for further theora headers */
+ while(theora_processing_headers&&(ret=ogg_stream_packetpeek(&to,&op))){
+ if(ret<0)continue;
+ theora_processing_headers=th_decode_headerin(&ti,&tc,&ts,&op);
+ if(theora_processing_headers<0){
+ fprintf(stderr,"Error parsing Theora stream headers; "
+ "corrupt stream?\n");
+ exit(1);
+ }
+ else if(theora_processing_headers>0){
+ /*Advance past the successfully processed header.*/
+ ogg_stream_packetout(&to,NULL);
+ }
+ theora_p++;
+ }
+
+ /*Stop now so we don't fail if there aren't enough pages in a short
+ stream.*/
+ if(!(theora_p && theora_processing_headers))break;
+
+ /* The header pages/packets will arrive before anything else we
+ care about, or the stream is not obeying spec */
+
+ if(ogg_sync_pageout(&oy,&og)>0){
+ queue_page(&og); /* demux into the appropriate stream */
+ }else{
+ int ret=buffer_data(infile,&oy); /* someone needs more data */
+ if(ret==0){
+ fprintf(stderr,"End of file while searching for codec headers.\n");
+ exit(1);
+ }
+ }
+ }
+
+ /* and now we have it all. initialize decoders */
+ if(theora_p){
+ dump_comments(&tc);
+ td=th_decode_alloc(&ti,ts);
+ fprintf(stderr,"Ogg logical stream %lx is Theora %dx%d %.02f fps video\n"
+ "Encoded frame content is %dx%d with %dx%d offset\n",
+ to.serialno,ti.frame_width,ti.frame_height,
+ (double)ti.fps_numerator/ti.fps_denominator,
+ ti.pic_width,ti.pic_height,ti.pic_x,ti.pic_y);
+ }else{
+ /* tear down the partial theora setup */
+ th_info_clear(&ti);
+ th_comment_clear(&tc);
+ }
+ /*Either way, we're done with the codec setup data.*/
+ th_setup_free(ts);
+
+ /* open video */
+ if(theora_p)open_video();
+
+ if(!raw && outfile){
+ static const char *CHROMA_TYPES[4]={"420jpeg",NULL,"422jpeg","444"};
+ if(ti.pixel_fmt>=4||ti.pixel_fmt==TH_PF_RSVD){
+ fprintf(stderr,"Unknown pixel format: %i\n",ti.pixel_fmt);
+ exit(1);
+ }
+ fprintf(outfile,"YUV4MPEG2 C%s W%d H%d F%d:%d I%c A%d:%d\n",
+ CHROMA_TYPES[ti.pixel_fmt],ti.frame_width,ti.frame_height,
+ ti.fps_numerator,ti.fps_denominator,'p',
+ ti.aspect_numerator,ti.aspect_denominator);
+ }
+
+ /* install signal handler */
+ signal (SIGINT, sigint_handler);
+
+ /*Finally the main decode loop.
+
+ It's one Theora packet per frame, so this is pretty straightforward if
+ we're not trying to maintain sync with other multiplexed streams.
+
+ The videobuf_ready flag is used to maintain the input buffer in the libogg
+ stream state.
+ If there's no output frame available at the end of the decode step, we must
+ need more input data.
+ We could simplify this by just using the return code on
+ ogg_page_packetout(), but the flag system extends easily to the case where
+ you care about more than one multiplexed stream (like with audio
+ playback).
+ In that case, just maintain a flag for each decoder you care about, and
+ pull data when any one of them stalls.
+
+ videobuf_time holds the presentation time of the currently buffered video
+ frame.
+ We ignore this value.*/
+
+ stateflag=0; /* playback has not begun */
+ /* queue any remaining pages from data we buffered but that did not
+ contain headers */
+ while(ogg_sync_pageout(&oy,&og)>0){
+ queue_page(&og);
+ }
+
+ if(fps_only){
+ ftime(&start);
+ ftime(&last);
+ }
+
+ while(!got_sigint){
+
+ while(theora_p && !videobuf_ready){
+ /* theora is one in, one out... */
+ if(ogg_stream_packetout(&to,&op)>0){
+
+ if(th_decode_packetin(td,&op,&videobuf_granulepos)>=0){
+ videobuf_time=th_granule_time(td,videobuf_granulepos);
+ videobuf_ready=1;
+ frames++;
+ if(fps_only)
+ ftime(&after);
+ }
+
+ }else
+ break;
+ }
+
+ if(fps_only && (videobuf_ready || fps_only==2)){
+ long ms =
+ after.time*1000.+after.millitm-
+ (last.time*1000.+last.millitm);
+
+ if(ms>500 || fps_only==1 ||
+ (feof(infile) && !videobuf_ready)){
+ float file_fps = (float)ti.fps_numerator/ti.fps_denominator;
+ fps_only=2;
+
+ ms = after.time*1000.+after.millitm-
+ (start.time*1000.+start.millitm);
+
+ fprintf(stderr,"\rframe:%d rate:%.2fx ",
+ frames,
+ frames*1000./(ms*file_fps));
+ memcpy(&last,&after,sizeof(last));
+ }
+ }
+
+ if(!videobuf_ready && feof(infile))break;
+
+ if(!videobuf_ready){
+ /* no data yet for somebody. Grab another page */
+ buffer_data(infile,&oy);
+ while(ogg_sync_pageout(&oy,&og)>0){
+ queue_page(&og);
+ }
+ }
+ /* dumpvideo frame, and get new one */
+ else if(outfile)video_write();
+
+ videobuf_ready=0;
+ }
+
+ /* end of decoder loop -- close everything */
+
+ if(theora_p){
+ ogg_stream_clear(&to);
+ th_decode_free(td);
+ th_comment_clear(&tc);
+ th_info_clear(&ti);
+ }
+ ogg_sync_clear(&oy);
+
+ if(infile && infile!=stdin)fclose(infile);
+ if(outfile && outfile!=stdout)fclose(outfile);
+
+ fprintf(stderr, "\n\n%d frames\n", frames);
+ fprintf(stderr, "\nDone.\n");
+
+ return(0);
+
+}
diff --git a/libs/libtheora-1.1/examples/encoder_example.c b/libs/libtheora-1.1/examples/encoder_example.c
new file mode 100644
index 00000000..1ff39da1
--- /dev/null
+++ b/libs/libtheora-1.1/examples/encoder_example.c
@@ -0,0 +1,1830 @@
+/********************************************************************
+ * *
+ * THIS FILE IS PART OF THE OggTheora SOFTWARE CODEC SOURCE CODE. *
+ * USE, DISTRIBUTION AND REPRODUCTION OF THIS LIBRARY SOURCE IS *
+ * GOVERNED BY A BSD-STYLE SOURCE LICENSE INCLUDED WITH THIS SOURCE *
+ * IN 'COPYING'. PLEASE READ THESE TERMS BEFORE DISTRIBUTING. *
+ * *
+ * THE Theora SOURCE CODE IS COPYRIGHT (C) 2002-2009 *
+ * by the Xiph.Org Foundation and contributors http://www.xiph.org/ *
+ * *
+ ********************************************************************
+
+ function: example encoder application; makes an Ogg Theora/Vorbis
+ file from YUV4MPEG2 and WAV input
+ last mod: $Id: encoder_example.c 16764 2009-12-28 14:27:33Z tterribe $
+
+ ********************************************************************/
+
+#if !defined(_REENTRANT)
+#define _REENTRANT
+#endif
+#if !defined(_GNU_SOURCE)
+#define _GNU_SOURCE
+#endif
+#if !defined(_LARGEFILE_SOURCE)
+#define _LARGEFILE_SOURCE
+#endif
+#if !defined(_LARGEFILE64_SOURCE)
+#define _LARGEFILE64_SOURCE
+#endif
+#if !defined(_FILE_OFFSET_BITS)
+#define _FILE_OFFSET_BITS 64
+#endif
+
+#include
+#if !defined(_WIN32)
+#include
+#include
+#else
+#include "getopt.h"
+#endif
+#include
+#include
+#include
+#include
+#include "theora/theoraenc.h"
+#include "vorbis/codec.h"
+#include "vorbis/vorbisenc.h"
+
+#ifdef _WIN32
+/*supply missing headers and functions to Win32. going to hell, I know*/
+#include
+#include
+
+static double rint(double x)
+{
+ if (x < 0.0)
+ return (double)(int)(x - 0.5);
+ else
+ return (double)(int)(x + 0.5);
+}
+#endif
+
+const char *optstring = "b:e:o:a:A:v:V:s:S:f:F:ck:d:z:\1\2\3\4";
+struct option options [] = {
+ {"begin-time",required_argument,NULL,'b'},
+ {"end-time",required_argument,NULL,'e'},
+ {"output",required_argument,NULL,'o'},
+ {"audio-rate-target",required_argument,NULL,'A'},
+ {"video-rate-target",required_argument,NULL,'V'},
+ {"audio-quality",required_argument,NULL,'a'},
+ {"video-quality",required_argument,NULL,'v'},
+ {"aspect-numerator",required_argument,NULL,'s'},
+ {"aspect-denominator",required_argument,NULL,'S'},
+ {"framerate-numerator",required_argument,NULL,'f'},
+ {"framerate-denominator",required_argument,NULL,'F'},
+ {"vp3-compatible",no_argument,NULL,'c'},
+ {"speed",required_argument,NULL,'z'},
+ {"soft-target",no_argument,NULL,'\1'},
+ {"keyframe-freq",required_argument,NULL,'k'},
+ {"buf-delay",required_argument,NULL,'d'},
+ {"two-pass",no_argument,NULL,'\2'},
+ {"first-pass",required_argument,NULL,'\3'},
+ {"second-pass",required_argument,NULL,'\4'},
+ {NULL,0,NULL,0}
+};
+
+/* You'll go to Hell for using globals. */
+
+FILE *audio=NULL;
+FILE *video=NULL;
+
+int audio_ch=0;
+int audio_hz=0;
+
+float audio_q=.1f;
+int audio_r=-1;
+int vp3_compatible=0;
+
+int frame_w=0;
+int frame_h=0;
+int pic_w=0;
+int pic_h=0;
+int pic_x=0;
+int pic_y=0;
+int video_fps_n=-1;
+int video_fps_d=-1;
+int video_par_n=-1;
+int video_par_d=-1;
+char interlace;
+int src_c_dec_h=2;
+int src_c_dec_v=2;
+int dst_c_dec_h=2;
+int dst_c_dec_v=2;
+char chroma_type[16];
+
+/*The size of each converted frame buffer.*/
+size_t y4m_dst_buf_sz;
+/*The amount to read directly into the converted frame buffer.*/
+size_t y4m_dst_buf_read_sz;
+/*The size of the auxilliary buffer.*/
+size_t y4m_aux_buf_sz;
+/*The amount to read into the auxilliary buffer.*/
+size_t y4m_aux_buf_read_sz;
+
+/*The function used to perform chroma conversion.*/
+typedef void (*y4m_convert_func)(unsigned char *_dst,unsigned char *_aux);
+
+y4m_convert_func y4m_convert=NULL;
+
+int video_r=-1;
+int video_q=-1;
+ogg_uint32_t keyframe_frequency=0;
+int buf_delay=-1;
+
+long begin_sec=-1;
+long begin_usec=0;
+long end_sec=-1;
+long end_usec=0;
+
+static void usage(void){
+ fprintf(stderr,
+ "Usage: encoder_example [options] [audio_file] video_file\n\n"
+ "Options: \n\n"
+ " -o --output file name for encoded output;\n"
+ " If this option is not given, the\n"
+ " compressed data is sent to stdout.\n\n"
+ " -A --audio-rate-target bitrate target for Vorbis audio;\n"
+ " use -a and not -A if at all possible,\n"
+ " as -a gives higher quality for a given\n"
+ " bitrate.\n\n"
+ " -V --video-rate-target bitrate target for Theora video\n\n"
+ " --soft-target Use a large reservoir and treat the rate\n"
+ " as a soft target; rate control is less\n"
+ " strict but resulting quality is usually\n"
+ " higher/smoother overall. Soft target also\n"
+ " allows an optional -v setting to specify\n"
+ " a minimum allowed quality.\n\n"
+ " --two-pass Compress input using two-pass rate control\n"
+ " This option requires that the input to the\n"
+ " to the encoder is seekable and performs\n"
+ " both passes automatically.\n\n"
+ " --first-pass Perform first-pass of a two-pass rate\n"
+ " controlled encoding, saving pass data to\n"
+ " for a later second pass\n\n"
+ " --second-pass Perform second-pass of a two-pass rate\n"
+ " controlled encoding, reading first-pass\n"
+ " data from . The first pass\n"
+ " data must come from a first encoding pass\n"
+ " using identical input video to work\n"
+ " properly.\n\n"
+ " -a --audio-quality Vorbis quality selector from -1 to 10\n"
+ " (-1 yields smallest files but lowest\n"
+ " fidelity; 10 yields highest fidelity\n"
+ " but large files. '2' is a reasonable\n"
+ " default).\n\n"
+ " -v --video-quality Theora quality selector from 0 to 10\n"
+ " (0 yields smallest files but lowest\n"
+ " video quality. 10 yields highest\n"
+ " fidelity but large files).\n\n"
+ " -s --aspect-numerator Aspect ratio numerator, default is 0\n"
+ " or extracted from YUV input file\n"
+ " -S --aspect-denominator Aspect ratio denominator, default is 0\n"
+ " or extracted from YUV input file\n"
+ " -f --framerate-numerator Frame rate numerator, can be extracted\n"
+ " from YUV input file. ex: 30000000\n"
+ " -F --framerate-denominator Frame rate denominator, can be extracted\n"
+ " from YUV input file. ex: 1000000\n"
+ " The frame rate nominator divided by this\n"
+ " determinates the frame rate in units per tick\n"
+ " -k --keyframe-freq Keyframe frequency\n"
+ " -z --speed Sets the encoder speed level. Higher speed\n"
+ " levels favor quicker encoding over better\n"
+ " quality per bit. Depending on the encoding\n"
+ " mode, and the internal algorithms used,\n"
+ " quality may actually improve with higher\n"
+ " speeds, but in this case bitrate will also\n"
+ " likely increase. The maximum value, and the\n"
+ " meaning of each value, are implementation-\n"
+ " specific and may change depending on the\n"
+ " current encoding mode (rate constrained,\n"
+ " two-pass, etc.).\n"
+ " -d --buf-delay Buffer delay (in frames). Longer delays\n"
+ " allow smoother rate adaptation and provide\n"
+ " better overall quality, but require more\n"
+ " client side buffering and add latency. The\n"
+ " default value is the keyframe interval for\n"
+ " one-pass encoding (or somewhat larger if\n"
+ " --soft-target is used) and infinite for\n"
+ " two-pass encoding.\n"
+ " -b --begin-time Begin encoding at offset into input\n"
+ " -e --end-time End encoding at offset into input\n"
+ "encoder_example accepts only uncompressed RIFF WAV format audio and\n"
+ "YUV4MPEG2 uncompressed video.\n\n");
+ exit(1);
+}
+
+static int y4m_parse_tags(char *_tags){
+ int got_w;
+ int got_h;
+ int got_fps;
+ int got_interlace;
+ int got_par;
+ int got_chroma;
+ int tmp_video_fps_n;
+ int tmp_video_fps_d;
+ int tmp_video_par_n;
+ int tmp_video_par_d;
+ char *p;
+ char *q;
+ got_w=got_h=got_fps=got_interlace=got_par=got_chroma=0;
+ for(p=_tags;;p=q){
+ /*Skip any leading spaces.*/
+ while(*p==' ')p++;
+ /*If that's all we have, stop.*/
+ if(p[0]=='\0')break;
+ /*Find the end of this tag.*/
+ for(q=p+1;*q!='\0'&&*q!=' ';q++);
+ /*Process the tag.*/
+ switch(p[0]){
+ case 'W':{
+ if(sscanf(p+1,"%d",&pic_w)!=1)return -1;
+ got_w=1;
+ }break;
+ case 'H':{
+ if(sscanf(p+1,"%d",&pic_h)!=1)return -1;
+ got_h=1;
+ }break;
+ case 'F':{
+ if(sscanf(p+1,"%d:%d",&tmp_video_fps_n,&tmp_video_fps_d)!=2)return -1;
+ got_fps=1;
+ }break;
+ case 'I':{
+ interlace=p[1];
+ got_interlace=1;
+ }break;
+ case 'A':{
+ if(sscanf(p+1,"%d:%d",&tmp_video_par_n,&tmp_video_par_d)!=2)return -1;
+ got_par=1;
+ }break;
+ case 'C':{
+ if(q-p>16)return -1;
+ memcpy(chroma_type,p+1,q-p-1);
+ chroma_type[q-p-1]='\0';
+ got_chroma=1;
+ }break;
+ /*Ignore unknown tags.*/
+ }
+ }
+ if(!got_w||!got_h||!got_fps||!got_interlace||!got_par)return -1;
+ /*Chroma-type is not specified in older files, e.g., those generated by
+ mplayer.*/
+ if(!got_chroma)strcpy(chroma_type,"420");
+ /*Update fps and aspect ratio globals if not specified in the command line.*/
+ if(video_fps_n==-1)video_fps_n=tmp_video_fps_n;
+ if(video_fps_d==-1)video_fps_d=tmp_video_fps_d;
+ if(video_par_n==-1)video_par_n=tmp_video_par_n;
+ if(video_par_d==-1)video_par_d=tmp_video_par_d;
+ return 0;
+}
+
+/*All anti-aliasing filters in the following conversion functions are based on
+ one of two window functions:
+ The 6-tap Lanczos window (for down-sampling and shifts):
+ sinc(\pi*t)*sinc(\pi*t/3), |t|<3 (sinc(t)==sin(t)/t)
+ 0, |t|>=3
+ The 4-tap Mitchell window (for up-sampling):
+ 7|t|^3-12|t|^2+16/3, |t|<1
+ -(7/3)|x|^3+12|x|^2-20|x|+32/3, |t|<2
+ 0, |t|>=2
+ The number of taps is intentionally kept small to reduce computational
+ overhead and limit ringing.
+
+ The taps from these filters are scaled so that their sum is 1, and the result
+ is scaled by 128 and rounded to integers to create a filter whose
+ intermediate values fit inside 16 bits.
+ Coefficients are rounded in such a way as to ensure their sum is still 128,
+ which is usually equivalent to normal rounding.*/
+
+#define OC_MINI(_a,_b) ((_a)>(_b)?(_b):(_a))
+#define OC_MAXI(_a,_b) ((_a)<(_b)?(_b):(_a))
+#define OC_CLAMPI(_a,_b,_c) (OC_MAXI(_a,OC_MINI(_b,_c)))
+
+/*420jpeg chroma samples are sited like:
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | BR | | BR |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | BR | | BR |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+
+ 420mpeg2 chroma samples are sited like:
+ Y-------Y-------Y-------Y-------
+ | | | |
+ BR | BR |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ BR | BR |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+
+ We use a resampling filter to shift the site locations one quarter pixel (at
+ the chroma plane's resolution) to the right.
+ The 4:2:2 modes look exactly the same, except there are twice as many chroma
+ lines, and they are vertically co-sited with the luma samples in both the
+ mpeg2 and jpeg cases (thus requiring no vertical resampling).*/
+static void y4m_convert_42xmpeg2_42xjpeg(unsigned char *_dst,
+ unsigned char *_aux){
+ int c_w;
+ int c_h;
+ int pli;
+ int y;
+ int x;
+ /*Skip past the luma data.*/
+ _dst+=pic_w*pic_h;
+ /*Compute the size of each chroma plane.*/
+ c_w=(pic_w+dst_c_dec_h-1)/dst_c_dec_h;
+ c_h=(pic_h+dst_c_dec_v-1)/dst_c_dec_v;
+ for(pli=1;pli<3;pli++){
+ for(y=0;y>7,255);
+ }
+ for(;x>7,255);
+ }
+ for(;x>7,255);
+ }
+ _dst+=c_w;
+ _aux+=c_w;
+ }
+ }
+}
+
+/*This format is only used for interlaced content, but is included for
+ completeness.
+
+ 420jpeg chroma samples are sited like:
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | BR | | BR |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | BR | | BR |
+ | | | |
+ Y-------Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+
+ 420paldv chroma samples are sited like:
+ YR------Y-------YR------Y-------
+ | | | |
+ | | | |
+ | | | |
+ YB------Y-------YB------Y-------
+ | | | |
+ | | | |
+ | | | |
+ YR------Y-------YR------Y-------
+ | | | |
+ | | | |
+ | | | |
+ YB------Y-------YB------Y-------
+ | | | |
+ | | | |
+ | | | |
+
+ We use a resampling filter to shift the site locations one quarter pixel (at
+ the chroma plane's resolution) to the right.
+ Then we use another filter to move the C_r location down one quarter pixel,
+ and the C_b location up one quarter pixel.*/
+static void y4m_convert_42xpaldv_42xjpeg(unsigned char *_dst,
+ unsigned char *_aux){
+ unsigned char *tmp;
+ int c_w;
+ int c_h;
+ int c_sz;
+ int pli;
+ int y;
+ int x;
+ /*Skip past the luma data.*/
+ _dst+=pic_w*pic_h;
+ /*Compute the size of each chroma plane.*/
+ c_w=(pic_w+1)/2;
+ c_h=(pic_h+dst_c_dec_h-1)/dst_c_dec_h;
+ c_sz=c_w*c_h;
+ /*First do the horizontal re-sampling.
+ This is the same as the mpeg2 case, except that after the horizontal case,
+ we need to apply a second vertical filter.*/
+ tmp=_aux+2*c_sz;
+ for(pli=1;pli<3;pli++){
+ for(y=0;y>7,255);
+ }
+ for(;x>7,255);
+ }
+ for(;x>7,255);
+ }
+ tmp+=c_w;
+ _aux+=c_w;
+ }
+ switch(pli){
+ case 1:{
+ tmp-=c_sz;
+ /*Slide C_b up a quarter-pel.
+ This is the same filter used above, but in the other order.*/
+ for(x=0;x>7,255);
+ }
+ for(;y>7,255);
+ }
+ for(;y>7,255);
+ }
+ _dst++;
+ tmp++;
+ }
+ _dst+=c_sz-c_w;
+ tmp-=c_w;
+ }break;
+ case 2:{
+ tmp-=c_sz;
+ /*Slide C_r down a quarter-pel.
+ This is the same as the horizontal filter.*/
+ for(x=0;x>7,255);
+ }
+ for(;y>7,255);
+ }
+ for(;y>7,255);
+ }
+ _dst++;
+ tmp++;
+ }
+ }break;
+ }
+ /*For actual interlaced material, this would have to be done separately on
+ each field, and the shift amounts would be different.
+ C_r moves down 1/8, C_b up 3/8 in the top field, and C_r moves down 3/8,
+ C_b up 1/8 in the bottom field.
+ The corresponding filters would be:
+ Down 1/8 (reverse order for up): [3 -11 125 15 -4 0]/128
+ Down 3/8 (reverse order for up): [4 -19 98 56 -13 2]/128*/
+ }
+}
+
+/*422jpeg chroma samples are sited like:
+ Y---BR--Y-------Y---BR--Y-------
+ | | | |
+ | | | |
+ | | | |
+ Y---BR--Y-------Y---BR--Y-------
+ | | | |
+ | | | |
+ | | | |
+ Y---BR--Y-------Y---BR--Y-------
+ | | | |
+ | | | |
+ | | | |
+ Y---BR--Y-------Y---BR--Y-------
+ | | | |
+ | | | |
+ | | | |
+
+ 411 chroma samples are sited like:
+ YBR-----Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+ YBR-----Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+ YBR-----Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+ YBR-----Y-------Y-------Y-------
+ | | | |
+ | | | |
+ | | | |
+
+ We use a filter to resample at site locations one eighth pixel (at the source
+ chroma plane's horizontal resolution) and five eighths of a pixel to the
+ right.*/
+static void y4m_convert_411_422jpeg(unsigned char *_dst,
+ unsigned char *_aux){
+ int c_w;
+ int dst_c_w;
+ int c_h;
+ int pli;
+ int y;
+ int x;
+ /*Skip past the luma data.*/
+ _dst+=pic_w*pic_h;
+ /*Compute the size of each chroma plane.*/
+ c_w=(pic_w+src_c_dec_h-1)/src_c_dec_h;
+ dst_c_w=(pic_w+dst_c_dec_h-1)/dst_c_dec_h;
+ c_h=(pic_h+dst_c_dec_v-1)/dst_c_dec_v;
+ for(pli=1;pli<3;pli++){
+ for(y=0;y>7,255);
+ _dst[x<<1|1]=(unsigned char)OC_CLAMPI(0,47*_aux[0]+
+ 86*_aux[OC_MINI(1,c_w-1)]-5*_aux[OC_MINI(2,c_w-1)]+64>>7,255);
+ }
+ for(;x>7,255);
+ _dst[x<<1|1]=(unsigned char)OC_CLAMPI(0,-3*_aux[x-1]+50*_aux[x]+
+ 86*_aux[x+1]-5*_aux[x+2]+64>>7,255);
+ }
+ for(;x>7,255);
+ if((x<<1|1)>7,255);
+ }
+ }
+ _dst+=dst_c_w;
+ _aux+=c_w;
+ }
+ }
+}
+
+/*The image is padded with empty chroma components at 4:2:0.
+ This costs about 17 bits a frame to code.*/
+static void y4m_convert_mono_420jpeg(unsigned char *_dst,
+ unsigned char *_aux){
+ int c_sz;
+ _dst+=pic_w*pic_h;
+ c_sz=((pic_w+dst_c_dec_h-1)/dst_c_dec_h)*((pic_h+dst_c_dec_v-1)/dst_c_dec_v);
+ memset(_dst,128,c_sz*2);
+}
+
+#if 0
+/*Right now just 444 to 420.
+ Not too hard to generalize.*/
+static void y4m_convert_4xxjpeg_42xjpeg(unsigned char *_dst,
+ unsigned char *_aux){
+ unsigned char *tmp;
+ int c_w;
+ int c_h;
+ int pic_sz;
+ int tmp_sz;
+ int c_sz;
+ int pli;
+ int y;
+ int x;
+ /*Compute the size of each chroma plane.*/
+ c_w=(pic_w+dst_c_dec_h-1)/dst_c_dec_h;
+ c_h=(pic_h+dst_c_dec_v-1)/dst_c_dec_v;
+ pic_sz=pic_w*pic_h;
+ tmp_sz=c_w*pic_h;
+ c_sz=c_w*c_h;
+ _dst+=pic_sz;
+ for(pli=1;pli<3;pli++){
+ tmp=_aux+pic_sz;
+ /*In reality, the horizontal and vertical steps could be pipelined, for
+ less memory consumption and better cache performance, but we do them
+ separately for simplicity.*/
+ /*First do horizontal filtering (convert to 4:2:2)*/
+ /*Filter: [3 -17 78 78 -17 3]/128, derived from a 6-tap Lanczos window.*/
+ for(y=0;y>1]=OC_CLAMPI(0,64*_aux[0]+78*_aux[OC_MINI(1,pic_w-1)]-
+ 17*_aux[OC_MINI(2,pic_w-1)]+3*_aux[OC_MINI(3,pic_w-1)]+64>>7,255);
+ }
+ for(;x>1]=OC_CLAMPI(0,3*(_aux[x-2]+_aux[x+3])-17*(_aux[x-1]+_aux[x+2])+
+ 78*(_aux[x]+_aux[x+1])+64>>7,255);
+ }
+ for(;x>1]=OC_CLAMPI(0,3*(_aux[x-2]+_aux[pic_w-1])-
+ 17*(_aux[x-1]+_aux[OC_MINI(x+2,pic_w-1)])+
+ 78*(_aux[x]+_aux[OC_MINI(x+1,pic_w-1)])+64>>7,255);
+ }
+ tmp+=c_w;
+ _aux+=pic_w;
+ }
+ _aux-=pic_sz;
+ tmp-=tmp_sz;
+ /*Now do the vertical filtering.*/
+ for(x=0;x>1)*c_w]=OC_CLAMPI(0,64*tmp[0]+78*tmp[OC_MINI(1,pic_h-1)*c_w]-
+ 17*tmp[OC_MINI(2,pic_h-1)*c_w]+3*tmp[OC_MINI(3,pic_h-1)*c_w]+
+ 64>>7,255);
+ }
+ for(;y>1)*c_w]=OC_CLAMPI(0,3*(tmp[(y-2)*c_w]+tmp[(y+3)*c_w])-
+ 17*(tmp[(y-1)*c_w]+tmp[(y+2)*c_w])+78*(tmp[y*c_w]+tmp[(y+1)*c_w])+
+ 64>>7,255);
+ }
+ for(;y>1)*c_w]=OC_CLAMPI(0,3*(tmp[(y-2)*c_w]+tmp[(pic_h-1)*c_w])-
+ 17*(tmp[(y-1)*c_w]+tmp[OC_MINI(y+2,pic_h-1)*c_w])+
+ 78*(tmp[y*c_w]+tmp[OC_MINI(y+1,pic_h-1)*c_w])+64>>7,255);
+ }
+ tmp++;
+ _dst++;
+ }
+ _dst-=c_w;
+ }
+}
+#endif
+
+
+/*No conversion function needed.*/
+static void y4m_convert_null(unsigned char *_dst,
+ unsigned char *_aux){
+}
+
+static void id_file(char *f){
+ FILE *test;
+ unsigned char buffer[80];
+ int ret;
+
+ /* open it, look for magic */
+
+ if(!strcmp(f,"-")){
+ /* stdin */
+ test=stdin;
+ }else{
+ test=fopen(f,"rb");
+ if(!test){
+ fprintf(stderr,"Unable to open file %s.\n",f);
+ exit(1);
+ }
+ }
+
+ ret=fread(buffer,1,4,test);
+ if(ret<4){
+ fprintf(stderr,"EOF determining file type of file %s.\n",f);
+ exit(1);
+ }
+
+ if(!memcmp(buffer,"RIFF",4)){
+ /* possible WAV file */
+
+ if(audio){
+ /* umm, we already have one */
+ fprintf(stderr,"Multiple RIFF WAVE files specified on command line.\n");
+ exit(1);
+ }
+
+ /* Parse the rest of the header */
+
+ ret=fread(buffer,1,8,test);
+ if(ret<8)goto riff_err;
+ if(!memcmp(buffer+4,"WAVE",4)){
+
+ while(!feof(test)){
+ ret=fread(buffer,1,4,test);
+ if(ret<4)goto riff_err;
+ if(!memcmp("fmt",buffer,3)){
+
+ /* OK, this is our audio specs chunk. Slurp it up. */
+
+ ret=fread(buffer,1,20,test);
+ if(ret<20)goto riff_err;
+
+ if(memcmp(buffer+4,"\001\000",2)){
+ fprintf(stderr,"The WAV file %s is in a compressed format; "
+ "can't read it.\n",f);
+ exit(1);
+ }
+
+ audio=test;
+ audio_ch=buffer[6]+(buffer[7]<<8);
+ audio_hz=buffer[8]+(buffer[9]<<8)+
+ (buffer[10]<<16)+(buffer[11]<<24);
+
+ if(buffer[18]+(buffer[19]<<8)!=16){
+ fprintf(stderr,"Can only read 16 bit WAV files for now.\n");
+ exit(1);
+ }
+
+ /* Now, align things to the beginning of the data */
+ /* Look for 'dataxxxx' */
+ while(!feof(test)){
+ ret=fread(buffer,1,4,test);
+ if(ret<4)goto riff_err;
+ if(!memcmp("data",buffer,4)){
+ /* We're there. Ignore the declared size for now. */
+ ret=fread(buffer,1,4,test);
+ if(ret<4)goto riff_err;
+
+ fprintf(stderr,"File %s is 16 bit %d channel %d Hz RIFF WAV audio.\n",
+ f,audio_ch,audio_hz);
+
+ return;
+ }
+ }
+ }
+ }
+ }
+
+ fprintf(stderr,"Couldn't find WAVE data in RIFF file %s.\n",f);
+ exit(1);
+
+ }
+ if(!memcmp(buffer,"YUV4",4)){
+ /* possible YUV2MPEG2 format file */
+ /* read until newline, or 80 cols, whichever happens first */
+ int i;
+ for(i=0;i<79;i++){
+ ret=fread(buffer+i,1,1,test);
+ if(ret<1)goto yuv_err;
+ if(buffer[i]=='\n')break;
+ }
+ if(i==79){
+ fprintf(stderr,"Error parsing %s header; not a YUV2MPEG2 file?\n",f);
+ }
+ buffer[i]='\0';
+
+ if(!memcmp(buffer,"MPEG",4)){
+
+ if(video){
+ /* umm, we already have one */
+ fprintf(stderr,"Multiple video files specified on command line.\n");
+ exit(1);
+ }
+
+ if(buffer[4]!='2'){
+ fprintf(stderr,"Incorrect YUV input file version; YUV4MPEG2 required.\n");
+ }
+
+ ret=y4m_parse_tags((char *)buffer+5);
+ if(ret<0){
+ fprintf(stderr,"Error parsing YUV4MPEG2 header in file %s.\n",f);
+ exit(1);
+ }
+
+ if(interlace!='p'){
+ fprintf(stderr,"Input video is interlaced; Theora handles only progressive scan\n");
+ exit(1);
+ }
+
+ if(strcmp(chroma_type,"420")==0||strcmp(chroma_type,"420jpeg")==0){
+ src_c_dec_h=dst_c_dec_h=src_c_dec_v=dst_c_dec_v=2;
+ y4m_dst_buf_read_sz=pic_w*pic_h+2*((pic_w+1)/2)*((pic_h+1)/2);
+ /*Natively supported: no conversion required.*/
+ y4m_aux_buf_sz=y4m_aux_buf_read_sz=0;
+ y4m_convert=y4m_convert_null;
+ }
+ else if(strcmp(chroma_type,"420mpeg2")==0){
+ src_c_dec_h=dst_c_dec_h=src_c_dec_v=dst_c_dec_v=2;
+ y4m_dst_buf_read_sz=pic_w*pic_h;
+ /*Chroma filter required: read into the aux buf first.*/
+ y4m_aux_buf_sz=y4m_aux_buf_read_sz=2*((pic_w+1)/2)*((pic_h+1)/2);
+ y4m_convert=y4m_convert_42xmpeg2_42xjpeg;
+ }
+ else if(strcmp(chroma_type,"420paldv")==0){
+ src_c_dec_h=dst_c_dec_h=src_c_dec_v=dst_c_dec_v=2;
+ y4m_dst_buf_read_sz=pic_w*pic_h;
+ /*Chroma filter required: read into the aux buf first.
+ We need to make two filter passes, so we need some extra space in the
+ aux buffer.*/
+ y4m_aux_buf_sz=3*((pic_w+1)/2)*((pic_h+1)/2);
+ y4m_aux_buf_read_sz=2*((pic_w+1)/2)*((pic_h+1)/2);
+ y4m_convert=y4m_convert_42xpaldv_42xjpeg;
+ }
+ else if(strcmp(chroma_type,"422")==0){
+ src_c_dec_h=dst_c_dec_h=2;
+ src_c_dec_v=dst_c_dec_v=1;
+ y4m_dst_buf_read_sz=pic_w*pic_h;
+ /*Chroma filter required: read into the aux buf first.*/
+ y4m_aux_buf_sz=y4m_aux_buf_read_sz=2*((pic_w+1)/2)*pic_h;
+ y4m_convert=y4m_convert_42xmpeg2_42xjpeg;
+ }
+ else if(strcmp(chroma_type,"422jpeg")==0){
+ src_c_dec_h=dst_c_dec_h=2;
+ src_c_dec_v=dst_c_dec_v=1;
+ y4m_dst_buf_read_sz=pic_w*pic_h+2*((pic_w+1)/2)*pic_h;
+ /*Natively supported: no conversion required.*/
+ y4m_aux_buf_sz=y4m_aux_buf_read_sz=0;
+ y4m_convert=y4m_convert_null;
+ }
+ else if(strcmp(chroma_type,"411")==0){
+ src_c_dec_h=4;
+ /*We don't want to introduce any additional sub-sampling, so we
+ promote 4:1:1 material to 4:2:2, as the closest format Theora can
+ handle.*/
+ dst_c_dec_h=2;
+ src_c_dec_v=dst_c_dec_v=1;
+ y4m_dst_buf_read_sz=pic_w*pic_h;
+ /*Chroma filter required: read into the aux buf first.*/
+ y4m_aux_buf_sz=y4m_aux_buf_read_sz=2*((pic_w+3)/4)*pic_h;
+ y4m_convert=y4m_convert_411_422jpeg;
+ }
+ else if(strcmp(chroma_type,"444")==0){
+ src_c_dec_h=dst_c_dec_h=src_c_dec_v=dst_c_dec_v=1;
+ y4m_dst_buf_read_sz=pic_w*pic_h*3;
+ y4m_aux_buf_sz=y4m_aux_buf_read_sz=0;
+ y4m_convert=y4m_convert_null;
+ }
+ else if(strcmp(chroma_type,"444alpha")==0){
+ src_c_dec_h=dst_c_dec_h=src_c_dec_v=dst_c_dec_v=1;
+ y4m_dst_buf_read_sz=pic_w*pic_h*3;
+ /*Read the extra alpha plane into the aux buf.
+ It will be discarded.*/
+ y4m_aux_buf_sz=y4m_aux_buf_read_sz=pic_w*pic_h;
+ y4m_convert=y4m_convert_null;
+ }
+ else if(strcmp(chroma_type,"mono")==0){
+ src_c_dec_h=src_c_dec_v=0;
+ dst_c_dec_h=dst_c_dec_v=2;
+ y4m_dst_buf_read_sz=pic_w*pic_h;
+ y4m_aux_buf_sz=y4m_aux_buf_read_sz=0;
+ y4m_convert=y4m_convert_mono_420jpeg;
+ }
+ else{
+ fprintf(stderr,"Unknown chroma sampling type: %s\n",chroma_type);
+ exit(1);
+ }
+ /*The size of the final frame buffers is always computed from the
+ destination chroma decimation type.*/
+ y4m_dst_buf_sz=pic_w*pic_h+2*((pic_w+dst_c_dec_h-1)/dst_c_dec_h)*
+ ((pic_h+dst_c_dec_v-1)/dst_c_dec_v);
+
+ video=test;
+
+ fprintf(stderr,"File %s is %dx%d %.02f fps %s video.\n",
+ f,pic_w,pic_h,(double)video_fps_n/video_fps_d,chroma_type);
+
+ return;
+ }
+ }
+ fprintf(stderr,"Input file %s is neither a WAV nor YUV4MPEG2 file.\n",f);
+ exit(1);
+
+ riff_err:
+ fprintf(stderr,"EOF parsing RIFF file %s.\n",f);
+ exit(1);
+ yuv_err:
+ fprintf(stderr,"EOF parsing YUV4MPEG2 file %s.\n",f);
+ exit(1);
+
+}
+
+int spinner=0;
+char *spinascii="|/-\\";
+void spinnit(void){
+ spinner++;
+ if(spinner==4)spinner=0;
+ fprintf(stderr,"\r%c",spinascii[spinner]);
+}
+
+int fetch_and_process_audio(FILE *audio,ogg_page *audiopage,
+ ogg_stream_state *vo,
+ vorbis_dsp_state *vd,
+ vorbis_block *vb,
+ int audioflag){
+ static ogg_int64_t samples_sofar=0;
+ ogg_packet op;
+ int i,j;
+ ogg_int64_t beginsample = audio_hz*begin_sec + audio_hz*begin_usec*.000001;
+ ogg_int64_t endsample = audio_hz*end_sec + audio_hz*end_usec*.000001;
+
+ while(audio && !audioflag){
+ /* process any audio already buffered */
+ spinnit();
+ if(ogg_stream_pageout(vo,audiopage)>0) return 1;
+ if(ogg_stream_eos(vo))return 0;
+
+ {
+ /* read and process more audio */
+ signed char readbuffer[4096];
+ signed char *readptr=readbuffer;
+ int toread=4096/2/audio_ch;
+ int bytesread=fread(readbuffer,1,toread*2*audio_ch,audio);
+ int sampread=bytesread/2/audio_ch;
+ float **vorbis_buffer;
+ int count=0;
+
+ if(bytesread<=0 ||
+ (samples_sofar>=endsample && endsample>0)){
+ /* end of file. this can be done implicitly, but it's
+ easier to see here in non-clever fashion. Tell the
+ library we're at end of stream so that it can handle the
+ last frame and mark end of stream in the output properly */
+ vorbis_analysis_wrote(vd,0);
+ }else{
+ if(samples_sofar < beginsample){
+ if(samples_sofar+sampread > beginsample){
+ readptr += (beginsample-samples_sofar)*2*audio_ch;
+ sampread += samples_sofar-beginsample;
+ samples_sofar = sampread+beginsample;
+ }else{
+ samples_sofar += sampread;
+ sampread = 0;
+ }
+ }else{
+ samples_sofar += sampread;
+ }
+
+ if(samples_sofar > endsample && endsample > 0)
+ sampread-= (samples_sofar - endsample);
+
+ if(sampread>0){
+
+ vorbis_buffer=vorbis_analysis_buffer(vd,sampread);
+ /* uninterleave samples */
+ for(i=0;i=beginframe)
+ frame_state++;
+ }
+ /* check to see if there are dupes to flush */
+ if(th_encode_packetout(td,frame_state<1,op)>0)return 1;
+ if(frame_state<1){
+ /* can't get here unless YUV4MPEG stream has no video */
+ fprintf(stderr,"Video input contains no frames.\n");
+ exit(1);
+ }
+ /* Theora is a one-frame-in,one-frame-out system; submit a frame
+ for compression and pull out the packet */
+ /* in two-pass mode's second pass, we need to submit first-pass data */
+ if(passno==2){
+ for(;;){
+ static unsigned char buffer[80];
+ static int buf_pos;
+ int bytes;
+ /*Ask the encoder how many bytes it would like.*/
+ bytes=th_encode_ctl(td,TH_ENCCTL_2PASS_IN,NULL,0);
+ if(bytes<0){
+ fprintf(stderr,"Error submitting pass data in second pass.\n");
+ exit(1);
+ }
+ /*If it's got enough, stop.*/
+ if(bytes==0)break;
+ /*Read in some more bytes, if necessary.*/
+ if(bytes>80-buf_pos)bytes=80-buf_pos;
+ if(bytes>0&&fread(buffer+buf_pos,1,bytes,twopass_file)=bytes)buf_pos=0;
+ /*Otherwise remember how much it used.*/
+ else buf_pos+=ret;
+ }
+ }
+ /*We submit the buffer using the size of the picture region.
+ libtheora will pad the picture region out to the full frame size for us,
+ whether we pass in a full frame or not.*/
+ ycbcr[0].width=pic_w;
+ ycbcr[0].height=pic_h;
+ ycbcr[0].stride=pic_w;
+ ycbcr[0].data=yuvframe[0];
+ ycbcr[1].width=c_w;
+ ycbcr[1].height=c_h;
+ ycbcr[1].stride=c_w;
+ ycbcr[1].data=yuvframe[0]+pic_sz;
+ ycbcr[2].width=c_w;
+ ycbcr[2].height=c_h;
+ ycbcr[2].stride=c_w;
+ ycbcr[2].data=yuvframe[0]+pic_sz+c_sz;
+ th_encode_ycbcr_in(td,ycbcr);
+ {
+ unsigned char *temp=yuvframe[0];
+ yuvframe[0]=yuvframe[1];
+ yuvframe[1]=temp;
+ frame_state--;
+ }
+ /* in two-pass mode's first pass we need to extract and save the pass data */
+ if(passno==1){
+ unsigned char *buffer;
+ int bytes = th_encode_ctl(td, TH_ENCCTL_2PASS_OUT, &buffer, sizeof(buffer));
+ if(bytes<0){
+ fprintf(stderr,"Could not read two-pass data from encoder.\n");
+ exit(1);
+ }
+ if(fwrite(buffer,1,bytes,twopass_file)0) return 1;
+ if(ogg_stream_eos(to)) return 0;
+ ret=fetch_and_process_video_packet(video,twopass_file,passno,td,&op);
+ if(ret<=0)return 0;
+ ogg_stream_packetin(to,&op);
+ }
+ return videoflag;
+}
+
+static int ilog(unsigned _v){
+ int ret;
+ for(ret=0;_v;ret++)_v>>=1;
+ return ret;
+}
+
+int main(int argc,char *argv[]){
+ int c,long_option_index,ret;
+
+ ogg_stream_state to; /* take physical pages, weld into a logical
+ stream of packets */
+ ogg_stream_state vo; /* take physical pages, weld into a logical
+ stream of packets */
+ ogg_page og; /* one Ogg bitstream page. Vorbis packets are inside */
+ ogg_packet op; /* one raw packet of data for decode */
+
+ th_enc_ctx *td;
+ th_info ti;
+ th_comment tc;
+
+ vorbis_info vi; /* struct that stores all the static vorbis bitstream
+ settings */
+ vorbis_comment vc; /* struct that stores all the user comments */
+
+ vorbis_dsp_state vd; /* central working state for the packet->PCM decoder */
+ vorbis_block vb; /* local working space for packet->PCM decode */
+
+ int speed=-1;
+ int audioflag=0;
+ int videoflag=0;
+ int akbps=0;
+ int vkbps=0;
+ int soft_target=0;
+
+ ogg_int64_t audio_bytesout=0;
+ ogg_int64_t video_bytesout=0;
+ double timebase;
+
+ FILE *outfile = stdout;
+
+ FILE *twopass_file = NULL;
+ fpos_t video_rewind_pos;
+ int twopass=0;
+ int passno;
+
+#ifdef _WIN32 /* We need to set stdin/stdout to binary mode. Damn windows. */
+ /* if we were reading/writing a file, it would also need to in
+ binary mode, eg, fopen("file.wav","wb"); */
+ /* Beware the evil ifdef. We avoid these where we can, but this one we
+ cannot. Don't add any more, you'll probably go to hell if you do. */
+ _setmode( _fileno( stdin ), _O_BINARY );
+ _setmode( _fileno( stdout ), _O_BINARY );
+#endif
+
+ while((c=getopt_long(argc,argv,optstring,options,&long_option_index))!=EOF){
+ switch(c){
+ case 'o':
+ outfile=fopen(optarg,"wb");
+ if(outfile==NULL){
+ fprintf(stderr,"Unable to open output file '%s'\n", optarg);
+ exit(1);
+ }
+ break;;
+
+ case 'a':
+ audio_q=(float)(atof(optarg)*.099);
+ if(audio_q<-.1 || audio_q>1){
+ fprintf(stderr,"Illegal audio quality (choose -1 through 10)\n");
+ exit(1);
+ }
+ audio_r=-1;
+ break;
+
+ case 'v':
+ video_q=(int)rint(6.3*atof(optarg));
+ if(video_q<0 || video_q>63){
+ fprintf(stderr,"Illegal video quality (choose 0 through 10)\n");
+ exit(1);
+ }
+ break;
+
+ case 'A':
+ audio_r=(int)(atof(optarg)*1000);
+ if(audio_q<0){
+ fprintf(stderr,"Illegal audio quality (choose > 0 please)\n");
+ exit(1);
+ }
+ audio_q=-99;
+ break;
+
+ case 'V':
+ video_r=(int)rint(atof(optarg)*1000);
+ if(video_r<1){
+ fprintf(stderr,"Illegal video bitrate (choose > 0 please)\n");
+ exit(1);
+ }
+ break;
+
+ case '\1':
+ soft_target=1;
+ break;
+
+ case 's':
+ video_par_n=(int)rint(atof(optarg));
+ break;
+
+ case 'S':
+ video_par_d=(int)rint(atof(optarg));
+ break;
+
+ case 'f':
+ video_fps_n=(int)rint(atof(optarg));
+ break;
+
+ case 'F':
+ video_fps_d=(int)rint(atof(optarg));
+ break;
+
+ case 'c':
+ vp3_compatible=1;
+ break;
+
+ case 'k':
+ keyframe_frequency=rint(atof(optarg));
+ if(keyframe_frequency<1 || keyframe_frequency>2147483647){
+ fprintf(stderr,"Illegal keyframe frequency\n");
+ exit(1);
+ }
+ break;
+
+ case 'd':
+ buf_delay=atoi(optarg);
+ if(buf_delay<=0){
+ fprintf(stderr,"Illegal buffer delay\n");
+ exit(1);
+ }
+ break;
+
+ case 'z':
+ speed=atoi(optarg);
+ if(speed<0){
+ fprintf(stderr,"Illegal speed level\n");
+ exit(1);
+ }
+ break;
+
+ case 'b':
+ {
+ char *pos=strchr(optarg,':');
+ begin_sec=atol(optarg);
+ if(pos){
+ char *pos2=strchr(++pos,':');
+ begin_sec*=60;
+ begin_sec+=atol(pos);
+ if(pos2){
+ pos2++;
+ begin_sec*=60;
+ begin_sec+=atol(pos2);
+ pos=pos2;
+ }
+ }else
+ pos=optarg;
+ pos=strchr(pos,'.');
+ if(pos){
+ int digits = strlen(++pos);
+ begin_usec=atol(pos);
+ while(digits++ < 6)
+ begin_usec*=10;
+ }
+ }
+ break;
+ case 'e':
+ {
+ char *pos=strchr(optarg,':');
+ end_sec=atol(optarg);
+ if(pos){
+ char *pos2=strchr(++pos,':');
+ end_sec*=60;
+ end_sec+=atol(pos);
+ if(pos2){
+ pos2++;
+ end_sec*=60;
+ end_sec+=atol(pos2);
+ pos=pos2;
+ }
+ }else
+ pos=optarg;
+ pos=strchr(pos,'.');
+ if(pos){
+ int digits = strlen(++pos);
+ end_usec=atol(pos);
+ while(digits++ < 6)
+ end_usec*=10;
+ }
+ }
+ break;
+ case '\2':
+ twopass=3; /* perform both passes */
+ twopass_file=tmpfile();
+ if(!twopass_file){
+ fprintf(stderr,"Unable to open temporary file for twopass data\n");
+ exit(1);
+ }
+ break;
+ case '\3':
+ twopass=1; /* perform first pass */
+ twopass_file=fopen(optarg,"wb");
+ if(!twopass_file){
+ fprintf(stderr,"Unable to open \'%s\' for twopass data\n",optarg);
+ exit(1);
+ }
+ break;
+ case '\4':
+ twopass=2; /* perform second pass */
+ twopass_file=fopen(optarg,"rb");
+ if(!twopass_file){
+ fprintf(stderr,"Unable to open twopass data file \'%s\'",optarg);
+ exit(1);
+ }
+ break;
+
+ default:
+ usage();
+ }
+ }
+
+ if(soft_target){
+ if(video_r<=0){
+ fprintf(stderr,"Soft rate target (--soft-target) requested without a bitrate (-V).\n");
+ exit(1);
+ }
+ if(video_q==-1)
+ video_q=0;
+ }else{
+ if(video_q==-1){
+ if(video_r>0)
+ video_q=0;
+ else
+ video_q=48;
+ }
+ }
+
+ if(keyframe_frequency<=0){
+ /*Use a default keyframe frequency of 64 for 1-pass (streaming) mode, and
+ 256 for two-pass mode.*/
+ keyframe_frequency=twopass?256:64;
+ }
+
+ while(optind-99)
+ ret = vorbis_encode_init_vbr(&vi,audio_ch,audio_hz,audio_q);
+ else
+ ret = vorbis_encode_init(&vi,audio_ch,audio_hz,-1,
+ (int)(64870*(ogg_int64_t)audio_r>>16),-1);
+ if(ret){
+ fprintf(stderr,"The Vorbis encoder could not set up a mode according to\n"
+ "the requested quality or bitrate.\n\n");
+ exit(1);
+ }
+
+ vorbis_comment_init(&vc);
+ vorbis_analysis_init(&vd,&vi);
+ vorbis_block_init(&vd,&vb);
+ }
+
+ for(passno=(twopass==3?1:twopass);passno<=(twopass==3?2:twopass);passno++){
+ /* Set up Theora encoder */
+ if(!video){
+ fprintf(stderr,"No video files submitted for compression?\n");
+ exit(1);
+ }
+ /* Theora has a divisible-by-sixteen restriction for the encoded frame size */
+ /* scale the picture size up to the nearest /16 and calculate offsets */
+ frame_w=pic_w+15&~0xF;
+ frame_h=pic_h+15&~0xF;
+ /*Force the offsets to be even so that chroma samples line up like we
+ expect.*/
+ pic_x=frame_w-pic_w>>1&~1;
+ pic_y=frame_h-pic_h>>1&~1;
+ th_info_init(&ti);
+ ti.frame_width=frame_w;
+ ti.frame_height=frame_h;
+ ti.pic_width=pic_w;
+ ti.pic_height=pic_h;
+ ti.pic_x=pic_x;
+ ti.pic_y=pic_y;
+ ti.fps_numerator=video_fps_n;
+ ti.fps_denominator=video_fps_d;
+ ti.aspect_numerator=video_par_n;
+ ti.aspect_denominator=video_par_d;
+ ti.colorspace=TH_CS_UNSPECIFIED;
+ /*Account for the Ogg page overhead.
+ This is 1 byte per 255 for lacing values, plus 26 bytes per 4096 bytes for
+ the page header, plus approximately 1/2 byte per packet (not accounted for
+ here).*/
+ ti.target_bitrate=(int)(64870*(ogg_int64_t)video_r>>16);
+ ti.quality=video_q;
+ ti.keyframe_granule_shift=ilog(keyframe_frequency-1);
+ if(dst_c_dec_h==2){
+ if(dst_c_dec_v==2)ti.pixel_fmt=TH_PF_420;
+ else ti.pixel_fmt=TH_PF_422;
+ }
+ else ti.pixel_fmt=TH_PF_444;
+ td=th_encode_alloc(&ti);
+ th_info_clear(&ti);
+ /* setting just the granule shift only allows power-of-two keyframe
+ spacing. Set the actual requested spacing. */
+ ret=th_encode_ctl(td,TH_ENCCTL_SET_KEYFRAME_FREQUENCY_FORCE,
+ &keyframe_frequency,sizeof(keyframe_frequency-1));
+ if(ret<0){
+ fprintf(stderr,"Could not set keyframe interval to %d.\n",(int)keyframe_frequency);
+ }
+ if(vp3_compatible){
+ ret=th_encode_ctl(td,TH_ENCCTL_SET_VP3_COMPATIBLE,&vp3_compatible,
+ sizeof(vp3_compatible));
+ if(ret<0||!vp3_compatible){
+ fprintf(stderr,"Could not enable strict VP3 compatibility.\n");
+ if(ret>=0){
+ fprintf(stderr,"Ensure your source format is supported by VP3.\n");
+ fprintf(stderr,
+ "(4:2:0 pixel format, width and height multiples of 16).\n");
+ }
+ }
+ }
+ if(soft_target){
+ /* reverse the rate control flags to favor a 'long time' strategy */
+ int arg = TH_RATECTL_CAP_UNDERFLOW;
+ ret=th_encode_ctl(td,TH_ENCCTL_SET_RATE_FLAGS,&arg,sizeof(arg));
+ if(ret<0)
+ fprintf(stderr,"Could not set encoder flags for --soft-target\n");
+ /* Default buffer control is overridden on two-pass */
+ if(!twopass&&buf_delay<0){
+ if((keyframe_frequency*7>>1) > 5*video_fps_n/video_fps_d)
+ arg=keyframe_frequency*7>>1;
+ else
+ arg=5*video_fps_n/video_fps_d;
+ ret=th_encode_ctl(td,TH_ENCCTL_SET_RATE_BUFFER,&arg,sizeof(arg));
+ if(ret<0)
+ fprintf(stderr,"Could not set rate control buffer for --soft-target\n");
+ }
+ }
+ /* set up two-pass if needed */
+ if(passno==1){
+ unsigned char *buffer;
+ int bytes;
+ bytes=th_encode_ctl(td,TH_ENCCTL_2PASS_OUT,&buffer,sizeof(buffer));
+ if(bytes<0){
+ fprintf(stderr,"Could not set up the first pass of two-pass mode.\n");
+ fprintf(stderr,"Did you remember to specify an estimated bitrate?\n");
+ exit(1);
+ }
+ /*Perform a seek test to ensure we can overwrite this placeholder data at
+ the end; this is better than letting the user sit through a whole
+ encode only to find out their pass 1 file is useless at the end.*/
+ if(fseek(twopass_file,0,SEEK_SET)<0){
+ fprintf(stderr,"Unable to seek in two-pass data file.\n");
+ exit(1);
+ }
+ if(fwrite(buffer,1,bytes,twopass_file)=0){
+ ret=th_encode_ctl(td,TH_ENCCTL_SET_RATE_BUFFER,
+ &buf_delay,sizeof(buf_delay));
+ if(ret<0){
+ fprintf(stderr,"Warning: could not set desired buffer delay.\n");
+ }
+ }
+ /*Speed should also be set after the current encoder mode is established,
+ since the available speed levels may change depending.*/
+ if(speed>=0){
+ int speed_max;
+ int ret;
+ ret=th_encode_ctl(td,TH_ENCCTL_GET_SPLEVEL_MAX,
+ &speed_max,sizeof(speed_max));
+ if(ret<0){
+ fprintf(stderr,"Warning: could not determine maximum speed level.\n");
+ speed_max=0;
+ }
+ ret=th_encode_ctl(td,TH_ENCCTL_SET_SPLEVEL,&speed,sizeof(speed));
+ if(ret<0){
+ fprintf(stderr,"Warning: could not set speed level to %i of %i\n",
+ speed,speed_max);
+ if(speed>speed_max){
+ fprintf(stderr,"Setting it to %i instead\n",speed_max);
+ }
+ ret=th_encode_ctl(td,TH_ENCCTL_SET_SPLEVEL,
+ &speed_max,sizeof(speed_max));
+ if(ret<0){
+ fprintf(stderr,"Warning: could not set speed level to %i of %i\n",
+ speed_max,speed_max);
+ }
+ }
+ }
+ /* write the bitstream header packets with proper page interleave */
+ th_comment_init(&tc);
+ /* first packet will get its own page automatically */
+ if(th_encode_flushheader(td,&tc,&op)<=0){
+ fprintf(stderr,"Internal Theora library error.\n");
+ exit(1);
+ }
+ if(passno!=1){
+ ogg_stream_packetin(&to,&op);
+ if(ogg_stream_pageout(&to,&og)!=1){
+ fprintf(stderr,"Internal Ogg library error.\n");
+ exit(1);
+ }
+ fwrite(og.header,1,og.header_len,outfile);
+ fwrite(og.body,1,og.body_len,outfile);
+ }
+ /* create the remaining theora headers */
+ for(;;){
+ ret=th_encode_flushheader(td,&tc,&op);
+ if(ret<0){
+ fprintf(stderr,"Internal Theora library error.\n");
+ exit(1);
+ }
+ else if(!ret)break;
+ if(passno!=1)ogg_stream_packetin(&to,&op);
+ }
+ if(audio && passno!=1){
+ ogg_packet header;
+ ogg_packet header_comm;
+ ogg_packet header_code;
+ vorbis_analysis_headerout(&vd,&vc,&header,&header_comm,&header_code);
+ ogg_stream_packetin(&vo,&header); /* automatically placed in its own
+ page */
+ if(ogg_stream_pageout(&vo,&og)!=1){
+ fprintf(stderr,"Internal Ogg library error.\n");
+ exit(1);
+ }
+ fwrite(og.header,1,og.header_len,outfile);
+ fwrite(og.body,1,og.body_len,outfile);
+ /* remaining vorbis header packets */
+ ogg_stream_packetin(&vo,&header_comm);
+ ogg_stream_packetin(&vo,&header_code);
+ }
+ /* Flush the rest of our headers. This ensures
+ the actual data in each stream will start
+ on a new page, as per spec. */
+ if(passno!=1){
+ for(;;){
+ int result = ogg_stream_flush(&to,&og);
+ if(result<0){
+ /* can't get here */
+ fprintf(stderr,"Internal Ogg library error.\n");
+ exit(1);
+ }
+ if(result==0)break;
+ fwrite(og.header,1,og.header_len,outfile);
+ fwrite(og.body,1,og.body_len,outfile);
+ }
+ }
+ if(audio && passno!=1){
+ for(;;){
+ int result=ogg_stream_flush(&vo,&og);
+ if(result<0){
+ /* can't get here */
+ fprintf(stderr,"Internal Ogg library error.\n");
+ exit(1);
+ }
+ if(result==0)break;
+ fwrite(og.header,1,og.header_len,outfile);
+ fwrite(og.body,1,og.body_len,outfile);
+ }
+ }
+ /* setup complete. Raw processing loop */
+ switch(passno){
+ case 0: case 2:
+ fprintf(stderr,"\rCompressing.... \n");
+ break;
+ case 1:
+ fprintf(stderr,"\rScanning first pass.... \n");
+ break;
+ }
+ for(;;){
+ int audio_or_video=-1;
+ if(passno==1){
+ ogg_packet op;
+ int ret=fetch_and_process_video_packet(video,twopass_file,passno,td,&op);
+ if(ret<0)break;
+ if(op.e_o_s)break; /* end of stream */
+ timebase=th_granule_time(td,op.granulepos);
+ audio_or_video=1;
+ }else{
+ double audiotime;
+ double videotime;
+ ogg_page audiopage;
+ ogg_page videopage;
+ /* is there an audio page flushed? If not, fetch one if possible */
+ audioflag=fetch_and_process_audio(audio,&audiopage,&vo,&vd,&vb,audioflag);
+ /* is there a video page flushed? If not, fetch one if possible */
+ videoflag=fetch_and_process_video(video,&videopage,&to,td,twopass_file,passno,videoflag);
+ /* no pages of either? Must be end of stream. */
+ if(!audioflag && !videoflag)break;
+ /* which is earlier; the end of the audio page or the end of the
+ video page? Flush the earlier to stream */
+ audiotime=
+ audioflag?vorbis_granule_time(&vd,ogg_page_granulepos(&audiopage)):-1;
+ videotime=
+ videoflag?th_granule_time(td,ogg_page_granulepos(&videopage)):-1;
+ if(!audioflag){
+ audio_or_video=1;
+ } else if(!videoflag) {
+ audio_or_video=0;
+ } else {
+ if(audiotime 0){
+ int hundredths=(int)(timebase*100-(long)timebase*100);
+ int seconds=(long)timebase%60;
+ int minutes=((long)timebase/60)%60;
+ int hours=(long)timebase/3600;
+ if(audio_or_video)vkbps=(int)rint(video_bytesout*8./timebase*.001);
+ else akbps=(int)rint(audio_bytesout*8./timebase*.001);
+ fprintf(stderr,
+ "\r %d:%02d:%02d.%02d audio: %dkbps video: %dkbps ",
+ hours,minutes,seconds,hundredths,akbps,vkbps);
+ }
+ }
+ if(video)th_encode_free(td);
+ }
+
+ /* clear out state */
+ if(audio && twopass!=1){
+ ogg_stream_clear(&vo);
+ vorbis_block_clear(&vb);
+ vorbis_dsp_clear(&vd);
+ vorbis_comment_clear(&vc);
+ vorbis_info_clear(&vi);
+ if(audio!=stdin)fclose(audio);
+ }
+ if(video){
+ ogg_stream_clear(&to);
+ th_comment_clear(&tc);
+ if(video!=stdin)fclose(video);
+ }
+
+ if(outfile && outfile!=stdout)fclose(outfile);
+ if(twopass_file)fclose(twopass_file);
+
+ fprintf(stderr,"\r \ndone.\n\n");
+
+ return(0);
+
+}
diff --git a/libs/libtheora-1.1/examples/getopt.c b/libs/libtheora-1.1/examples/getopt.c
new file mode 100644
index 00000000..b75e3c62
--- /dev/null
+++ b/libs/libtheora-1.1/examples/getopt.c
@@ -0,0 +1,1055 @@
+/* Getopt for GNU.
+ NOTE: getopt is now part of the C library, so if you don't know what
+ "Keep this file name-space clean" means, talk to drepper@gnu.org
+ before changing it!
+ Copyright (C) 1987,88,89,90,91,92,93,94,95,96,98,99,2000,2001
+ Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, write to the Free
+ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+ 02111-1307 USA. */
+
+/* This tells Alpha OSF/1 not to define a getopt prototype in .
+ Ditto for AIX 3.2 and . */
+#ifndef _NO_PROTO
+# define _NO_PROTO
+#endif
+
+#ifdef HAVE_CONFIG_H
+# include
+#endif
+
+#if !defined __STDC__ || !__STDC__
+/* This is a separate conditional since some stdc systems
+ reject `defined (const)'. */
+# ifndef const
+# define const
+# endif
+#endif
+
+#include
+
+/* Comment out all this code if we are using the GNU C Library, and are not
+ actually compiling the library itself. This code is part of the GNU C
+ Library, but also included in many other GNU distributions. Compiling
+ and linking in this code is a waste when using the GNU C library
+ (especially if it is a shared library). Rather than having every GNU
+ program understand `configure --with-gnu-libc' and omit the object files,
+ it is simpler to just do this in the source for each such file. */
+
+#define GETOPT_INTERFACE_VERSION 2
+#if !defined _LIBC && defined __GLIBC__ && __GLIBC__ >= 2
+# include
+# if _GNU_GETOPT_INTERFACE_VERSION == GETOPT_INTERFACE_VERSION
+# define ELIDE_CODE
+# endif
+#endif
+
+#ifndef ELIDE_CODE
+
+
+/* This needs to come after some library #include
+ to get __GNU_LIBRARY__ defined. */
+#ifdef __GNU_LIBRARY__
+/* Don't include stdlib.h for non-GNU C libraries because some of them
+ contain conflicting prototypes for getopt. */
+# include
+# include
+#endif /* GNU C library. */
+
+#ifdef VMS
+# include
+# if HAVE_STRING_H - 0
+# include
+# endif
+#endif
+
+#ifndef _
+/* This is for other GNU distributions with internationalized messages. */
+# if defined HAVE_LIBINTL_H || defined _LIBC
+# include
+# ifndef _
+# define _(msgid) gettext (msgid)
+# endif
+# else
+# define _(msgid) (msgid)
+# endif
+#endif
+
+/* This version of `getopt' appears to the caller like standard Unix `getopt'
+ but it behaves differently for the user, since it allows the user
+ to intersperse the options with the other arguments.
+
+ As `getopt' works, it permutes the elements of ARGV so that,
+ when it is done, all the options precede everything else. Thus
+ all application programs are extended to handle flexible argument order.
+
+ Setting the environment variable POSIXLY_CORRECT disables permutation.
+ Then the behavior is completely standard.
+
+ GNU application programs can use a third alternative mode in which
+ they can distinguish the relative order of options and other arguments. */
+
+#include "getopt.h"
+
+/* For communication from `getopt' to the caller.
+ When `getopt' finds an option that takes an argument,
+ the argument value is returned here.
+ Also, when `ordering' is RETURN_IN_ORDER,
+ each non-option ARGV-element is returned here. */
+
+char *optarg;
+
+/* Index in ARGV of the next element to be scanned.
+ This is used for communication to and from the caller
+ and for communication between successive calls to `getopt'.
+
+ On entry to `getopt', zero means this is the first call; initialize.
+
+ When `getopt' returns -1, this is the index of the first of the
+ non-option elements that the caller should itself scan.
+
+ Otherwise, `optind' communicates from one call to the next
+ how much of ARGV has been scanned so far. */
+
+/* 1003.2 says this must be 1 before any call. */
+int optind = 1;
+
+/* Formerly, initialization of getopt depended on optind==0, which
+ causes problems with re-calling getopt as programs generally don't
+ know that. */
+
+int __getopt_initialized;
+
+/* The next char to be scanned in the option-element
+ in which the last option character we returned was found.
+ This allows us to pick up the scan where we left off.
+
+ If this is zero, or a null string, it means resume the scan
+ by advancing to the next ARGV-element. */
+
+static char *nextchar;
+
+/* Callers store zero here to inhibit the error message
+ for unrecognized options. */
+
+int opterr = 1;
+
+/* Set to an option character which was unrecognized.
+ This must be initialized on some systems to avoid linking in the
+ system's own getopt implementation. */
+
+int optopt = '?';
+
+/* Describe how to deal with options that follow non-option ARGV-elements.
+
+ If the caller did not specify anything,
+ the default is REQUIRE_ORDER if the environment variable
+ POSIXLY_CORRECT is defined, PERMUTE otherwise.
+
+ REQUIRE_ORDER means don't recognize them as options;
+ stop option processing when the first non-option is seen.
+ This is what Unix does.
+ This mode of operation is selected by either setting the environment
+ variable POSIXLY_CORRECT, or using `+' as the first character
+ of the list of option characters.
+
+ PERMUTE is the default. We permute the contents of ARGV as we scan,
+ so that eventually all the non-options are at the end. This allows options
+ to be given in any order, even with programs that were not written to
+ expect this.
+
+ RETURN_IN_ORDER is an option available to programs that were written
+ to expect options and other ARGV-elements in any order and that care about
+ the ordering of the two. We describe each non-option ARGV-element
+ as if it were the argument of an option with character code 1.
+ Using `-' as the first character of the list of option characters
+ selects this mode of operation.
+
+ The special argument `--' forces an end of option-scanning regardless
+ of the value of `ordering'. In the case of RETURN_IN_ORDER, only
+ `--' can cause `getopt' to return -1 with `optind' != ARGC. */
+
+static enum
+{
+ REQUIRE_ORDER, PERMUTE, RETURN_IN_ORDER
+} ordering;
+
+/* Value of POSIXLY_CORRECT environment variable. */
+static char *posixly_correct;
+
+#ifdef __GNU_LIBRARY__
+/* We want to avoid inclusion of string.h with non-GNU libraries
+ because there are many ways it can cause trouble.
+ On some systems, it contains special magic macros that don't work
+ in GCC. */
+# include
+# define my_index strchr
+#else
+
+# if HAVE_STRING_H
+# include
+# else
+# include
+# endif
+
+/* Avoid depending on library functions or files
+ whose names are inconsistent. */
+
+#ifndef getenv
+extern char *getenv ();
+#endif
+
+static char *
+my_index (str, chr)
+ const char *str;
+ int chr;
+{
+ while (*str)
+ {
+ if (*str == chr)
+ return (char *) str;
+ str++;
+ }
+ return 0;
+}
+
+/* If using GCC, we can safely declare strlen this way.
+ If not using GCC, it is ok not to declare it. */
+#ifdef __GNUC__
+/* Note that Motorola Delta 68k R3V7 comes with GCC but not stddef.h.
+ That was relevant to code that was here before. */
+# if (!defined __STDC__ || !__STDC__) && !defined strlen
+/* gcc with -traditional declares the built-in strlen to return int,
+ and has done so at least since version 2.4.5. -- rms. */
+extern int strlen (const char *);
+# endif /* not __STDC__ */
+#endif /* __GNUC__ */
+
+#endif /* not __GNU_LIBRARY__ */
+
+/* Handle permutation of arguments. */
+
+/* Describe the part of ARGV that contains non-options that have
+ been skipped. `first_nonopt' is the index in ARGV of the first of them;
+ `last_nonopt' is the index after the last of them. */
+
+static int first_nonopt;
+static int last_nonopt;
+
+#ifdef _LIBC
+/* Stored original parameters.
+ XXX This is no good solution. We should rather copy the args so
+ that we can compare them later. But we must not use malloc(3). */
+extern int __libc_argc;
+extern char **__libc_argv;
+
+/* Bash 2.0 gives us an environment variable containing flags
+ indicating ARGV elements that should not be considered arguments. */
+
+# ifdef USE_NONOPTION_FLAGS
+/* Defined in getopt_init.c */
+extern char *__getopt_nonoption_flags;
+
+static int nonoption_flags_max_len;
+static int nonoption_flags_len;
+# endif
+
+# ifdef USE_NONOPTION_FLAGS
+# define SWAP_FLAGS(ch1, ch2) \
+ if (nonoption_flags_len > 0) \
+ { \
+ char __tmp = __getopt_nonoption_flags[ch1]; \
+ __getopt_nonoption_flags[ch1] = __getopt_nonoption_flags[ch2]; \
+ __getopt_nonoption_flags[ch2] = __tmp; \
+ }
+# else
+# define SWAP_FLAGS(ch1, ch2)
+# endif
+#else /* !_LIBC */
+# define SWAP_FLAGS(ch1, ch2)
+#endif /* _LIBC */
+
+/* Exchange two adjacent subsequences of ARGV.
+ One subsequence is elements [first_nonopt,last_nonopt)
+ which contains all the non-options that have been skipped so far.
+ The other is elements [last_nonopt,optind), which contains all
+ the options processed since those non-options were skipped.
+
+ `first_nonopt' and `last_nonopt' are relocated so that they describe
+ the new indices of the non-options in ARGV after they are moved. */
+
+#if defined __STDC__ && __STDC__
+static void exchange (char **);
+#endif
+
+static void
+exchange (argv)
+ char **argv;
+{
+ int bottom = first_nonopt;
+ int middle = last_nonopt;
+ int top = optind;
+ char *tem;
+
+ /* Exchange the shorter segment with the far end of the longer segment.
+ That puts the shorter segment into the right place.
+ It leaves the longer segment in the right place overall,
+ but it consists of two parts that need to be swapped next. */
+
+#if defined _LIBC && defined USE_NONOPTION_FLAGS
+ /* First make sure the handling of the `__getopt_nonoption_flags'
+ string can work normally. Our top argument must be in the range
+ of the string. */
+ if (nonoption_flags_len > 0 && top >= nonoption_flags_max_len)
+ {
+ /* We must extend the array. The user plays games with us and
+ presents new arguments. */
+ char *new_str = malloc (top + 1);
+ if (new_str == NULL)
+ nonoption_flags_len = nonoption_flags_max_len = 0;
+ else
+ {
+ memset (__mempcpy (new_str, __getopt_nonoption_flags,
+ nonoption_flags_max_len),
+ '\0', top + 1 - nonoption_flags_max_len);
+ nonoption_flags_max_len = top + 1;
+ __getopt_nonoption_flags = new_str;
+ }
+ }
+#endif
+
+ while (top > middle && middle > bottom)
+ {
+ if (top - middle > middle - bottom)
+ {
+ /* Bottom segment is the short one. */
+ int len = middle - bottom;
+ register int i;
+
+ /* Swap it with the top part of the top segment. */
+ for (i = 0; i < len; i++)
+ {
+ tem = argv[bottom + i];
+ argv[bottom + i] = argv[top - (middle - bottom) + i];
+ argv[top - (middle - bottom) + i] = tem;
+ SWAP_FLAGS (bottom + i, top - (middle - bottom) + i);
+ }
+ /* Exclude the moved bottom segment from further swapping. */
+ top -= len;
+ }
+ else
+ {
+ /* Top segment is the short one. */
+ int len = top - middle;
+ register int i;
+
+ /* Swap it with the bottom part of the bottom segment. */
+ for (i = 0; i < len; i++)
+ {
+ tem = argv[bottom + i];
+ argv[bottom + i] = argv[middle + i];
+ argv[middle + i] = tem;
+ SWAP_FLAGS (bottom + i, middle + i);
+ }
+ /* Exclude the moved top segment from further swapping. */
+ bottom += len;
+ }
+ }
+
+ /* Update records for the slots the non-options now occupy. */
+
+ first_nonopt += (optind - last_nonopt);
+ last_nonopt = optind;
+}
+
+/* Initialize the internal data when the first call is made. */
+
+#if defined __STDC__ && __STDC__
+static const char *_getopt_initialize (int, char *const *, const char *);
+#endif
+static const char *
+_getopt_initialize (argc, argv, optstring)
+ int argc;
+ char *const *argv;
+ const char *optstring;
+{
+ /* Start processing options with ARGV-element 1 (since ARGV-element 0
+ is the program name); the sequence of previously skipped
+ non-option ARGV-elements is empty. */
+
+ first_nonopt = last_nonopt = optind;
+
+ nextchar = NULL;
+
+ posixly_correct = getenv ("POSIXLY_CORRECT");
+
+ /* Determine how to handle the ordering of options and nonoptions. */
+
+ if (optstring[0] == '-')
+ {
+ ordering = RETURN_IN_ORDER;
+ ++optstring;
+ }
+ else if (optstring[0] == '+')
+ {
+ ordering = REQUIRE_ORDER;
+ ++optstring;
+ }
+ else if (posixly_correct != NULL)
+ ordering = REQUIRE_ORDER;
+ else
+ ordering = PERMUTE;
+
+#if defined _LIBC && defined USE_NONOPTION_FLAGS
+ if (posixly_correct == NULL
+ && argc == __libc_argc && argv == __libc_argv)
+ {
+ if (nonoption_flags_max_len == 0)
+ {
+ if (__getopt_nonoption_flags == NULL
+ || __getopt_nonoption_flags[0] == '\0')
+ nonoption_flags_max_len = -1;
+ else
+ {
+ const char *orig_str = __getopt_nonoption_flags;
+ int len = nonoption_flags_max_len = strlen (orig_str);
+ if (nonoption_flags_max_len < argc)
+ nonoption_flags_max_len = argc;
+ __getopt_nonoption_flags =
+ (char *) malloc (nonoption_flags_max_len);
+ if (__getopt_nonoption_flags == NULL)
+ nonoption_flags_max_len = -1;
+ else
+ memset (__mempcpy (__getopt_nonoption_flags, orig_str, len),
+ '\0', nonoption_flags_max_len - len);
+ }
+ }
+ nonoption_flags_len = nonoption_flags_max_len;
+ }
+ else
+ nonoption_flags_len = 0;
+#endif
+
+ return optstring;
+}
+
+/* Scan elements of ARGV (whose length is ARGC) for option characters
+ given in OPTSTRING.
+
+ If an element of ARGV starts with '-', and is not exactly "-" or "--",
+ then it is an option element. The characters of this element
+ (aside from the initial '-') are option characters. If `getopt'
+ is called repeatedly, it returns successively each of the option characters
+ from each of the option elements.
+
+ If `getopt' finds another option character, it returns that character,
+ updating `optind' and `nextchar' so that the next call to `getopt' can
+ resume the scan with the following option character or ARGV-element.
+
+ If there are no more option characters, `getopt' returns -1.
+ Then `optind' is the index in ARGV of the first ARGV-element
+ that is not an option. (The ARGV-elements have been permuted
+ so that those that are not options now come last.)
+
+ OPTSTRING is a string containing the legitimate option characters.
+ If an option character is seen that is not listed in OPTSTRING,
+ return '?' after printing an error message. If you set `opterr' to
+ zero, the error message is suppressed but we still return '?'.
+
+ If a char in OPTSTRING is followed by a colon, that means it wants an arg,
+ so the following text in the same ARGV-element, or the text of the following
+ ARGV-element, is returned in `optarg'. Two colons mean an option that
+ wants an optional arg; if there is text in the current ARGV-element,
+ it is returned in `optarg', otherwise `optarg' is set to zero.
+
+ If OPTSTRING starts with `-' or `+', it requests different methods of
+ handling the non-option ARGV-elements.
+ See the comments about RETURN_IN_ORDER and REQUIRE_ORDER, above.
+
+ Long-named options begin with `--' instead of `-'.
+ Their names may be abbreviated as long as the abbreviation is unique
+ or is an exact match for some defined option. If they have an
+ argument, it follows the option name in the same ARGV-element, separated
+ from the option name by a `=', or else the in next ARGV-element.
+ When `getopt' finds a long-named option, it returns 0 if that option's
+ `flag' field is nonzero, the value of the option's `val' field
+ if the `flag' field is zero.
+
+ The elements of ARGV aren't really const, because we permute them.
+ But we pretend they're const in the prototype to be compatible
+ with other systems.
+
+ LONGOPTS is a vector of `struct option' terminated by an
+ element containing a name which is zero.
+
+ LONGIND returns the index in LONGOPT of the long-named option found.
+ It is only valid when a long-named option has been found by the most
+ recent call.
+
+ If LONG_ONLY is nonzero, '-' as well as '--' can introduce
+ long-named options. */
+
+int
+_getopt_internal (argc, argv, optstring, longopts, longind, long_only)
+ int argc;
+ char *const *argv;
+ const char *optstring;
+ const struct option *longopts;
+ int *longind;
+ int long_only;
+{
+ int print_errors = opterr;
+ if (optstring[0] == ':')
+ print_errors = 0;
+
+ if (argc < 1)
+ return -1;
+
+ optarg = NULL;
+
+ if (optind == 0 || !__getopt_initialized)
+ {
+ if (optind == 0)
+ optind = 1; /* Don't scan ARGV[0], the program name. */
+ optstring = _getopt_initialize (argc, argv, optstring);
+ __getopt_initialized = 1;
+ }
+
+ /* Test whether ARGV[optind] points to a non-option argument.
+ Either it does not have option syntax, or there is an environment flag
+ from the shell indicating it is not an option. The later information
+ is only used when the used in the GNU libc. */
+#if defined _LIBC && defined USE_NONOPTION_FLAGS
+# define NONOPTION_P (argv[optind][0] != '-' || argv[optind][1] == '\0' \
+ || (optind < nonoption_flags_len \
+ && __getopt_nonoption_flags[optind] == '1'))
+#else
+# define NONOPTION_P (argv[optind][0] != '-' || argv[optind][1] == '\0')
+#endif
+
+ if (nextchar == NULL || *nextchar == '\0')
+ {
+ /* Advance to the next ARGV-element. */
+
+ /* Give FIRST_NONOPT & LAST_NONOPT rational values if OPTIND has been
+ moved back by the user (who may also have changed the arguments). */
+ if (last_nonopt > optind)
+ last_nonopt = optind;
+ if (first_nonopt > optind)
+ first_nonopt = optind;
+
+ if (ordering == PERMUTE)
+ {
+ /* If we have just processed some options following some non-options,
+ exchange them so that the options come first. */
+
+ if (first_nonopt != last_nonopt && last_nonopt != optind)
+ exchange ((char **) argv);
+ else if (last_nonopt != optind)
+ first_nonopt = optind;
+
+ /* Skip any additional non-options
+ and extend the range of non-options previously skipped. */
+
+ while (optind < argc && NONOPTION_P)
+ optind++;
+ last_nonopt = optind;
+ }
+
+ /* The special ARGV-element `--' means premature end of options.
+ Skip it like a null option,
+ then exchange with previous non-options as if it were an option,
+ then skip everything else like a non-option. */
+
+ if (optind != argc && !strcmp (argv[optind], "--"))
+ {
+ optind++;
+
+ if (first_nonopt != last_nonopt && last_nonopt != optind)
+ exchange ((char **) argv);
+ else if (first_nonopt == last_nonopt)
+ first_nonopt = optind;
+ last_nonopt = argc;
+
+ optind = argc;
+ }
+
+ /* If we have done all the ARGV-elements, stop the scan
+ and back over any non-options that we skipped and permuted. */
+
+ if (optind == argc)
+ {
+ /* Set the next-arg-index to point at the non-options
+ that we previously skipped, so the caller will digest them. */
+ if (first_nonopt != last_nonopt)
+ optind = first_nonopt;
+ return -1;
+ }
+
+ /* If we have come to a non-option and did not permute it,
+ either stop the scan or describe it to the caller and pass it by. */
+
+ if (NONOPTION_P)
+ {
+ if (ordering == REQUIRE_ORDER)
+ return -1;
+ optarg = argv[optind++];
+ return 1;
+ }
+
+ /* We have found another option-ARGV-element.
+ Skip the initial punctuation. */
+
+ nextchar = (argv[optind] + 1
+ + (longopts != NULL && argv[optind][1] == '-'));
+ }
+
+ /* Decode the current option-ARGV-element. */
+
+ /* Check whether the ARGV-element is a long option.
+
+ If long_only and the ARGV-element has the form "-f", where f is
+ a valid short option, don't consider it an abbreviated form of
+ a long option that starts with f. Otherwise there would be no
+ way to give the -f short option.
+
+ On the other hand, if there's a long option "fubar" and
+ the ARGV-element is "-fu", do consider that an abbreviation of
+ the long option, just like "--fu", and not "-f" with arg "u".
+
+ This distinction seems to be the most useful approach. */
+
+ if (longopts != NULL
+ && (argv[optind][1] == '-'
+ || (long_only && (argv[optind][2] || !my_index (optstring, argv[optind][1])))))
+ {
+ char *nameend;
+ const struct option *p;
+ const struct option *pfound = NULL;
+ int exact = 0;
+ int ambig = 0;
+ int indfound = -1;
+ int option_index;
+
+ for (nameend = nextchar; *nameend && *nameend != '='; nameend++)
+ /* Do nothing. */ ;
+
+ /* Test all long options for either exact match
+ or abbreviated matches. */
+ for (p = longopts, option_index = 0; p->name; p++, option_index++)
+ if (!strncmp (p->name, nextchar, nameend - nextchar))
+ {
+ if ((unsigned int) (nameend - nextchar)
+ == (unsigned int) strlen (p->name))
+ {
+ /* Exact match found. */
+ pfound = p;
+ indfound = option_index;
+ exact = 1;
+ break;
+ }
+ else if (pfound == NULL)
+ {
+ /* First nonexact match found. */
+ pfound = p;
+ indfound = option_index;
+ }
+ else if (long_only
+ || pfound->has_arg != p->has_arg
+ || pfound->flag != p->flag
+ || pfound->val != p->val)
+ /* Second or later nonexact match found. */
+ ambig = 1;
+ }
+
+ if (ambig && !exact)
+ {
+ if (print_errors)
+ fprintf (stderr, _("%s: option `%s' is ambiguous\n"),
+ argv[0], argv[optind]);
+ nextchar += strlen (nextchar);
+ optind++;
+ optopt = 0;
+ return '?';
+ }
+
+ if (pfound != NULL)
+ {
+ option_index = indfound;
+ optind++;
+ if (*nameend)
+ {
+ /* Don't test has_arg with >, because some C compilers don't
+ allow it to be used on enums. */
+ if (pfound->has_arg)
+ optarg = nameend + 1;
+ else
+ {
+ if (print_errors)
+ {
+ if (argv[optind - 1][1] == '-')
+ /* --option */
+ fprintf (stderr,
+ _("%s: option `--%s' doesn't allow an argument\n"),
+ argv[0], pfound->name);
+ else
+ /* +option or -option */
+ fprintf (stderr,
+ _("%s: option `%c%s' doesn't allow an argument\n"),
+ argv[0], argv[optind - 1][0], pfound->name);
+ }
+
+ nextchar += strlen (nextchar);
+
+ optopt = pfound->val;
+ return '?';
+ }
+ }
+ else if (pfound->has_arg == 1)
+ {
+ if (optind < argc)
+ optarg = argv[optind++];
+ else
+ {
+ if (print_errors)
+ fprintf (stderr,
+ _("%s: option `%s' requires an argument\n"),
+ argv[0], argv[optind - 1]);
+ nextchar += strlen (nextchar);
+ optopt = pfound->val;
+ return optstring[0] == ':' ? ':' : '?';
+ }
+ }
+ nextchar += strlen (nextchar);
+ if (longind != NULL)
+ *longind = option_index;
+ if (pfound->flag)
+ {
+ *(pfound->flag) = pfound->val;
+ return 0;
+ }
+ return pfound->val;
+ }
+
+ /* Can't find it as a long option. If this is not getopt_long_only,
+ or the option starts with '--' or is not a valid short
+ option, then it's an error.
+ Otherwise interpret it as a short option. */
+ if (!long_only || argv[optind][1] == '-'
+ || my_index (optstring, *nextchar) == NULL)
+ {
+ if (print_errors)
+ {
+ if (argv[optind][1] == '-')
+ /* --option */
+ fprintf (stderr, _("%s: unrecognized option `--%s'\n"),
+ argv[0], nextchar);
+ else
+ /* +option or -option */
+ fprintf (stderr, _("%s: unrecognized option `%c%s'\n"),
+ argv[0], argv[optind][0], nextchar);
+ }
+ nextchar = (char *) "";
+ optind++;
+ optopt = 0;
+ return '?';
+ }
+ }
+
+ /* Look at and handle the next short option-character. */
+
+ {
+ char c = *nextchar++;
+ char *temp = my_index (optstring, c);
+
+ /* Increment `optind' when we start to process its last character. */
+ if (*nextchar == '\0')
+ ++optind;
+
+ if (temp == NULL || c == ':')
+ {
+ if (print_errors)
+ {
+ if (posixly_correct)
+ /* 1003.2 specifies the format of this message. */
+ fprintf (stderr, _("%s: illegal option -- %c\n"),
+ argv[0], c);
+ else
+ fprintf (stderr, _("%s: invalid option -- %c\n"),
+ argv[0], c);
+ }
+ optopt = c;
+ return '?';
+ }
+ /* Convenience. Treat POSIX -W foo same as long option --foo */
+ if (temp[0] == 'W' && temp[1] == ';')
+ {
+ char *nameend;
+ const struct option *p;
+ const struct option *pfound = NULL;
+ int exact = 0;
+ int ambig = 0;
+ int indfound = 0;
+ int option_index;
+
+ /* This is an option that requires an argument. */
+ if (*nextchar != '\0')
+ {
+ optarg = nextchar;
+ /* If we end this ARGV-element by taking the rest as an arg,
+ we must advance to the next element now. */
+ optind++;
+ }
+ else if (optind == argc)
+ {
+ if (print_errors)
+ {
+ /* 1003.2 specifies the format of this message. */
+ fprintf (stderr, _("%s: option requires an argument -- %c\n"),
+ argv[0], c);
+ }
+ optopt = c;
+ if (optstring[0] == ':')
+ c = ':';
+ else
+ c = '?';
+ return c;
+ }
+ else
+ /* We already incremented `optind' once;
+ increment it again when taking next ARGV-elt as argument. */
+ optarg = argv[optind++];
+
+ /* optarg is now the argument, see if it's in the
+ table of longopts. */
+
+ for (nextchar = nameend = optarg; *nameend && *nameend != '='; nameend++)
+ /* Do nothing. */ ;
+
+ /* Test all long options for either exact match
+ or abbreviated matches. */
+ for (p = longopts, option_index = 0; p->name; p++, option_index++)
+ if (!strncmp (p->name, nextchar, nameend - nextchar))
+ {
+ if ((unsigned int) (nameend - nextchar) == strlen (p->name))
+ {
+ /* Exact match found. */
+ pfound = p;
+ indfound = option_index;
+ exact = 1;
+ break;
+ }
+ else if (pfound == NULL)
+ {
+ /* First nonexact match found. */
+ pfound = p;
+ indfound = option_index;
+ }
+ else
+ /* Second or later nonexact match found. */
+ ambig = 1;
+ }
+ if (ambig && !exact)
+ {
+ if (print_errors)
+ fprintf (stderr, _("%s: option `-W %s' is ambiguous\n"),
+ argv[0], argv[optind]);
+ nextchar += strlen (nextchar);
+ optind++;
+ return '?';
+ }
+ if (pfound != NULL)
+ {
+ option_index = indfound;
+ if (*nameend)
+ {
+ /* Don't test has_arg with >, because some C compilers don't
+ allow it to be used on enums. */
+ if (pfound->has_arg)
+ optarg = nameend + 1;
+ else
+ {
+ if (print_errors)
+ fprintf (stderr, _("\
+%s: option `-W %s' doesn't allow an argument\n"),
+ argv[0], pfound->name);
+
+ nextchar += strlen (nextchar);
+ return '?';
+ }
+ }
+ else if (pfound->has_arg == 1)
+ {
+ if (optind < argc)
+ optarg = argv[optind++];
+ else
+ {
+ if (print_errors)
+ fprintf (stderr,
+ _("%s: option `%s' requires an argument\n"),
+ argv[0], argv[optind - 1]);
+ nextchar += strlen (nextchar);
+ return optstring[0] == ':' ? ':' : '?';
+ }
+ }
+ nextchar += strlen (nextchar);
+ if (longind != NULL)
+ *longind = option_index;
+ if (pfound->flag)
+ {
+ *(pfound->flag) = pfound->val;
+ return 0;
+ }
+ return pfound->val;
+ }
+ nextchar = NULL;
+ return 'W'; /* Let the application handle it. */
+ }
+ if (temp[1] == ':')
+ {
+ if (temp[2] == ':')
+ {
+ /* This is an option that accepts an argument optionally. */
+ if (*nextchar != '\0')
+ {
+ optarg = nextchar;
+ optind++;
+ }
+ else
+ optarg = NULL;
+ nextchar = NULL;
+ }
+ else
+ {
+ /* This is an option that requires an argument. */
+ if (*nextchar != '\0')
+ {
+ optarg = nextchar;
+ /* If we end this ARGV-element by taking the rest as an arg,
+ we must advance to the next element now. */
+ optind++;
+ }
+ else if (optind == argc)
+ {
+ if (print_errors)
+ {
+ /* 1003.2 specifies the format of this message. */
+ fprintf (stderr,
+ _("%s: option requires an argument -- %c\n"),
+ argv[0], c);
+ }
+ optopt = c;
+ if (optstring[0] == ':')
+ c = ':';
+ else
+ c = '?';
+ }
+ else
+ /* We already incremented `optind' once;
+ increment it again when taking next ARGV-elt as argument. */
+ optarg = argv[optind++];
+ nextchar = NULL;
+ }
+ }
+ return c;
+ }
+}
+
+int
+getopt (argc, argv, optstring)
+ int argc;
+ char *const *argv;
+ const char *optstring;
+{
+ return _getopt_internal (argc, argv, optstring,
+ (const struct option *) 0,
+ (int *) 0,
+ 0);
+}
+
+#endif /* Not ELIDE_CODE. */
+
+#ifdef TEST
+
+/* Compile with -DTEST to make an executable for use in testing
+ the above definition of `getopt'. */
+
+int
+main (argc, argv)
+ int argc;
+ char **argv;
+{
+ int c;
+ int digit_optind = 0;
+
+ while (1)
+ {
+ int this_option_optind = optind ? optind : 1;
+
+ c = getopt (argc, argv, "abc:d:0123456789");
+ if (c == -1)
+ break;
+
+ switch (c)
+ {
+ case '0':
+ case '1':
+ case '2':
+ case '3':
+ case '4':
+ case '5':
+ case '6':
+ case '7':
+ case '8':
+ case '9':
+ if (digit_optind != 0 && digit_optind != this_option_optind)
+ printf ("digits occur in two different argv-elements.\n");
+ digit_optind = this_option_optind;
+ printf ("option %c\n", c);
+ break;
+
+ case 'a':
+ printf ("option a\n");
+ break;
+
+ case 'b':
+ printf ("option b\n");
+ break;
+
+ case 'c':
+ printf ("option c with value `%s'\n", optarg);
+ break;
+
+ case '?':
+ break;
+
+ default:
+ printf ("?? getopt returned character code 0%o ??\n", c);
+ }
+ }
+
+ if (optind < argc)
+ {
+ printf ("non-option ARGV-elements: ");
+ while (optind < argc)
+ printf ("%s ", argv[optind++]);
+ printf ("\n");
+ }
+
+ exit (0);
+}
+
+#endif /* TEST */
diff --git a/libs/libtheora-1.1/examples/getopt.h b/libs/libtheora-1.1/examples/getopt.h
new file mode 100644
index 00000000..74d0d2b6
--- /dev/null
+++ b/libs/libtheora-1.1/examples/getopt.h
@@ -0,0 +1,180 @@
+/* Declarations for getopt.
+ Copyright (C) 1989-1994, 1996-1999, 2001 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, write to the Free
+ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+ 02111-1307 USA. */
+
+#ifndef _GETOPT_H
+
+#ifndef __need_getopt
+# define _GETOPT_H 1
+#endif
+
+/* If __GNU_LIBRARY__ is not already defined, either we are being used
+ standalone, or this is the first header included in the source file.
+ If we are being used with glibc, we need to include , but
+ that does not exist if we are standalone. So: if __GNU_LIBRARY__ is
+ not defined, include , which will pull in for us
+ if it's from glibc. (Why ctype.h? It's guaranteed to exist and it
+ doesn't flood the namespace with stuff the way some other headers do.) */
+#if !defined __GNU_LIBRARY__
+# include
+#endif
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* For communication from `getopt' to the caller.
+ When `getopt' finds an option that takes an argument,
+ the argument value is returned here.
+ Also, when `ordering' is RETURN_IN_ORDER,
+ each non-option ARGV-element is returned here. */
+
+extern char *optarg;
+
+/* Index in ARGV of the next element to be scanned.
+ This is used for communication to and from the caller
+ and for communication between successive calls to `getopt'.
+
+ On entry to `getopt', zero means this is the first call; initialize.
+
+ When `getopt' returns -1, this is the index of the first of the
+ non-option elements that the caller should itself scan.
+
+ Otherwise, `optind' communicates from one call to the next
+ how much of ARGV has been scanned so far. */
+
+extern int optind;
+
+/* Callers store zero here to inhibit the error message `getopt' prints
+ for unrecognized options. */
+
+extern int opterr;
+
+/* Set to an option character which was unrecognized. */
+
+extern int optopt;
+
+#ifndef __need_getopt
+/* Describe the long-named options requested by the application.
+ The LONG_OPTIONS argument to getopt_long or getopt_long_only is a vector
+ of `struct option' terminated by an element containing a name which is
+ zero.
+
+ The field `has_arg' is:
+ no_argument (or 0) if the option does not take an argument,
+ required_argument (or 1) if the option requires an argument,
+ optional_argument (or 2) if the option takes an optional argument.
+
+ If the field `flag' is not NULL, it points to a variable that is set
+ to the value given in the field `val' when the option is found, but
+ left unchanged if the option is not found.
+
+ To have a long-named option do something other than set an `int' to
+ a compiled-in constant, such as set a value from `optarg', set the
+ option's `flag' field to zero and its `val' field to a nonzero
+ value (the equivalent single-letter option character, if there is
+ one). For long options that have a zero `flag' field, `getopt'
+ returns the contents of the `val' field. */
+
+struct option
+{
+# if (defined __STDC__ && __STDC__) || defined __cplusplus
+ const char *name;
+# else
+ char *name;
+# endif
+ /* has_arg can't be an enum because some compilers complain about
+ type mismatches in all the code that assumes it is an int. */
+ int has_arg;
+ int *flag;
+ int val;
+};
+
+/* Names for the values of the `has_arg' field of `struct option'. */
+
+# define no_argument 0
+# define required_argument 1
+# define optional_argument 2
+#endif /* need getopt */
+
+
+/* Get definitions and prototypes for functions to process the
+ arguments in ARGV (ARGC of them, minus the program name) for
+ options given in OPTS.
+
+ Return the option character from OPTS just read. Return -1 when
+ there are no more options. For unrecognized options, or options
+ missing arguments, `optopt' is set to the option letter, and '?' is
+ returned.
+
+ The OPTS string is a list of characters which are recognized option
+ letters, optionally followed by colons, specifying that that letter
+ takes an argument, to be placed in `optarg'.
+
+ If a letter in OPTS is followed by two colons, its argument is
+ optional. This behavior is specific to the GNU `getopt'.
+
+ The argument `--' causes premature termination of argument
+ scanning, explicitly telling `getopt' that there are no more
+ options.
+
+ If OPTS begins with `--', then non-option arguments are treated as
+ arguments to the option '\0'. This behavior is specific to the GNU
+ `getopt'. */
+
+#if (defined __STDC__ && __STDC__) || defined __cplusplus
+# ifdef __GNU_LIBRARY__
+/* Many other libraries have conflicting prototypes for getopt, with
+ differences in the consts, in stdlib.h. To avoid compilation
+ errors, only prototype getopt for the GNU C library. */
+extern int getopt (int __argc, char *const *__argv, const char *__shortopts);
+# else /* not __GNU_LIBRARY__ */
+extern int getopt ();
+# endif /* __GNU_LIBRARY__ */
+
+# ifndef __need_getopt
+extern int getopt_long (int __argc, char *const *__argv, const char *__shortopts,
+ const struct option *__longopts, int *__longind);
+extern int getopt_long_only (int __argc, char *const *__argv,
+ const char *__shortopts,
+ const struct option *__longopts, int *__longind);
+
+/* Internal only. Users should not call this directly. */
+extern int _getopt_internal (int __argc, char *const *__argv,
+ const char *__shortopts,
+ const struct option *__longopts, int *__longind,
+ int __long_only);
+# endif
+#else /* not __STDC__ */
+extern int getopt ();
+# ifndef __need_getopt
+extern int getopt_long ();
+extern int getopt_long_only ();
+
+extern int _getopt_internal ();
+# endif
+#endif /* __STDC__ */
+
+#ifdef __cplusplus
+}
+#endif
+
+/* Make sure we later can get all the definitions and declarations. */
+#undef __need_getopt
+
+#endif /* getopt.h */
diff --git a/libs/libtheora-1.1/examples/getopt1.c b/libs/libtheora-1.1/examples/getopt1.c
new file mode 100644
index 00000000..15448919
--- /dev/null
+++ b/libs/libtheora-1.1/examples/getopt1.c
@@ -0,0 +1,188 @@
+/* getopt_long and getopt_long_only entry points for GNU getopt.
+ Copyright (C) 1987,88,89,90,91,92,93,94,96,97,98
+ Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, write to the Free
+ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+ 02111-1307 USA. */
+
+#ifdef HAVE_CONFIG_H
+#include
+#endif
+
+#include "getopt.h"
+
+#if !defined __STDC__ || !__STDC__
+/* This is a separate conditional since some stdc systems
+ reject `defined (const)'. */
+#ifndef const
+#define const
+#endif
+#endif
+
+#include
+
+/* Comment out all this code if we are using the GNU C Library, and are not
+ actually compiling the library itself. This code is part of the GNU C
+ Library, but also included in many other GNU distributions. Compiling
+ and linking in this code is a waste when using the GNU C library
+ (especially if it is a shared library). Rather than having every GNU
+ program understand `configure --with-gnu-libc' and omit the object files,
+ it is simpler to just do this in the source for each such file. */
+
+#define GETOPT_INTERFACE_VERSION 2
+#if !defined _LIBC && defined __GLIBC__ && __GLIBC__ >= 2
+#include
+#if _GNU_GETOPT_INTERFACE_VERSION == GETOPT_INTERFACE_VERSION
+#define ELIDE_CODE
+#endif
+#endif
+
+#ifndef ELIDE_CODE
+
+
+/* This needs to come after some library #include
+ to get __GNU_LIBRARY__ defined. */
+#ifdef __GNU_LIBRARY__
+#include
+#endif
+
+#ifndef NULL
+#define NULL 0
+#endif
+
+int
+getopt_long (argc, argv, options, long_options, opt_index)
+ int argc;
+ char *const *argv;
+ const char *options;
+ const struct option *long_options;
+ int *opt_index;
+{
+ return _getopt_internal (argc, argv, options, long_options, opt_index, 0);
+}
+
+/* Like getopt_long, but '-' as well as '--' can indicate a long option.
+ If an option that starts with '-' (not '--') doesn't match a long option,
+ but does match a short option, it is parsed as a short option
+ instead. */
+
+int
+getopt_long_only (argc, argv, options, long_options, opt_index)
+ int argc;
+ char *const *argv;
+ const char *options;
+ const struct option *long_options;
+ int *opt_index;
+{
+ return _getopt_internal (argc, argv, options, long_options, opt_index, 1);
+}
+
+
+#endif /* Not ELIDE_CODE. */
+
+#ifdef TEST
+
+#include
+
+int
+main (argc, argv)
+ int argc;
+ char **argv;
+{
+ int c;
+ int digit_optind = 0;
+
+ while (1)
+ {
+ int this_option_optind = optind ? optind : 1;
+ int option_index = 0;
+ static struct option long_options[] =
+ {
+ {"add", 1, 0, 0},
+ {"append", 0, 0, 0},
+ {"delete", 1, 0, 0},
+ {"verbose", 0, 0, 0},
+ {"create", 0, 0, 0},
+ {"file", 1, 0, 0},
+ {0, 0, 0, 0}
+ };
+
+ c = getopt_long (argc, argv, "abc:d:0123456789",
+ long_options, &option_index);
+ if (c == -1)
+ break;
+
+ switch (c)
+ {
+ case 0:
+ printf ("option %s", long_options[option_index].name);
+ if (optarg)
+ printf (" with arg %s", optarg);
+ printf ("\n");
+ break;
+
+ case '0':
+ case '1':
+ case '2':
+ case '3':
+ case '4':
+ case '5':
+ case '6':
+ case '7':
+ case '8':
+ case '9':
+ if (digit_optind != 0 && digit_optind != this_option_optind)
+ printf ("digits occur in two different argv-elements.\n");
+ digit_optind = this_option_optind;
+ printf ("option %c\n", c);
+ break;
+
+ case 'a':
+ printf ("option a\n");
+ break;
+
+ case 'b':
+ printf ("option b\n");
+ break;
+
+ case 'c':
+ printf ("option c with value `%s'\n", optarg);
+ break;
+
+ case 'd':
+ printf ("option d with value `%s'\n", optarg);
+ break;
+
+ case '?':
+ break;
+
+ default:
+ printf ("?? getopt returned character code 0%o ??\n", c);
+ }
+ }
+
+ if (optind < argc)
+ {
+ printf ("non-option ARGV-elements: ");
+ while (optind < argc)
+ printf ("%s ", argv[optind++]);
+ printf ("\n");
+ }
+
+ exit (0);
+}
+
+#endif /* TEST */
diff --git a/libs/libtheora-1.1/examples/player_example.c b/libs/libtheora-1.1/examples/player_example.c
new file mode 100644
index 00000000..60a81435
--- /dev/null
+++ b/libs/libtheora-1.1/examples/player_example.c
@@ -0,0 +1,887 @@
+/********************************************************************
+ * *
+ * THIS FILE IS PART OF THE OggTheora SOFTWARE CODEC SOURCE CODE. *
+ * USE, DISTRIBUTION AND REPRODUCTION OF THIS LIBRARY SOURCE IS *
+ * GOVERNED BY A BSD-STYLE SOURCE LICENSE INCLUDED WITH THIS SOURCE *
+ * IN 'COPYING'. PLEASE READ THESE TERMS BEFORE DISTRIBUTING. *
+ * *
+ * THE Theora SOURCE CODE IS COPYRIGHT (C) 2002-2009 *
+ * by the Xiph.Org Foundation and contributors http://www.xiph.org/ *
+ * *
+ ********************************************************************
+
+ function: example SDL player application; plays Ogg Theora files (with
+ optional Vorbis audio second stream)
+ last mod: $Id: player_example.c 17974 2011-05-07 22:31:49Z giles $
+
+ ********************************************************************/
+
+/* far more complex than most Ogg 'example' programs. The complexity
+ of maintaining A/V sync is pretty much unavoidable. It's necessary
+ to actually have audio/video playback to make the hard audio clock
+ sync actually work. If there's audio playback, there might as well
+ be simple video playback as well...
+
+ A simple 'demux and write back streams' would have been easier,
+ it's true. */
+
+#if !defined(_GNU_SOURCE)
+#define _GNU_SOURCE
+#endif
+#if !defined(_LARGEFILE_SOURCE)
+#define _LARGEFILE_SOURCE
+#endif
+#if !defined(_LARGEFILE64_SOURCE)
+#define _LARGEFILE64_SOURCE
+#endif
+#if !defined(_FILE_OFFSET_BITS)
+#define _FILE_OFFSET_BITS 64
+#endif
+
+#ifdef HAVE_CONFIG_H
+# include
+#endif
+
+#ifndef _REENTRANT
+# define _REENTRANT
+#endif
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "theora/theoradec.h"
+#include "vorbis/codec.h"
+#include
+
+/* yes, this makes us OSS-specific for now. None of SDL, libao, libao2
+ give us any way to determine hardware timing, and since the
+ hard/kernel buffer is going to be most of or > a second, that's
+ just a little bit important */
+#if defined(__FreeBSD__)
+#include
+#define AUDIO_DEVICE "/dev/audio"
+#elif defined(__NetBSD__) || defined(__OpenBSD__)
+#include
+#define AUDIO_DEVICE "/dev/audio"
+#else
+#include
+#define AUDIO_DEVICE "/dev/dsp"
+#endif
+#include
+
+/* Helper; just grab some more compressed bitstream and sync it for
+ page extraction */
+int buffer_data(FILE *in,ogg_sync_state *oy){
+ char *buffer=ogg_sync_buffer(oy,4096);
+ int bytes=fread(buffer,1,4096,in);
+ ogg_sync_wrote(oy,bytes);
+ return(bytes);
+}
+
+/* never forget that globals are a one-way ticket to Hell */
+/* Ogg and codec state for demux/decode */
+ogg_sync_state oy;
+ogg_page og;
+ogg_stream_state vo;
+ogg_stream_state to;
+th_info ti;
+th_comment tc;
+th_dec_ctx *td;
+th_setup_info *ts;
+vorbis_info vi;
+vorbis_dsp_state vd;
+vorbis_block vb;
+vorbis_comment vc;
+th_pixel_fmt px_fmt;
+
+int theora_p=0;
+int vorbis_p=0;
+int stateflag=0;
+
+/* SDL Video playback structures */
+SDL_Surface *screen;
+SDL_Overlay *yuv_overlay;
+SDL_Rect rect;
+unsigned char *RGBbuffer;
+
+#define OC_CLAMP255(_x) ((unsigned char)((((_x)<0)-1)&((_x)|-((_x)>255))))
+
+/* single frame video buffering */
+int videobuf_ready=0;
+ogg_int64_t videobuf_granulepos=-1;
+double videobuf_time=0;
+
+/* single audio fragment audio buffering */
+int audiobuf_fill=0;
+int audiobuf_ready=0;
+ogg_int16_t *audiobuf;
+ogg_int64_t audiobuf_granulepos=0; /* time position of last sample */
+
+/* audio / video synchronization tracking:
+
+Since this will make it to Google at some point and lots of people
+search for how to do this, a quick rundown of a practical A/V sync
+strategy under Linux [the UNIX where Everything Is Hard]. Naturally,
+this works on other platforms using OSS for sound as well.
+
+In OSS, we don't have reliable access to any precise information on
+the exact current playback position (that, of course would have been
+too easy; the kernel folks like to keep us app people working hard
+doing simple things that should have been solved once and abstracted
+long ago). Hopefully ALSA solves this a little better; we'll probably
+use that once ALSA is the standard in the stable kernel.
+
+We can't use the system clock for a/v sync because audio is hard
+synced to its own clock, and both the system and audio clocks suffer
+from wobble, drift, and a lack of accuracy that can be guaranteed to
+add a reliable percent or so of error. After ten seconds, that's
+100ms. We can't drift by half a second every minute.
+
+Although OSS can't generally tell us where the audio playback pointer
+is, we do know that if we work in complete audio fragments and keep
+the kernel buffer full, a blocking select on the audio buffer will
+give us a writable fragment immediately after playback finishes with
+it. We assume at that point that we know the exact number of bytes in
+the kernel buffer that have not been played (total fragments minus
+one) and calculate clock drift between audio and system then (and only
+then). Damp the sync correction fraction, apply, and walla: A
+reliable A/V clock that even works if it's interrupted. */
+
+long audiofd_totalsize=-1;
+int audiofd_fragsize; /* read and write only complete fragments
+ so that SNDCTL_DSP_GETOSPACE is
+ accurate immediately after a bank
+ switch */
+int audiofd=-1;
+ogg_int64_t audiofd_timer_calibrate=-1;
+
+
+static void open_audio(){
+ audio_buf_info info;
+ int format=AFMT_S16_NE; /* host endian */
+ int channels=vi.channels;
+ int rate=vi.rate;
+ int ret;
+
+ audiofd=open(AUDIO_DEVICE,O_RDWR);
+ if(audiofd<0){
+ fprintf(stderr,"Could not open audio device " AUDIO_DEVICE ".\n");
+ exit(1);
+ }
+
+ ret=ioctl(audiofd,SNDCTL_DSP_SETFMT,&format);
+ if(ret){
+ fprintf(stderr,"Could not set 16 bit host-endian playback\n");
+ exit(1);
+ }
+
+ ret=ioctl(audiofd,SNDCTL_DSP_CHANNELS,&channels);
+ if(ret){
+ fprintf(stderr,"Could not set %d channel playback\n",channels);
+ exit(1);
+ }
+
+ ret=ioctl(audiofd,SNDCTL_DSP_SPEED,&rate);
+ if(ret){
+ fprintf(stderr,"Could not set %d Hz playback\n",rate);
+ exit(1);
+ }
+
+ ioctl(audiofd,SNDCTL_DSP_GETOSPACE,&info);
+ audiofd_fragsize=info.fragsize;
+ audiofd_totalsize=info.fragstotal*info.fragsize;
+
+ audiobuf=malloc(audiofd_fragsize);
+}
+
+static void audio_close(void){
+ if(audiofd>-1){
+ ioctl(audiofd,SNDCTL_DSP_RESET,NULL);
+ close(audiofd);
+ free(audiobuf);
+ }
+}
+
+/* call this only immediately after unblocking from a full kernel
+ having a newly empty fragment or at the point of DMA restart */
+void audio_calibrate_timer(int restart){
+ struct timeval tv;
+ ogg_int64_t current_sample;
+ ogg_int64_t new_time;
+
+ gettimeofday(&tv,0);
+ new_time=tv.tv_sec*1000+tv.tv_usec/1000;
+
+ if(restart){
+ current_sample=audiobuf_granulepos-audiobuf_fill/2/vi.channels;
+ }else
+ current_sample=audiobuf_granulepos-
+ (audiobuf_fill+audiofd_totalsize-audiofd_fragsize)/2/vi.channels;
+
+ new_time-=1000*current_sample/vi.rate;
+
+ audiofd_timer_calibrate=new_time;
+}
+
+/* get relative time since beginning playback, compensating for A/V
+ drift */
+double get_time(){
+ static ogg_int64_t last=0;
+ static ogg_int64_t up=0;
+ ogg_int64_t now;
+ struct timeval tv;
+
+ gettimeofday(&tv,0);
+ now=tv.tv_sec*1000+tv.tv_usec/1000;
+
+ if(audiofd_timer_calibrate==-1)audiofd_timer_calibrate=last=now;
+
+ if(audiofd<0){
+ /* no audio timer to worry about, we can just use the system clock */
+ /* only one complication: If the process is suspended, we should
+ reset timing to account for the gap in play time. Do it the
+ easy/hack way */
+ if(now-last>1000)audiofd_timer_calibrate+=(now-last);
+ last=now;
+ }
+
+ if(now-up>200){
+ double timebase=(now-audiofd_timer_calibrate)*.001;
+ int hundredths=timebase*100-(long)timebase*100;
+ int seconds=(long)timebase%60;
+ int minutes=((long)timebase/60)%60;
+ int hours=(long)timebase/3600;
+
+ fprintf(stderr," Playing: %d:%02d:%02d.%02d \r",
+ hours,minutes,seconds,hundredths);
+ up=now;
+ }
+
+ return (now-audiofd_timer_calibrate)*.001;
+
+}
+
+/* write a fragment to the OSS kernel audio API, but only if we can
+ stuff in a whole fragment without blocking */
+void audio_write_nonblocking(void){
+
+ if(audiobuf_ready){
+ audio_buf_info info;
+ long bytes;
+
+ ioctl(audiofd,SNDCTL_DSP_GETOSPACE,&info);
+ bytes=info.bytes;
+ if(bytes>=audiofd_fragsize){
+ if(bytes==audiofd_totalsize)audio_calibrate_timer(1);
+
+ while(1){
+ bytes=write(audiofd,audiobuf+(audiofd_fragsize-audiobuf_fill),
+ audiofd_fragsize);
+
+ if(bytes>0){
+
+ if(bytes!=audiobuf_fill){
+ /* shouldn't actually be possible... but eh */
+ audiobuf_fill-=bytes;
+ }else
+ break;
+ }
+ }
+
+ audiobuf_fill=0;
+ audiobuf_ready=0;
+
+ }
+ }
+}
+
+/* clean quit on Ctrl-C for SDL and thread shutdown as per SDL example
+ (we don't use any threads, but libSDL does) */
+int got_sigint=0;
+static void sigint_handler (int signal) {
+ got_sigint = 1;
+}
+
+static void open_video(void){
+ int w;
+ int h;
+ w=(ti.pic_x+ti.pic_width+1&~1)-(ti.pic_x&~1);
+ h=(ti.pic_y+ti.pic_height+1&~1)-(ti.pic_y&~1);
+ if ( SDL_Init(SDL_INIT_VIDEO) < 0 ) {
+ fprintf(stderr, "Unable to init SDL: %s\n", SDL_GetError());
+ exit(1);
+ }
+
+ screen = SDL_SetVideoMode(w, h, 0, SDL_SWSURFACE);
+ if ( screen == NULL ) {
+ fprintf(stderr, "Unable to set %dx%d video: %s\n",
+ w,h,SDL_GetError());
+ exit(1);
+ }
+
+ if (px_fmt==TH_PF_422)
+ yuv_overlay = SDL_CreateYUVOverlay(w, h,
+ SDL_YUY2_OVERLAY,
+ screen);
+ else if (px_fmt==TH_PF_444) {
+ RGBbuffer = calloc(sizeof(char),w*h*4);
+ fprintf(stderr,"warning: SDL does not support YUV 4:4:4, using slow software conversion.\n");
+ } else
+ yuv_overlay = SDL_CreateYUVOverlay(w, h,
+ SDL_YV12_OVERLAY,
+ screen);
+
+ if ( (yuv_overlay == NULL && px_fmt!=TH_PF_444) || (screen == NULL && px_fmt==TH_PF_444) ) {
+ fprintf(stderr, "SDL: xCouldn't create SDL_yuv_overlay: %s\n",
+ SDL_GetError());
+ exit(1);
+ }
+ rect.x = 0;
+ rect.y = 0;
+ rect.w = w;
+ rect.h = h;
+
+ if (px_fmt!=TH_PF_444)
+ SDL_DisplayYUVOverlay(yuv_overlay, &rect);
+}
+
+static void video_write(void){
+ int i;
+ th_ycbcr_buffer yuv;
+ int y_offset, uv_offset;
+ th_decode_ycbcr_out(td,yuv);
+ /* Lock SDL_yuv_overlay */
+ if ( SDL_MUSTLOCK(screen) ) {
+ if ( SDL_LockSurface(screen) < 0 ) return;
+ }
+ if (px_fmt!=TH_PF_444 && SDL_LockYUVOverlay(yuv_overlay) < 0) return;
+
+ /* let's draw the data on a SDL screen (*screen) */
+ /* deal with border stride */
+ /* reverse u and v for SDL */
+ /* and crop input properly, respecting the encoded frame rect */
+ /* problems may exist for odd frame rect for some encodings */
+
+ y_offset=(ti.pic_x&~1)+yuv[0].stride*(ti.pic_y&~1);
+
+ if (px_fmt==TH_PF_422) {
+ uv_offset=(ti.pic_x/2)+(yuv[1].stride)*(ti.pic_y);
+ /* SDL doesn't have a planar 4:2:2 */
+ for(i=0;ih;i++) {
+ int j;
+ char *in_y = (char *)yuv[0].data+y_offset+yuv[0].stride*i;
+ char *out = (char *)(yuv_overlay->pixels[0]+yuv_overlay->pitches[0]*i);
+ for (j=0;jw;j++)
+ out[j*2] = in_y[j];
+ char *in_u = (char *)yuv[1].data+uv_offset+yuv[1].stride*i;
+ char *in_v = (char *)yuv[2].data+uv_offset+yuv[2].stride*i;
+ for (j=0;jw>>1;j++) {
+ out[j*4+1] = in_u[j];
+ out[j*4+3] = in_v[j];
+ }
+ }
+ } else if (px_fmt==TH_PF_444){
+ SDL_Surface *output;
+ for(i=0;ih;i++) {
+ int j;
+ unsigned char *in_y = (unsigned char *)yuv[0].data+y_offset+yuv[0].stride*i;
+ unsigned char *in_u = (unsigned char *)yuv[1].data+y_offset+yuv[1].stride*i;
+ unsigned char *in_v = (unsigned char *)yuv[2].data+y_offset+yuv[2].stride*i;
+ unsigned char *out = RGBbuffer+(screen->w*i*4);
+ for (j=0;jw;j++) {
+ int r, g, b;
+ r=(1904000*in_y[j]+2609823*in_v[j]-363703744)/1635200;
+ g=(3827562*in_y[j]-1287801*in_u[j]
+ -2672387*in_v[j]+447306710)/3287200;
+ b=(952000*in_y[j]+1649289*in_u[j]-225932192)/817600;
+ out[4*j+0]=OC_CLAMP255(b);
+ out[4*j+1]=OC_CLAMP255(g);
+ out[4*j+2]=OC_CLAMP255(r);
+ }
+ output=SDL_CreateRGBSurfaceFrom(RGBbuffer,screen->w,screen->h,32,4*screen->w,0,0,0,0);
+ SDL_BlitSurface(output,NULL,screen,NULL);
+ }
+ } else {
+ uv_offset=(ti.pic_x/2)+(yuv[1].stride)*(ti.pic_y/2);
+ for(i=0;ih;i++)
+ memcpy(yuv_overlay->pixels[0]+yuv_overlay->pitches[0]*i,
+ yuv[0].data+y_offset+yuv[0].stride*i,
+ yuv_overlay->w);
+ for(i=0;ih/2;i++){
+ memcpy(yuv_overlay->pixels[1]+yuv_overlay->pitches[1]*i,
+ yuv[2].data+uv_offset+yuv[2].stride*i,
+ yuv_overlay->w/2);
+ memcpy(yuv_overlay->pixels[2]+yuv_overlay->pitches[2]*i,
+ yuv[1].data+uv_offset+yuv[1].stride*i,
+ yuv_overlay->w/2);
+ }
+ }
+
+ /* Unlock SDL_yuv_overlay */
+ if ( SDL_MUSTLOCK(screen) ) {
+ SDL_UnlockSurface(screen);
+ }
+ if (px_fmt!=TH_PF_444) {
+ SDL_UnlockYUVOverlay(yuv_overlay);
+ /* Show, baby, show! */
+ SDL_DisplayYUVOverlay(yuv_overlay, &rect);
+ } else {
+ SDL_Flip(screen);
+ }
+}
+/* dump the theora (or vorbis) comment header */
+static int dump_comments(th_comment *tc){
+ int i, len;
+ char *value;
+ FILE *out=stdout;
+
+ fprintf(out,"Encoded by %s\n",tc->vendor);
+ if(tc->comments){
+ fprintf(out, "theora comment header:\n");
+ for(i=0;icomments;i++){
+ if(tc->user_comments[i]){
+ len=tc->comment_lengths[i];
+ value=malloc(len+1);
+ memcpy(value,tc->user_comments[i],len);
+ value[len]='\0';
+ fprintf(out, "\t%s\n", value);
+ free(value);
+ }
+ }
+ }
+ return(0);
+}
+
+/* Report the encoder-specified colorspace for the video, if any.
+ We don't actually make use of the information in this example;
+ a real player should attempt to perform color correction for
+ whatever display device it supports. */
+static void report_colorspace(th_info *ti)
+{
+ switch(ti->colorspace){
+ case TH_CS_UNSPECIFIED:
+ /* nothing to report */
+ break;;
+ case TH_CS_ITU_REC_470M:
+ fprintf(stderr," encoder specified ITU Rec 470M (NTSC) color.\n");
+ break;;
+ case TH_CS_ITU_REC_470BG:
+ fprintf(stderr," encoder specified ITU Rec 470BG (PAL) color.\n");
+ break;;
+ default:
+ fprintf(stderr,"warning: encoder specified unknown colorspace (%d).\n",
+ ti->colorspace);
+ break;;
+ }
+}
+
+/* helper: push a page into the appropriate steam */
+/* this can be done blindly; a stream won't accept a page
+ that doesn't belong to it */
+static int queue_page(ogg_page *page){
+ if(theora_p)ogg_stream_pagein(&to,page);
+ if(vorbis_p)ogg_stream_pagein(&vo,page);
+ return 0;
+}
+
+static void usage(void){
+ fprintf(stderr,
+ "Usage: player_example \n"
+ "input is read from stdin if no file is passed on the command line\n"
+ "\n"
+ );
+}
+
+int main(int argc,char *const *argv){
+
+ int pp_level_max;
+ int pp_level;
+ int pp_inc;
+ int i,j;
+ ogg_packet op;
+
+ FILE *infile = stdin;
+
+ int frames = 0;
+ int dropped = 0;
+
+#ifdef _WIN32 /* We need to set stdin/stdout to binary mode. Damn windows. */
+ /* Beware the evil ifdef. We avoid these where we can, but this one we
+ cannot. Don't add any more, you'll probably go to hell if you do. */
+ _setmode( _fileno( stdin ), _O_BINARY );
+#endif
+
+ /* open the input file if any */
+ if(argc==2){
+ infile=fopen(argv[1],"rb");
+ if(infile==NULL){
+ fprintf(stderr,"Unable to open '%s' for playback.\n", argv[1]);
+ exit(1);
+ }
+ }
+ if(argc>2){
+ usage();
+ exit(1);
+ }
+
+ /* start up Ogg stream synchronization layer */
+ ogg_sync_init(&oy);
+
+ /* init supporting Vorbis structures needed in header parsing */
+ vorbis_info_init(&vi);
+ vorbis_comment_init(&vc);
+
+ /* init supporting Theora structures needed in header parsing */
+ th_comment_init(&tc);
+ th_info_init(&ti);
+
+ /* Ogg file open; parse the headers */
+ /* Only interested in Vorbis/Theora streams */
+ while(!stateflag){
+ int ret=buffer_data(infile,&oy);
+ if(ret==0)break;
+ while(ogg_sync_pageout(&oy,&og)>0){
+ ogg_stream_state test;
+
+ /* is this a mandated initial header? If not, stop parsing */
+ if(!ogg_page_bos(&og)){
+ /* don't leak the page; get it into the appropriate stream */
+ queue_page(&og);
+ stateflag=1;
+ break;
+ }
+
+ ogg_stream_init(&test,ogg_page_serialno(&og));
+ ogg_stream_pagein(&test,&og);
+ ogg_stream_packetout(&test,&op);
+
+
+ /* identify the codec: try theora */
+ if(!theora_p && th_decode_headerin(&ti,&tc,&ts,&op)>=0){
+ /* it is theora */
+ memcpy(&to,&test,sizeof(test));
+ theora_p=1;
+ }else if(!vorbis_p && vorbis_synthesis_headerin(&vi,&vc,&op)>=0){
+ /* it is vorbis */
+ memcpy(&vo,&test,sizeof(test));
+ vorbis_p=1;
+ }else{
+ /* whatever it is, we don't care about it */
+ ogg_stream_clear(&test);
+ }
+ }
+ /* fall through to non-bos page parsing */
+ }
+
+ /* we're expecting more header packets. */
+ while((theora_p && theora_p<3) || (vorbis_p && vorbis_p<3)){
+ int ret;
+
+ /* look for further theora headers */
+ while(theora_p && (theora_p<3) && (ret=ogg_stream_packetout(&to,&op))){
+ if(ret<0){
+ fprintf(stderr,"Error parsing Theora stream headers; "
+ "corrupt stream?\n");
+ exit(1);
+ }
+ if(!th_decode_headerin(&ti,&tc,&ts,&op)){
+ fprintf(stderr,"Error parsing Theora stream headers; "
+ "corrupt stream?\n");
+ exit(1);
+ }
+ theora_p++;
+ }
+
+ /* look for more vorbis header packets */
+ while(vorbis_p && (vorbis_p<3) && (ret=ogg_stream_packetout(&vo,&op))){
+ if(ret<0){
+ fprintf(stderr,"Error parsing Vorbis stream headers; corrupt stream?\n");
+ exit(1);
+ }
+ if(vorbis_synthesis_headerin(&vi,&vc,&op)){
+ fprintf(stderr,"Error parsing Vorbis stream headers; corrupt stream?\n");
+ exit(1);
+ }
+ vorbis_p++;
+ if(vorbis_p==3)break;
+ }
+
+ /* The header pages/packets will arrive before anything else we
+ care about, or the stream is not obeying spec */
+
+ if(ogg_sync_pageout(&oy,&og)>0){
+ queue_page(&og); /* demux into the appropriate stream */
+ }else{
+ int ret=buffer_data(infile,&oy); /* someone needs more data */
+ if(ret==0){
+ fprintf(stderr,"End of file while searching for codec headers.\n");
+ exit(1);
+ }
+ }
+ }
+
+ /* and now we have it all. initialize decoders */
+ if(theora_p){
+ td=th_decode_alloc(&ti,ts);
+ printf("Ogg logical stream %lx is Theora %dx%d %.02f fps",
+ to.serialno,ti.pic_width,ti.pic_height,
+ (double)ti.fps_numerator/ti.fps_denominator);
+ px_fmt=ti.pixel_fmt;
+ switch(ti.pixel_fmt){
+ case TH_PF_420: printf(" 4:2:0 video\n"); break;
+ case TH_PF_422: printf(" 4:2:2 video\n"); break;
+ case TH_PF_444: printf(" 4:4:4 video\n"); break;
+ case TH_PF_RSVD:
+ default:
+ printf(" video\n (UNKNOWN Chroma sampling!)\n");
+ break;
+ }
+ if(ti.pic_width!=ti.frame_width || ti.pic_height!=ti.frame_height)
+ printf(" Frame content is %dx%d with offset (%d,%d).\n",
+ ti.frame_width, ti.frame_height, ti.pic_x, ti.pic_y);
+ report_colorspace(&ti);
+ dump_comments(&tc);
+ th_decode_ctl(td,TH_DECCTL_GET_PPLEVEL_MAX,&pp_level_max,
+ sizeof(pp_level_max));
+ pp_level=pp_level_max;
+ th_decode_ctl(td,TH_DECCTL_SET_PPLEVEL,&pp_level,sizeof(pp_level));
+ pp_inc=0;
+
+ /*{
+ int arg = 0xffff;
+ th_decode_ctl(td,TH_DECCTL_SET_TELEMETRY_MBMODE,&arg,sizeof(arg));
+ th_decode_ctl(td,TH_DECCTL_SET_TELEMETRY_MV,&arg,sizeof(arg));
+ th_decode_ctl(td,TH_DECCTL_SET_TELEMETRY_QI,&arg,sizeof(arg));
+ arg=10;
+ th_decode_ctl(td,TH_DECCTL_SET_TELEMETRY_BITS,&arg,sizeof(arg));
+ }*/
+ }else{
+ /* tear down the partial theora setup */
+ th_info_clear(&ti);
+ th_comment_clear(&tc);
+ }
+
+ th_setup_free(ts);
+
+ if(vorbis_p){
+ vorbis_synthesis_init(&vd,&vi);
+ vorbis_block_init(&vd,&vb);
+ fprintf(stderr,"Ogg logical stream %lx is Vorbis %d channel %ld Hz audio.\n",
+ vo.serialno,vi.channels,vi.rate);
+ }else{
+ /* tear down the partial vorbis setup */
+ vorbis_info_clear(&vi);
+ vorbis_comment_clear(&vc);
+ }
+
+ /* open audio */
+ if(vorbis_p)open_audio();
+
+ /* open video */
+ if(theora_p)open_video();
+
+ /* install signal handler as SDL clobbered the default */
+ signal (SIGINT, sigint_handler);
+
+ /* on to the main decode loop. We assume in this example that audio
+ and video start roughly together, and don't begin playback until
+ we have a start frame for both. This is not necessarily a valid
+ assumption in Ogg A/V streams! It will always be true of the
+ example_encoder (and most streams) though. */
+
+ stateflag=0; /* playback has not begun */
+ while(!got_sigint){
+
+ /* we want a video and audio frame ready to go at all times. If
+ we have to buffer incoming, buffer the compressed data (ie, let
+ ogg do the buffering) */
+ while(vorbis_p && !audiobuf_ready){
+ int ret;
+ float **pcm;
+
+ /* if there's pending, decoded audio, grab it */
+ if((ret=vorbis_synthesis_pcmout(&vd,&pcm))>0){
+ int count=audiobuf_fill/2;
+ int maxsamples=(audiofd_fragsize-audiobuf_fill)/2/vi.channels;
+ for(i=0;i32767)val=32767;
+ if(val<-32768)val=-32768;
+ audiobuf[count++]=val;
+ }
+ vorbis_synthesis_read(&vd,i);
+ audiobuf_fill+=i*vi.channels*2;
+ if(audiobuf_fill==audiofd_fragsize)audiobuf_ready=1;
+ if(vd.granulepos>=0)
+ audiobuf_granulepos=vd.granulepos-ret+i;
+ else
+ audiobuf_granulepos+=i;
+
+ }else{
+
+ /* no pending audio; is there a pending packet to decode? */
+ if(ogg_stream_packetout(&vo,&op)>0){
+ if(vorbis_synthesis(&vb,&op)==0) /* test for success! */
+ vorbis_synthesis_blockin(&vd,&vb);
+ }else /* we need more data; break out to suck in another page */
+ break;
+ }
+ }
+
+ while(theora_p && !videobuf_ready){
+ /* theora is one in, one out... */
+ if(ogg_stream_packetout(&to,&op)>0){
+
+ if(pp_inc){
+ pp_level+=pp_inc;
+ th_decode_ctl(td,TH_DECCTL_SET_PPLEVEL,&pp_level,
+ sizeof(pp_level));
+ pp_inc=0;
+ }
+ /*HACK: This should be set after a seek or a gap, but we might not have
+ a granulepos for the first packet (we only have them for the last
+ packet on a page), so we just set it as often as we get it.
+ To do this right, we should back-track from the last packet on the
+ page and compute the correct granulepos for the first packet after
+ a seek or a gap.*/
+ if(op.granulepos>=0){
+ th_decode_ctl(td,TH_DECCTL_SET_GRANPOS,&op.granulepos,
+ sizeof(op.granulepos));
+ }
+ if(th_decode_packetin(td,&op,&videobuf_granulepos)==0){
+ videobuf_time=th_granule_time(td,videobuf_granulepos);
+ frames++;
+
+ /* is it already too old to be useful? This is only actually
+ useful cosmetically after a SIGSTOP. Note that we have to
+ decode the frame even if we don't show it (for now) due to
+ keyframing. Soon enough libtheora will be able to deal
+ with non-keyframe seeks. */
+
+ if(videobuf_time>=get_time())
+ videobuf_ready=1;
+ else{
+ /*If we are too slow, reduce the pp level.*/
+ pp_inc=pp_level>0?-1:0;
+ dropped++;
+ }
+ }
+
+ }else
+ break;
+ }
+
+ if(!videobuf_ready && !audiobuf_ready && feof(infile))break;
+
+ if(!videobuf_ready || !audiobuf_ready){
+ /* no data yet for somebody. Grab another page */
+ buffer_data(infile,&oy);
+ while(ogg_sync_pageout(&oy,&og)>0){
+ queue_page(&og);
+ }
+ }
+
+ /* If playback has begun, top audio buffer off immediately. */
+ if(stateflag) audio_write_nonblocking();
+
+ /* are we at or past time for this video frame? */
+ if(stateflag && videobuf_ready && videobuf_time<=get_time()){
+ video_write();
+ videobuf_ready=0;
+ }
+
+ if(stateflag &&
+ (audiobuf_ready || !vorbis_p) &&
+ (videobuf_ready || !theora_p) &&
+ !got_sigint){
+ /* we have an audio frame ready (which means the audio buffer is
+ full), it's not time to play video, so wait until one of the
+ audio buffer is ready or it's near time to play video */
+
+ /* set up select wait on the audiobuffer and a timeout for video */
+ struct timeval timeout;
+ fd_set writefs;
+ fd_set empty;
+ int n=0;
+
+ FD_ZERO(&writefs);
+ FD_ZERO(&empty);
+ if(audiofd>=0){
+ FD_SET(audiofd,&writefs);
+ n=audiofd+1;
+ }
+
+ if(theora_p){
+ double tdiff;
+ long milliseconds;
+ tdiff=videobuf_time-get_time();
+ /*If we have lots of extra time, increase the post-processing level.*/
+ if(tdiff>ti.fps_denominator*0.25/ti.fps_numerator){
+ pp_inc=pp_level0?-1:0;
+ }
+ milliseconds=tdiff*1000-5;
+ if(milliseconds>500)milliseconds=500;
+ if(milliseconds>0){
+ timeout.tv_sec=milliseconds/1000;
+ timeout.tv_usec=(milliseconds%1000)*1000;
+
+ n=select(n,&empty,&writefs,&empty,&timeout);
+ if(n)audio_calibrate_timer(0);
+ }
+ }else{
+ select(n,&empty,&writefs,&empty,NULL);
+ }
+ }
+
+ /* if our buffers either don't exist or are ready to go,
+ we can begin playback */
+ if((!theora_p || videobuf_ready) &&
+ (!vorbis_p || audiobuf_ready))stateflag=1;
+ /* same if we've run out of input */
+ if(feof(infile))stateflag=1;
+
+ }
+
+ /* tear it all down */
+
+ audio_close();
+ SDL_Quit();
+
+ if(vorbis_p){
+ ogg_stream_clear(&vo);
+ vorbis_block_clear(&vb);
+ vorbis_dsp_clear(&vd);
+ vorbis_comment_clear(&vc);
+ vorbis_info_clear(&vi);
+ }
+ if(theora_p){
+ ogg_stream_clear(&to);
+ th_decode_free(td);
+ th_comment_clear(&tc);
+ th_info_clear(&ti);
+ }
+ ogg_sync_clear(&oy);
+
+ if(infile && infile!=stdin)fclose(infile);
+
+ fprintf(stderr,
+ "\r \r");
+ fprintf(stderr, "%d frames", frames);
+ if (dropped) fprintf(stderr, " (%d dropped)", dropped);
+ fprintf(stderr, "\n");
+ fprintf(stderr, "\nDone.\n");
+
+ return(0);
+
+}
diff --git a/libs/libtheora-1.1/examples/png2theora.c b/libs/libtheora-1.1/examples/png2theora.c
new file mode 100644
index 00000000..54728c9d
--- /dev/null
+++ b/libs/libtheora-1.1/examples/png2theora.c
@@ -0,0 +1,942 @@
+/********************************************************************
+ * *
+ * THIS FILE IS PART OF THE OggTheora SOFTWARE CODEC SOURCE CODE. *
+ * USE, DISTRIBUTION AND REPRODUCTION OF THIS LIBRARY SOURCE IS *
+ * GOVERNED BY A BSD-STYLE SOURCE LICENSE INCLUDED WITH THIS SOURCE *
+ * IN 'COPYING'. PLEASE READ THESE TERMS BEFORE DISTRIBUTING. *
+ * *
+ * THE Theora SOURCE CODE IS COPYRIGHT (C) 2002-2009,2009 *
+ * by the Xiph.Org Foundation and contributors http://www.xiph.org/ *
+ * *
+ ********************************************************************
+
+ function: example encoder application; makes an Ogg Theora
+ file from a sequence of png images
+ last mod: $Id: png2theora.c 17975 2011-05-07 22:35:30Z giles $
+ based on code from Vegard Nossum
+
+ ********************************************************************/
+
+#define _FILE_OFFSET_BITS 64
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef HAVE_CONFIG_H
+# include
+#endif
+
+#include
+#include
+#include "theora/theoraenc.h"
+
+#define PROGRAM_NAME "png2theora"
+#define PROGRAM_VERSION "1.1"
+
+static const char *option_output = NULL;
+static int video_fps_numerator = 24;
+static int video_fps_denominator = 1;
+static int video_aspect_numerator = 0;
+static int video_aspect_denominator = 0;
+static int video_rate = -1;
+static int video_quality = -1;
+ogg_uint32_t keyframe_frequency=0;
+int buf_delay=-1;
+int vp3_compatible=0;
+static int chroma_format = TH_PF_420;
+
+static FILE *twopass_file = NULL;
+static int twopass=0;
+static int passno;
+
+static FILE *ogg_fp = NULL;
+static ogg_stream_state ogg_os;
+static ogg_packet op;
+static ogg_page og;
+
+static th_enc_ctx *td;
+static th_info ti;
+
+static char *input_filter;
+
+const char *optstring = "o:hv:\4:\2:V:s:S:f:F:ck:d:\1\2\3\4\5\6";
+struct option options [] = {
+ {"output",required_argument,NULL,'o'},
+ {"help",no_argument,NULL,'h'},
+ {"chroma-444",no_argument,NULL,'\5'},
+ {"chroma-422",no_argument,NULL,'\6'},
+ {"video-rate-target",required_argument,NULL,'V'},
+ {"video-quality",required_argument,NULL,'v'},
+ {"aspect-numerator",required_argument,NULL,'s'},
+ {"aspect-denominator",required_argument,NULL,'S'},
+ {"framerate-numerator",required_argument,NULL,'f'},
+ {"framerate-denominator",required_argument,NULL,'F'},
+ {"vp3-compatible",no_argument,NULL,'c'},
+ {"soft-target",no_argument,NULL,'\1'},
+ {"keyframe-freq",required_argument,NULL,'k'},
+ {"buf-delay",required_argument,NULL,'d'},
+ {"two-pass",no_argument,NULL,'\2'},
+ {"first-pass",required_argument,NULL,'\3'},
+ {"second-pass",required_argument,NULL,'\4'},
+ {NULL,0,NULL,0}
+};
+
+static void usage(void){
+ fprintf(stderr,
+ "%s %s\n"
+ "Usage: %s [options] \n\n"
+ "The input argument uses C printf format to represent a list of files,\n"
+ " i.e. file-%%06d.png to look for files file000001.png to file9999999.png \n\n"
+ "Options: \n\n"
+ " -o --output file name for encoded output (required);\n"
+ " -v --video-quality Theora quality selector fro 0 to 10\n"
+ " (0 yields smallest files but lowest\n"
+ " video quality. 10 yields highest\n"
+ " fidelity but large files)\n\n"
+ " -V --video-rate-target bitrate target for Theora video\n\n"
+ " --soft-target Use a large reservoir and treat the rate\n"
+ " as a soft target; rate control is less\n"
+ " strict but resulting quality is usually\n"
+ " higher/smoother overall. Soft target also\n"
+ " allows an optional -v setting to specify\n"
+ " a minimum allowed quality.\n\n"
+ " --two-pass Compress input using two-pass rate control\n"
+ " This option performs both passes automatically.\n\n"
+ " --first-pass Perform first-pass of a two-pass rate\n"
+ " controlled encoding, saving pass data to\n"
+ " for a later second pass\n\n"
+ " --second-pass Perform second-pass of a two-pass rate\n"
+ " controlled encoding, reading first-pass\n"
+ " data from . The first pass\n"
+ " data must come from a first encoding pass\n"
+ " using identical input video to work\n"
+ " properly.\n\n"
+ " -k --keyframe-freq Keyframe frequency\n"
+ " -d --buf-delay Buffer delay (in frames). Longer delays\n"
+ " allow smoother rate adaptation and provide\n"
+ " better overall quality, but require more\n"
+ " client side buffering and add latency. The\n"
+ " default value is the keyframe interval for\n"
+ " one-pass encoding (or somewhat larger if\n"
+ " --soft-target is used) and infinite for\n"
+ " two-pass encoding.\n"
+ " --chroma-444 Use 4:4:4 chroma subsampling\n"
+ " --chroma-422 Use 4:2:2 chroma subsampling\n"
+ " (4:2:0 is default)\n\n"
+ " -s --aspect-numerator Aspect ratio numerator, default is 0\n"
+ " -S --aspect-denominator Aspect ratio denominator, default is 0\n"
+ " -f --framerate-numerator Frame rate numerator\n"
+ " -F --framerate-denominator Frame rate denominator\n"
+ " The frame rate nominator divided by this\n"
+ " determines the frame rate in units per tick\n"
+ ,PROGRAM_NAME, PROGRAM_VERSION, PROGRAM_NAME
+ );
+ exit(0);
+}
+
+#ifdef WIN32
+int
+alphasort (const void *a, const void *b)
+{
+ return strcoll ((*(const struct dirent **) a)->d_name,
+ (*(const struct dirent **) b)->d_name);
+}
+
+int
+scandir (const char *dir, struct dirent ***namelist,
+ int (*select)(const struct dirent *), int (*compar)(const void *, const void *))
+{
+ DIR *d;
+ struct dirent *entry;
+ register int i=0;
+ size_t entrysize;
+
+ if ((d=opendir(dir)) == NULL)
+ return(-1);
+
+ *namelist=NULL;
+ while ((entry=readdir(d)) != NULL)
+ {
+ if (select == NULL || (select != NULL && (*select)(entry)))
+ {
+ *namelist=(struct dirent **)realloc((void *)(*namelist),
+ (size_t)((i+1)*sizeof(struct dirent *)));
+ if (*namelist == NULL) return(-1);
+ entrysize=sizeof(struct dirent)-sizeof(entry->d_name)+strlen(entry->d_name)+1;
+ (*namelist)[i]=(struct dirent *)malloc(entrysize);
+ if ((*namelist)[i] == NULL) return(-1);
+ memcpy((*namelist)[i], entry, entrysize);
+ i++;
+ }
+ }
+ if (closedir(d)) return(-1);
+ if (i == 0) return(-1);
+ if (compar != NULL)
+ qsort((void *)(*namelist), (size_t)i, sizeof(struct dirent *), compar);
+
+ return(i);
+}
+#endif
+
+static int
+theora_write_frame(th_ycbcr_buffer ycbcr, int last)
+{
+ ogg_packet op;
+ ogg_page og;
+
+ /* Theora is a one-frame-in,one-frame-out system; submit a frame
+ for compression and pull out the packet */
+ /* in two-pass mode's second pass, we need to submit first-pass data */
+ if(passno==2){
+ int ret;
+ for(;;){
+ static unsigned char buffer[80];
+ static int buf_pos;
+ int bytes;
+ /*Ask the encoder how many bytes it would like.*/
+ bytes=th_encode_ctl(td,TH_ENCCTL_2PASS_IN,NULL,0);
+ if(bytes<0){
+ fprintf(stderr,"Error submitting pass data in second pass.\n");
+ exit(1);
+ }
+ /*If it's got enough, stop.*/
+ if(bytes==0)break;
+ /*Read in some more bytes, if necessary.*/
+ if(bytes>80-buf_pos)bytes=80-buf_pos;
+ if(bytes>0&&fread(buffer+buf_pos,1,bytes,twopass_file)=bytes)buf_pos=0;
+ /*Otherwise remember how much it used.*/
+ else buf_pos+=ret;
+ }
+ }
+
+ if(th_encode_ycbcr_in(td, ycbcr)) {
+ fprintf(stderr, "%s: error: could not encode frame\n",
+ option_output);
+ return 1;
+ }
+
+ /* in two-pass mode's first pass we need to extract and save the pass data */
+ if(passno==1){
+ unsigned char *buffer;
+ int bytes = th_encode_ctl(td, TH_ENCCTL_2PASS_OUT, &buffer, sizeof(buffer));
+ if(bytes<0){
+ fprintf(stderr,"Could not read two-pass data from encoder.\n");
+ exit(1);
+ }
+ if(fwrite(buffer,1,bytes,twopass_file) 255)
+ return 255;
+
+ return d;
+}
+
+static void
+rgb_to_yuv(png_bytep *png,
+ th_ycbcr_buffer ycbcr,
+ unsigned int w, unsigned int h)
+{
+ unsigned int x;
+ unsigned int y;
+
+ unsigned int x1;
+ unsigned int y1;
+
+ unsigned long yuv_w;
+
+ unsigned char *yuv_y;
+ unsigned char *yuv_u;
+ unsigned char *yuv_v;
+
+ yuv_w = ycbcr[0].width;
+
+ yuv_y = ycbcr[0].data;
+ yuv_u = ycbcr[1].data;
+ yuv_v = ycbcr[2].data;
+
+ /*This ignores gamma and RGB primary/whitepoint differences.
+ It also isn't terribly fast (though a decent compiler will
+ strength-reduce the division to a multiplication).*/
+
+ if (chroma_format == TH_PF_420) {
+ for(y = 0; y < h; y += 2) {
+ y1=y+(y+1> 1) + (y >> 1) * ycbcr[1].stride] =
+ clamp( ((-33488*r0-65744*g0+99232*b0+29032005)/4 +
+ (-33488*r0-65744*g0+99232*b0+29032005)/4 +
+ (-33488*r2-65744*g2+99232*b2+29032005)/4 +
+ (-33488*r3-65744*g3+99232*b3+29032005)/4)/225930);
+ yuv_v[(x >> 1) + (y >> 1) * ycbcr[2].stride] =
+ clamp( ((157024*r0-131488*g0-25536*b0+45940035)/4 +
+ (157024*r1-131488*g1-25536*b1+45940035)/4 +
+ (157024*r2-131488*g2-25536*b2+45940035)/4 +
+ (157024*r3-131488*g3-25536*b3+45940035)/4)/357510);
+ }
+ }
+ } else if (chroma_format == TH_PF_444) {
+ for(y = 0; y < h; y++) {
+ for(x = 0; x < w; x++) {
+ png_byte r = png[y][3 * x + 0];
+ png_byte g = png[y][3 * x + 1];
+ png_byte b = png[y][3 * x + 2];
+
+ yuv_y[x + y * yuv_w] = clamp((65481*r+128553*g+24966*b+4207500)/255000);
+ yuv_u[x + y * yuv_w] = clamp((-33488*r-65744*g+99232*b+29032005)/225930);
+ yuv_v[x + y * yuv_w] = clamp((157024*r-131488*g-25536*b+45940035)/357510);
+ }
+ }
+ } else { /* TH_PF_422 */
+ for(y = 0; y < h; y += 1) {
+ for(x = 0; x < w; x += 2) {
+ x1=x+(x+1> 1) + y * ycbcr[1].stride] =
+ clamp( ((-33488*r0-65744*g0+99232*b0+29032005)/2 +
+ (-33488*r1-65744*g1+99232*b1+29032005)/2)/225930);
+ yuv_v[(x >> 1) + y * ycbcr[2].stride] =
+ clamp( ((157024*r0-131488*g0-25536*b0+45940035)/2 +
+ (157024*r1-131488*g1-25536*b1+45940035)/2)/357510);
+ }
+ }
+ }
+
+}
+
+static int
+png_read(const char *pathname, unsigned int *w, unsigned int *h, th_ycbcr_buffer ycbcr)
+{
+ FILE *fp;
+ unsigned char header[8];
+ png_structp png_ptr;
+ png_infop info_ptr;
+ png_infop end_ptr;
+ png_bytep row_data;
+ png_bytep *row_pointers;
+ png_color_16p bkgd;
+ png_uint_32 width;
+ png_uint_32 height;
+ unsigned long yuv_w;
+ unsigned long yuv_h;
+ int bit_depth;
+ int color_type;
+ int interlace_type;
+ int compression_type;
+ int filter_method;
+ png_uint_32 y;
+
+ fp = fopen(pathname, "rb");
+ if(!fp) {
+ fprintf(stderr, "%s: error: %s\n",
+ pathname, strerror(errno));
+ return 1;
+ }
+
+ fread(header, 1, 8, fp);
+ if(png_sig_cmp(header, 0, 8)) {
+ fprintf(stderr, "%s: error: %s\n",
+ pathname, "not a PNG");
+ fclose(fp);
+ return 1;
+ }
+
+ png_ptr = png_create_read_struct(PNG_LIBPNG_VER_STRING,
+ NULL, NULL, NULL);
+ if(!png_ptr) {
+ fprintf(stderr, "%s: error: %s\n",
+ pathname, "couldn't create png read structure");
+ fclose(fp);
+ return 1;
+ }
+
+ info_ptr = png_create_info_struct(png_ptr);
+ if(!info_ptr) {
+ fprintf(stderr, "%s: error: %s\n",
+ pathname, "couldn't create png info structure");
+ png_destroy_read_struct(&png_ptr, NULL, NULL);
+ fclose(fp);
+ return 1;
+ }
+
+ end_ptr = png_create_info_struct(png_ptr);
+ if(!end_ptr) {
+ fprintf(stderr, "%s: error: %s\n",
+ pathname, "couldn't create png info structure");
+ png_destroy_read_struct(&png_ptr, &info_ptr, NULL);
+ fclose(fp);
+ return 1;
+ }
+
+ png_init_io(png_ptr, fp);
+ png_set_sig_bytes(png_ptr, 8);
+ png_read_info(png_ptr, info_ptr);
+ png_get_IHDR(png_ptr, info_ptr, &width, &height, &bit_depth, &color_type,
+ &interlace_type, &compression_type, &filter_method);
+ png_set_expand(png_ptr);
+ if(bit_depth<8)png_set_packing(png_ptr);
+ if(bit_depth==16)png_set_strip_16(png_ptr);
+ if(!(color_type&PNG_COLOR_MASK_COLOR))png_set_gray_to_rgb(png_ptr);
+ if(png_get_bKGD(png_ptr, info_ptr, &bkgd)){
+ png_set_background(png_ptr, bkgd, PNG_BACKGROUND_GAMMA_FILE, 1, 1.0);
+ }
+ /*Note that color_type 2 and 3 can also have alpha, despite not setting the
+ PNG_COLOR_MASK_ALPHA bit.
+ We always strip it to prevent libpng from overrunning our buffer.*/
+ png_set_strip_alpha(png_ptr);
+
+ row_data = (png_bytep)png_malloc(png_ptr,
+ 3*height*width*png_sizeof(*row_data));
+ row_pointers = (png_bytep *)png_malloc(png_ptr,
+ height*png_sizeof(*row_pointers));
+ for(y = 0; y < height; y++) {
+ row_pointers[y] = row_data + y*(3*width);
+ }
+ png_read_image(png_ptr, row_pointers);
+ png_read_end(png_ptr, end_ptr);
+
+ *w = width;
+ *h = height;
+ /* Must hold: yuv_w >= w */
+ yuv_w = (*w + 15) & ~15;
+ /* Must hold: yuv_h >= h */
+ yuv_h = (*h + 15) & ~15;
+
+ /* Do we need to allocate a buffer */
+ if (!ycbcr[0].data){
+ ycbcr[0].width = yuv_w;
+ ycbcr[0].height = yuv_h;
+ ycbcr[0].stride = yuv_w;
+ ycbcr[1].width = (chroma_format == TH_PF_444) ? yuv_w : (yuv_w >> 1);
+ ycbcr[1].stride = ycbcr[1].width;
+ ycbcr[1].height = (chroma_format == TH_PF_420) ? (yuv_h >> 1) : yuv_h;
+ ycbcr[2].width = ycbcr[1].width;
+ ycbcr[2].stride = ycbcr[1].stride;
+ ycbcr[2].height = ycbcr[1].height;
+
+ ycbcr[0].data = malloc(ycbcr[0].stride * ycbcr[0].height);
+ ycbcr[1].data = malloc(ycbcr[1].stride * ycbcr[1].height);
+ ycbcr[2].data = malloc(ycbcr[2].stride * ycbcr[2].height);
+ } else {
+ if ((ycbcr[0].width != yuv_w) || (ycbcr[0].height != yuv_h)){
+ fprintf(stderr, "Input size %lux%lu does not match %dx%d\n", yuv_w,yuv_h,ycbcr[0].width,ycbcr[0].height);
+ exit(1);
+ }
+ }
+
+ rgb_to_yuv(row_pointers, ycbcr, *w, *h);
+
+ png_free(png_ptr, row_pointers);
+ png_free(png_ptr, row_data);
+ png_destroy_read_struct(&png_ptr, &info_ptr, &end_ptr);
+
+ fclose(fp);
+ return 0;
+}
+
+static int include_files (const struct dirent *de)
+{
+ char name[1024];
+ int number = -1;
+ sscanf(de->d_name, input_filter, &number);
+ sprintf(name, input_filter, number);
+ return !strcmp(name, de->d_name);
+}
+
+static int ilog(unsigned _v){
+ int ret;
+ for(ret=0;_v;ret++)_v>>=1;
+ return ret;
+}
+
+int
+main(int argc, char *argv[])
+{
+ int c,long_option_index;
+ int i, n;
+ char *input_mask;
+ char *input_directory;
+ char *scratch;
+ th_comment tc;
+ struct dirent **png_files;
+ int soft_target=0;
+ int ret;
+
+ while(1) {
+
+ c=getopt_long(argc,argv,optstring,options,&long_option_index);
+ if(c == EOF)
+ break;
+
+ switch(c) {
+ case 'h':
+ usage();
+ break;
+ case 'o':
+ option_output = optarg;
+ break;;
+ case 'v':
+ video_quality=rint(atof(optarg)*6.3);
+ if(video_quality<0 || video_quality>63){
+ fprintf(stderr,"Illegal video quality (choose 0 through 10)\n");
+ exit(1);
+ }
+ video_rate=0;
+ break;
+ case 'V':
+ video_rate=rint(atof(optarg)*1000);
+ if(video_rate<1){
+ fprintf(stderr,"Illegal video bitrate (choose > 0 please)\n");
+ exit(1);
+ }
+ video_quality=0;
+ break;
+ case '\1':
+ soft_target=1;
+ break;
+ case 'c':
+ vp3_compatible=1;
+ break;
+ case 'k':
+ keyframe_frequency=rint(atof(optarg));
+ if(keyframe_frequency<1 || keyframe_frequency>2147483647){
+ fprintf(stderr,"Illegal keyframe frequency\n");
+ exit(1);
+ }
+ break;
+
+ case 'd':
+ buf_delay=atoi(optarg);
+ if(buf_delay<=0){
+ fprintf(stderr,"Illegal buffer delay\n");
+ exit(1);
+ }
+ break;
+ case 's':
+ video_aspect_numerator=rint(atof(optarg));
+ break;
+ case 'S':
+ video_aspect_denominator=rint(atof(optarg));
+ break;
+ case 'f':
+ video_fps_numerator=rint(atof(optarg));
+ break;
+ case 'F':
+ video_fps_denominator=rint(atof(optarg));
+ break;
+ case '\5':
+ chroma_format=TH_PF_444;
+ break;
+ case '\6':
+ chroma_format=TH_PF_422;
+ break;
+ case '\2':
+ twopass=3; /* perform both passes */
+ twopass_file=tmpfile();
+ if(!twopass_file){
+ fprintf(stderr,"Unable to open temporary file for twopass data\n");
+ exit(1);
+ }
+ break;
+ case '\3':
+ twopass=1; /* perform first pass */
+ twopass_file=fopen(optarg,"wb");
+ if(!twopass_file){
+ fprintf(stderr,"Unable to open \'%s\' for twopass data\n",optarg);
+ exit(1);
+ }
+ break;
+ case '\4':
+ twopass=2; /* perform second pass */
+ twopass_file=fopen(optarg,"rb");
+ if(!twopass_file){
+ fprintf(stderr,"Unable to open twopass data file \'%s\'",optarg);
+ exit(1);
+ }
+ break;
+ default:
+ usage();
+ break;
+ }
+ }
+
+ if(argc < 3) {
+ usage();
+ }
+
+ if(soft_target){
+ if(video_rate<=0){
+ fprintf(stderr,"Soft rate target (--soft-target) requested without a bitrate (-V).\n");
+ exit(1);
+ }
+ if(video_quality==-1)
+ video_quality=0;
+ }else{
+ if(video_rate>0)
+ video_quality=0;
+ if(video_quality==-1)
+ video_quality=48;
+ }
+
+ if(keyframe_frequency<=0){
+ /*Use a default keyframe frequency of 64 for 1-pass (streaming) mode, and
+ 256 for two-pass mode.*/
+ keyframe_frequency=twopass?256:64;
+ }
+
+ input_mask = argv[optind];
+ if (!input_mask) {
+ fprintf(stderr, "no input files specified; run with -h for help.\n");
+ exit(1);
+ }
+ /* dirname and basename must operate on scratch strings */
+ scratch = strdup(input_mask);
+ input_directory = strdup(dirname(scratch));
+ free(scratch);
+ scratch = strdup(input_mask);
+ input_filter = strdup(basename(scratch));
+ free(scratch);
+
+#ifdef DEBUG
+ fprintf(stderr, "scanning %s with filter '%s'\n",
+ input_directory, input_filter);
+#endif
+ n = scandir (input_directory, &png_files, include_files, alphasort);
+
+ if (!n) {
+ fprintf(stderr, "no input files found; run with -h for help.\n");
+ exit(1);
+ }
+
+ ogg_fp = fopen(option_output, "wb");
+ if(!ogg_fp) {
+ fprintf(stderr, "%s: error: %s\n",
+ option_output, "couldn't open output file");
+ return 1;
+ }
+
+ srand(time(NULL));
+ if(ogg_stream_init(&ogg_os, rand())) {
+ fprintf(stderr, "%s: error: %s\n",
+ option_output, "couldn't create ogg stream state");
+ return 1;
+ }
+
+ for(passno=(twopass==3?1:twopass);passno<=(twopass==3?2:twopass);passno++){
+ unsigned int w;
+ unsigned int h;
+ char input_png[1024];
+ th_ycbcr_buffer ycbcr;
+
+ ycbcr[0].data = 0;
+ int last = 0;
+
+ snprintf(input_png, 1023,"%s/%s", input_directory, png_files[0]->d_name);
+ if(png_read(input_png, &w, &h, ycbcr)) {
+ fprintf(stderr, "could not read %s\n", input_png);
+ exit(1);
+ }
+
+ if (passno!=2) fprintf(stderr,"%d frames, %dx%d\n",n,w,h);
+
+ /* setup complete. Raw processing loop */
+ switch(passno){
+ case 0: case 2:
+ fprintf(stderr,"\rCompressing.... \n");
+ break;
+ case 1:
+ fprintf(stderr,"\rScanning first pass.... \n");
+ break;
+ }
+
+ fprintf(stderr, "%s\n", input_png);
+
+ th_info_init(&ti);
+ ti.frame_width = ((w + 15) >>4)<<4;
+ ti.frame_height = ((h + 15)>>4)<<4;
+ ti.pic_width = w;
+ ti.pic_height = h;
+ ti.pic_x = 0;
+ ti.pic_y = 0;
+ ti.fps_numerator = video_fps_numerator;
+ ti.fps_denominator = video_fps_denominator;
+ ti.aspect_numerator = video_aspect_numerator;
+ ti.aspect_denominator = video_aspect_denominator;
+ ti.colorspace = TH_CS_UNSPECIFIED;
+ ti.pixel_fmt = chroma_format;
+ ti.target_bitrate = video_rate;
+ ti.quality = video_quality;
+ ti.keyframe_granule_shift=ilog(keyframe_frequency-1);
+
+ td=th_encode_alloc(&ti);
+ th_info_clear(&ti);
+ /* setting just the granule shift only allows power-of-two keyframe
+ spacing. Set the actual requested spacing. */
+ ret=th_encode_ctl(td,TH_ENCCTL_SET_KEYFRAME_FREQUENCY_FORCE,
+ &keyframe_frequency,sizeof(keyframe_frequency-1));
+ if(ret<0){
+ fprintf(stderr,"Could not set keyframe interval to %d.\n",(int)keyframe_frequency);
+ }
+ if(vp3_compatible){
+ ret=th_encode_ctl(td,TH_ENCCTL_SET_VP3_COMPATIBLE,&vp3_compatible,
+ sizeof(vp3_compatible));
+ if(ret<0||!vp3_compatible){
+ fprintf(stderr,"Could not enable strict VP3 compatibility.\n");
+ if(ret>=0){
+ fprintf(stderr,"Ensure your source format is supported by VP3.\n");
+ fprintf(stderr,
+ "(4:2:0 pixel format, width and height multiples of 16).\n");
+ }
+ }
+ }
+ if(soft_target){
+ /* reverse the rate control flags to favor a 'long time' strategy */
+ int arg = TH_RATECTL_CAP_UNDERFLOW;
+ ret=th_encode_ctl(td,TH_ENCCTL_SET_RATE_FLAGS,&arg,sizeof(arg));
+ if(ret<0)
+ fprintf(stderr,"Could not set encoder flags for --soft-target\n");
+ /* Default buffer control is overridden on two-pass */
+ if(!twopass&&buf_delay<0){
+ if((keyframe_frequency*7>>1) > 5*video_fps_numerator/video_fps_denominator)
+ arg=keyframe_frequency*7>>1;
+ else
+ arg=5*video_fps_numerator/video_fps_denominator;
+ ret=th_encode_ctl(td,TH_ENCCTL_SET_RATE_BUFFER,&arg,sizeof(arg));
+ if(ret<0)
+ fprintf(stderr,"Could not set rate control buffer for --soft-target\n");
+ }
+ }
+ /* set up two-pass if needed */
+ if(passno==1){
+ unsigned char *buffer;
+ int bytes;
+ bytes=th_encode_ctl(td,TH_ENCCTL_2PASS_OUT,&buffer,sizeof(buffer));
+ if(bytes<0){
+ fprintf(stderr,"Could not set up the first pass of two-pass mode.\n");
+ fprintf(stderr,"Did you remember to specify an estimated bitrate?\n");
+ exit(1);
+ }
+ /*Perform a seek test to ensure we can overwrite this placeholder data at
+ the end; this is better than letting the user sit through a whole
+ encode only to find out their pass 1 file is useless at the end.*/
+ if(fseek(twopass_file,0,SEEK_SET)<0){
+ fprintf(stderr,"Unable to seek in two-pass data file.\n");
+ exit(1);
+ }
+ if(fwrite(buffer,1,bytes,twopass_file)=0){
+ ret=th_encode_ctl(td,TH_ENCCTL_SET_RATE_BUFFER,
+ &buf_delay,sizeof(buf_delay));
+ if(ret<0){
+ fprintf(stderr,"Warning: could not set desired buffer delay.\n");
+ }
+ }
+ /* write the bitstream header packets with proper page interleave */
+ th_comment_init(&tc);
+ /* first packet will get its own page automatically */
+ if(th_encode_flushheader(td,&tc,&op)<=0){
+ fprintf(stderr,"Internal Theora library error.\n");
+ exit(1);
+ }
+ th_comment_clear(&tc);
+ if(passno!=1){
+ ogg_stream_packetin(&ogg_os,&op);
+ if(ogg_stream_pageout(&ogg_os,&og)!=1){
+ fprintf(stderr,"Internal Ogg library error.\n");
+ exit(1);
+ }
+ fwrite(og.header,1,og.header_len,ogg_fp);
+ fwrite(og.body,1,og.body_len,ogg_fp);
+ }
+ /* create the remaining theora headers */
+ for(;;){
+ ret=th_encode_flushheader(td,&tc,&op);
+ if(ret<0){
+ fprintf(stderr,"Internal Theora library error.\n");
+ exit(1);
+ }
+ else if(!ret)break;
+ if(passno!=1)ogg_stream_packetin(&ogg_os,&op);
+ }
+ /* Flush the rest of our headers. This ensures
+ the actual data in each stream will start
+ on a new page, as per spec. */
+ if(passno!=1){
+ for(;;){
+ int result = ogg_stream_flush(&ogg_os,&og);
+ if(result<0){
+ /* can't get here */
+ fprintf(stderr,"Internal Ogg library error.\n");
+ exit(1);
+ }
+ if(result==0)break;
+ fwrite(og.header,1,og.header_len,ogg_fp);
+ fwrite(og.body,1,og.body_len,ogg_fp);
+ }
+ }
+
+ i=0; last=0;
+ do {
+ if(i >= n-1) last = 1;
+ if(theora_write_frame(ycbcr, last)) {
+ fprintf(stderr,"Encoding error.\n");
+ exit(1);
+ }
+
+ i++;
+ if (!last) {
+ snprintf(input_png, 1023,"%s/%s", input_directory, png_files[i]->d_name);
+ if(png_read(input_png, &w, &h, ycbcr)) {
+ fprintf(stderr, "could not read %s\n", input_png);
+ exit(1);
+ }
+ fprintf(stderr, "%s\n", input_png);
+ }
+ } while (!last);
+
+ if(passno==1){
+ /* need to read the final (summary) packet */
+ unsigned char *buffer;
+ int bytes = th_encode_ctl(td, TH_ENCCTL_2PASS_OUT, &buffer, sizeof(buffer));
+ if(bytes<0){
+ fprintf(stderr,"Could not read two-pass summary data from encoder.\n");
+ exit(1);
+ }
+ if(fseek(twopass_file,0,SEEK_SET)<0){
+ fprintf(stderr,"Unable to seek in two-pass data file.\n");
+ exit(1);
+ }
+ if(fwrite(buffer,1,bytes,twopass_file)
+#endif
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "theora/theora.h"
+#include "vorbis/codec.h"
+
+#ifdef WIN32
+#include
+#include
+#endif
+
+#include
+#include
+
+/* for portaudio */
+#define FRAMES_PER_BUFFER (256)
+
+/*start of portaudio helper functions, extracted from pablio directory*/
+
+/* Pa_streamio routines modified by mauricio at xiph.org
+ * Modified version of Portable Audio Blocking read/write utility.
+ * from the original PABLIO files
+ * Modified to support only playback buffers, direct access
+ * to the underlying stream time and remove blocking operations*/
+
+/* PortAudio copyright notice follows */
+
+/*
+ * Author: Phil Burk, http://www.softsynth.com
+ *
+ * This program uses the PortAudio Portable Audio Library.
+ * For more information see: http://www.audiomulch.com/portaudio/
+ * Copyright (c) 1999-2000 Ross Bencina and Phil Burk
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining
+ * a copy of this software and associated documentation files
+ * (the "Software"), to deal in the Software without restriction,
+ * including without limitation the rights to use, copy, modify, merge,
+ * publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so,
+ * subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ */
+
+typedef struct
+{
+ long bufferSize; /* Number of bytes in FIFO. Power of 2. Set by RingBuffer_Init. */
+/* These are declared volatile because they are written by a different thread than the reader. */
+ volatile long writeIndex; /* Index of next writable byte. Set by RingBuffer_AdvanceWriteIndex. */
+ volatile long readIndex; /* Index of next readable byte. Set by RingBuffer_AdvanceReadIndex. */
+ long bigMask; /* Used for wrapping indices with extra bit to distinguish full/empty. */
+ long smallMask; /* Used for fitting indices to buffer. */
+ char *buffer;
+}
+RingBuffer;
+
+typedef struct
+{
+ RingBuffer outFIFO;
+ PortAudioStream *stream;
+ int bytesPerFrame;
+ int samplesPerFrame;
+}
+PASTREAMIO_Stream;
+
+/* Values for flags for OpenAudioStream(). */
+/* Keep PABLIO ones*/
+
+#define PASTREAMIO_READ (1<<0)
+#define PASTREAMIO_WRITE (1<<1)
+#define PASTREAMIO_READ_WRITE (PABLIO_READ|PABLIO_WRITE)
+#define PASTREAMIO_MONO (1<<2)
+#define PASTREAMIO_STEREO (1<<3)
+
+/***************************************************************************
+** Helper function added to report stream time. */
+
+PaTimestamp GetAudioStreamTime( PASTREAMIO_Stream *aStream ){
+ return Pa_StreamTime( aStream->stream ) ;
+}
+
+ /***************************************************************************
+** Clear buffer. Should only be called when buffer is NOT being read. */
+void RingBuffer_Flush( RingBuffer *rbuf )
+{
+ rbuf->writeIndex = rbuf->readIndex = 0;
+}
+
+/***************************************************************************
+ * Initialize FIFO.
+ * numBytes must be power of 2, returns -1 if not.
+ */
+long RingBuffer_Init( RingBuffer *rbuf, long numBytes, void *dataPtr )
+{
+ if( ((numBytes-1) & numBytes) != 0) return -1; /* Not Power of two. */
+ rbuf->bufferSize = numBytes;
+ rbuf->buffer = (char *)dataPtr;
+ RingBuffer_Flush( rbuf );
+ rbuf->bigMask = (numBytes*2)-1;
+ rbuf->smallMask = (numBytes)-1;
+ return 0;
+}
+/***************************************************************************
+** Return number of bytes available for reading. */
+long RingBuffer_GetReadAvailable( RingBuffer *rbuf )
+{
+ return ( (rbuf->writeIndex - rbuf->readIndex) & rbuf->bigMask );
+}
+/***************************************************************************
+** Return number of bytes available for writing. */
+long RingBuffer_GetWriteAvailable( RingBuffer *rbuf )
+{
+ return ( rbuf->bufferSize - RingBuffer_GetReadAvailable(rbuf));
+}
+
+
+/***************************************************************************
+** Get address of region(s) to which we can write data.
+** If the region is contiguous, size2 will be zero.
+** If non-contiguous, size2 will be the size of second region.
+** Returns room available to be written or numBytes, whichever is smaller.
+*/
+long RingBuffer_GetWriteRegions( RingBuffer *rbuf, long numBytes,
+ void **dataPtr1, long *sizePtr1,
+ void **dataPtr2, long *sizePtr2 )
+{
+ long index;
+ long available = RingBuffer_GetWriteAvailable( rbuf );
+ if( numBytes > available ) numBytes = available;
+ /* Check to see if write is not contiguous. */
+ index = rbuf->writeIndex & rbuf->smallMask;
+ if( (index + numBytes) > rbuf->bufferSize )
+ {
+ /* Write data in two blocks that wrap the buffer. */
+ long firstHalf = rbuf->bufferSize - index;
+ *dataPtr1 = &rbuf->buffer[index];
+ *sizePtr1 = firstHalf;
+ *dataPtr2 = &rbuf->buffer[0];
+ *sizePtr2 = numBytes - firstHalf;
+ }
+ else
+ {
+ *dataPtr1 = &rbuf->buffer[index];
+ *sizePtr1 = numBytes;
+ *dataPtr2 = NULL;
+ *sizePtr2 = 0;
+ }
+ return numBytes;
+}
+
+
+/***************************************************************************
+*/
+long RingBuffer_AdvanceWriteIndex( RingBuffer *rbuf, long numBytes )
+{
+ return rbuf->writeIndex = (rbuf->writeIndex + numBytes) & rbuf->bigMask;
+}
+
+/***************************************************************************
+** Get address of region(s) from which we can read data.
+** If the region is contiguous, size2 will be zero.
+** If non-contiguous, size2 will be the size of second region.
+** Returns room available to be written or numBytes, whichever is smaller.
+*/
+long RingBuffer_GetReadRegions( RingBuffer *rbuf, long numBytes,
+ void **dataPtr1, long *sizePtr1,
+ void **dataPtr2, long *sizePtr2 )
+{
+ long index;
+ long available = RingBuffer_GetReadAvailable( rbuf );
+ if( numBytes > available ) numBytes = available;
+ /* Check to see if read is not contiguous. */
+ index = rbuf->readIndex & rbuf->smallMask;
+ if( (index + numBytes) > rbuf->bufferSize )
+ {
+ /* Write data in two blocks that wrap the buffer. */
+ long firstHalf = rbuf->bufferSize - index;
+ *dataPtr1 = &rbuf->buffer[index];
+ *sizePtr1 = firstHalf;
+ *dataPtr2 = &rbuf->buffer[0];
+ *sizePtr2 = numBytes - firstHalf;
+ }
+ else
+ {
+ *dataPtr1 = &rbuf->buffer[index];
+ *sizePtr1 = numBytes;
+ *dataPtr2 = NULL;
+ *sizePtr2 = 0;
+ }
+ return numBytes;
+}
+/***************************************************************************
+*/
+long RingBuffer_AdvanceReadIndex( RingBuffer *rbuf, long numBytes )
+{
+ return rbuf->readIndex = (rbuf->readIndex + numBytes) & rbuf->bigMask;
+}
+
+/***************************************************************************
+** Return bytes written. */
+long RingBuffer_Write( RingBuffer *rbuf, void *data, long numBytes )
+{
+ long size1, size2, numWritten;
+ void *data1, *data2;
+ numWritten = RingBuffer_GetWriteRegions( rbuf, numBytes, &data1, &size1, &data2, &size2 );
+ if( size2 > 0 )
+ {
+
+ memcpy( data1, data, size1 );
+ data = ((char *)data) + size1;
+ memcpy( data2, data, size2 );
+ }
+ else
+ {
+ memcpy( data1, data, size1 );
+ }
+ RingBuffer_AdvanceWriteIndex( rbuf, numWritten );
+ return numWritten;
+}
+
+/***************************************************************************
+** Return bytes read. */
+long RingBuffer_Read( RingBuffer *rbuf, void *data, long numBytes )
+{
+ long size1, size2, numRead;
+ void *data1, *data2;
+ numRead = RingBuffer_GetReadRegions( rbuf, numBytes, &data1, &size1, &data2, &size2 );
+ if( size2 > 0 )
+ {
+ memcpy( data, data1, size1 );
+ data = ((char *)data) + size1;
+ memcpy( data, data2, size2 );
+ }
+ else
+ {
+ memcpy( data, data1, size1 );
+ }
+ RingBuffer_AdvanceReadIndex( rbuf, numRead );
+ return numRead;
+}
+
+
+/************************************************************************/
+/******** Functions *****************************************************/
+/************************************************************************/
+
+/* Called from PortAudio.
+ * Read and write data only if there is room in FIFOs.
+ */
+static int audioIOCallback( void *inputBuffer, void *outputBuffer,
+ unsigned long framesPerBuffer,
+ PaTimestamp outTime, void *userData )
+{
+ PASTREAMIO_Stream *data = (PASTREAMIO_Stream*)userData;
+ long numBytes = data->bytesPerFrame * framesPerBuffer;
+ (void) outTime;
+ (void) inputBuffer;
+
+ if( outputBuffer != NULL )
+ {
+ int i;
+ int numRead = RingBuffer_Read( &data->outFIFO, outputBuffer, numBytes );
+ /* Zero out remainder of buffer if we run out of data. */
+ for( i=numRead; ibuffer ) free( rbuf->buffer );
+ rbuf->buffer = NULL;
+ return paNoError;
+}
+
+/************************************************************
+ * Write data to ring buffer.
+ * Will not return until all the data has been written.
+ */
+long WriteAudioStream( PASTREAMIO_Stream *aStream, void *data, long numFrames )
+{
+ long bytesWritten;
+ char *p = (char *) data;
+ long numBytes = aStream->bytesPerFrame * numFrames;
+ while( numBytes > 0)
+ {
+ bytesWritten = RingBuffer_Write( &aStream->outFIFO, p, numBytes );
+ numBytes -= bytesWritten;
+ p += bytesWritten;
+ if( numBytes > 0) Pa_Sleep(10);
+ }
+ return numFrames;
+}
+
+
+/************************************************************
+ * Return the number of frames that could be written to the stream without
+ * having to wait.
+ */
+long GetAudioStreamWriteable( PASTREAMIO_Stream *aStream )
+{
+ int bytesEmpty = RingBuffer_GetWriteAvailable( &aStream->outFIFO );
+ return bytesEmpty / aStream->bytesPerFrame;
+}
+
+
+
+/************************************************************/
+unsigned long RoundUpToNextPowerOf2( unsigned long n )
+{
+ long numBits = 0;
+ if( ((n-1) & n) == 0) return n; /* Already Power of two. */
+ while( n > 0 )
+ {
+ n= n>>1;
+ numBits++;
+ }
+ return (1<samplesPerFrame = ((flags&PASTREAMIO_MONO) != 0) ? 1 : 2;
+ aStream->bytesPerFrame = bytesPerSample * aStream->samplesPerFrame;
+
+ /* Initialize PortAudio */
+ err = Pa_Initialize();
+ if( err != paNoError ) goto error;
+
+ /* Warning: numFrames must be larger than amount of data processed per interrupt
+ * inside PA to prevent glitches. Just to be safe, adjust size upwards.
+ */
+ minNumBuffers = 2 * Pa_GetMinNumBuffers( FRAMES_PER_BUFFER, sampleRate );
+ numFrames = minNumBuffers * FRAMES_PER_BUFFER;
+ numFrames = RoundUpToNextPowerOf2( numFrames );
+
+ /* Initialize Ring Buffer */
+ doWrite = ((flags & PASTREAMIO_WRITE) != 0);
+
+ if(doWrite)
+ {
+ err = PASTREAMIO_InitFIFO( &aStream->outFIFO, numFrames, aStream->bytesPerFrame );
+ if( err != paNoError ) goto error;
+ /* Make Write FIFO appear full initially.
+ numBytes = RingBuffer_GetWriteAvailable( &aStream->outFIFO );
+ RingBuffer_AdvanceWriteIndex( &aStream->outFIFO, numBytes );*/
+ }
+
+ /* Open a PortAudio stream that we will use to communicate with the underlying
+ * audio drivers. */
+ err = Pa_OpenStream(
+ &aStream->stream,
+ paNoDevice,
+ 0 ,
+ format,
+ NULL,
+ Pa_GetDefaultOutputDeviceID() ,
+ aStream->samplesPerFrame ,
+ format,
+ NULL,
+ sampleRate,
+ FRAMES_PER_BUFFER,
+ minNumBuffers,
+ paClipOff, /* we won't output out of range samples so don't bother clipping them */
+ audioIOCallback,
+ aStream );
+ if( err != paNoError ) goto error;
+
+ *rwblPtr = aStream;
+ return paNoError;
+
+error:
+ CloseAudioStream( aStream );
+ *rwblPtr = NULL;
+ return err;
+}
+
+PaError StartAudioStream( PASTREAMIO_Stream *aStream)
+{
+ PaError err;
+ err = Pa_StartStream( aStream->stream );
+ if( err != paNoError ) goto error;
+
+ return paNoError;
+error:
+ CloseAudioStream( aStream );
+ return err;
+}
+
+
+/************************************************************/
+PaError CloseAudioStream( PASTREAMIO_Stream *aStream )
+{
+ PaError err;
+ int bytesEmpty;
+ int byteSize = aStream->outFIFO.bufferSize;
+
+ /* If we are writing data, make sure we play everything written. */
+ if( byteSize > 0 )
+ {
+ bytesEmpty = RingBuffer_GetWriteAvailable( &aStream->outFIFO );
+ while( bytesEmpty < byteSize )
+ {
+ Pa_Sleep( 10 );
+ bytesEmpty = RingBuffer_GetWriteAvailable( &aStream->outFIFO );
+ }
+ }
+
+ err = Pa_StopStream( aStream->stream );
+ if( err != paNoError ) goto error;
+ err = Pa_CloseStream( aStream->stream );
+ if( err != paNoError ) goto error;
+ Pa_Terminate();
+
+error:
+ PASTREAMIO_TermFIFO( &aStream->outFIFO );
+ free( aStream );
+ return err;
+}
+
+/* -- end of portaudio specific routines --*/
+
+/* portaudio related global types */
+#define PA_SAMPLE_TYPE paInt16
+typedef short SAMPLE;
+#define SAMPLE_SILENCE (0)
+
+PASTREAMIO_Stream *aOutStream; /* our modified stream buffer*/
+SAMPLE *samples; /*local buffer for samples*/
+double latency_sec = 0;
+
+/* ticks information to be used if the audio stream is not present */
+int currentTicks = -1;
+
+/* initial state of the audio stream */
+int isPlaying = 0;
+PaError err;
+
+/* Ogg and codec state for demux/decode */
+ogg_sync_state oy;
+ogg_page og;
+ogg_stream_state vo;
+ogg_stream_state to;
+theora_info ti;
+theora_comment tc;
+theora_state td;
+vorbis_info vi;
+vorbis_dsp_state vd;
+vorbis_block vb;
+vorbis_comment vc;
+
+int theora_p=0;
+int vorbis_p=0;
+int stateflag=0;
+
+FILE * infile = NULL;
+
+/* SDL Video playback structures */
+SDL_Surface *screen;
+SDL_Overlay *yuv_overlay;
+SDL_Rect rect;
+
+/* single frame video buffering */
+int videobuf_ready=0;
+ogg_int64_t videobuf_granulepos=-1;
+double videobuf_time=0;
+
+int audiobuf_ready=0;
+ogg_int64_t audiobuf_granulepos=0; /* time position of last sample */
+
+static int open_audio(){
+ /* this will open one circular audio stream */
+ /* build on top of portaudio routines */
+ /* implementation based on file pastreamio.c */
+
+ int numSamples;
+ int numBytes;
+
+ int minNumBuffers;
+ int numFrames;
+
+ minNumBuffers = 2 * Pa_GetMinNumBuffers( FRAMES_PER_BUFFER, vi.rate );
+ numFrames = minNumBuffers * FRAMES_PER_BUFFER;
+ numFrames = RoundUpToNextPowerOf2( numFrames );
+
+ numSamples = numFrames * vi.channels;
+ numBytes = numSamples * sizeof(SAMPLE);
+
+ samples = (SAMPLE *) malloc( numBytes );
+
+ /* store our latency calculation here */
+ latency_sec = (double) numFrames / vi.rate / vi.channels;
+ printf( "Latency: %.04f\n", latency_sec );
+
+ err = OpenAudioStream( &aOutStream, vi.rate, PA_SAMPLE_TYPE,
+ (PASTREAMIO_WRITE | PASTREAMIO_STEREO) );
+ if( err != paNoError ) goto error;
+ return err;
+error:
+ CloseAudioStream( aOutStream );
+ printf( "An error occured while opening the portaudio stream\n" );
+ printf( "Error number: %d\n", err );
+ printf( "Error message: %s\n", Pa_GetErrorText( err ) );
+ return err;
+
+}
+
+static int start_audio(){
+ err = StartAudioStream(aOutStream);
+ if( err != paNoError ) goto error;
+
+ return err;
+error:
+ CloseAudioStream( aOutStream );
+ printf( "An error occured while opening the portaudio stream\n" );
+ printf( "Error number: %d\n", err );
+ printf( "Error message: %s\n", Pa_GetErrorText( err ) );
+ return err;
+}
+
+static int audio_close(void){
+ err = CloseAudioStream( aOutStream );
+ if( err != paNoError ) goto error;
+
+ free(samples);
+ return err;
+error:
+ Pa_Terminate();
+ printf( "An error occured while closing the portaudio stream\n" );
+ printf( "Error number: %d\n", err );
+ printf( "Error message: %s\n", Pa_GetErrorText( err ) );
+ return err;
+}
+
+
+double get_time() {
+ static Uint32 startticks = 0;
+ double curtime;
+ if (vorbis_p) {
+ /* not entirely accurate with the WAVE OUT device, but good enough
+ at this stage. Needs to be reworked to account for blank audio
+ data written to the stream... */
+ curtime = (double) (GetAudioStreamTime( aOutStream ) / vi.rate) - latency_sec;
+ if (curtime<0.0) curtime = 0.0;
+ } else {
+ /* initialize timer variable if not set yet */
+ if (startticks==0)
+ startticks = SDL_GetTicks();
+ curtime = 1.0e-3 * (double)(SDL_GetTicks() - startticks);
+ }
+ return curtime;
+}
+
+
+static void open_video(void){
+ /* taken from player_sample.c test file for theora alpha */
+
+ if ( SDL_Init(SDL_INIT_VIDEO) < 0 ) {
+ printf("Unable to initialize SDL: %s\n", SDL_GetError());
+ exit(1);
+ }
+
+ screen = SDL_SetVideoMode(ti.frame_width, ti.frame_height, 0, SDL_SWSURFACE);
+ if ( screen == NULL ) {
+ printf("Unable to set %dx%d video mode: %s\n",
+ ti.frame_width,ti.frame_height,SDL_GetError());
+ exit(1);
+ }
+
+ yuv_overlay = SDL_CreateYUVOverlay(ti.frame_width, ti.frame_height,
+ SDL_YV12_OVERLAY,
+ screen);
+ if ( yuv_overlay == NULL ) {
+ printf("SDL: Couldn't create SDL_yuv_overlay: %s\n",
+ SDL_GetError());
+ exit(1);
+ }
+ rect.x = 0;
+ rect.y = 0;
+ rect.w = ti.frame_width;
+ rect.h = ti.frame_height;
+
+ SDL_DisplayYUVOverlay(yuv_overlay, &rect);
+}
+
+static void video_write(void){
+ /* taken from player_sample.c test file for theora alpha */
+ int i;
+ yuv_buffer yuv;
+ int crop_offset;
+ theora_decode_YUVout(&td,&yuv);
+
+ /* Lock SDL_yuv_overlay */
+ if ( SDL_MUSTLOCK(screen) ) {
+ if ( SDL_LockSurface(screen) < 0 ) return;
+ }
+ if (SDL_LockYUVOverlay(yuv_overlay) < 0) return;
+
+ /* let's draw the data (*yuv[3]) on a SDL screen (*screen) */
+ /* deal with border stride */
+ /* reverse u and v for SDL */
+ /* and crop input properly, respecting the encoded frame rect */
+ crop_offset=ti.offset_x+yuv.y_stride*ti.offset_y;
+ for(i=0;ih;i++)
+ memcpy(yuv_overlay->pixels[0]+yuv_overlay->pitches[0]*i,
+ yuv.y+crop_offset+yuv.y_stride*i,
+ yuv_overlay->w);
+ crop_offset=(ti.offset_x/2)+(yuv.uv_stride)*(ti.offset_y/2);
+ for(i=0;ih/2;i++){
+ memcpy(yuv_overlay->pixels[1]+yuv_overlay->pitches[1]*i,
+ yuv.v+crop_offset+yuv.uv_stride*i,
+ yuv_overlay->w/2);
+ memcpy(yuv_overlay->pixels[2]+yuv_overlay->pitches[2]*i,
+ yuv.u+crop_offset+yuv.uv_stride*i,
+ yuv_overlay->w/2);
+ }
+
+ /* Unlock SDL_yuv_overlay */
+ SDL_UnlockYUVOverlay(yuv_overlay);
+ if ( SDL_MUSTLOCK(screen) ) {
+ SDL_UnlockSurface(screen);
+ }
+
+ /* Show, baby, show! */
+ SDL_DisplayYUVOverlay(yuv_overlay, &rect);
+}
+
+static void usage(void){
+ printf("Usage: splayer \n"
+#ifdef WIN32
+ "\n"
+ "or drag and drop an ogg file over the .exe\n\n"
+#endif
+ );
+}
+
+/* dump the theora (or vorbis) comment header */
+static int dump_comments(theora_comment *tc){
+ int i, len;
+ char *value;
+
+ printf("Encoded by %s\n",tc->vendor);
+ if(tc->comments){
+ printf("theora comment header:\n");
+ for(i=0;icomments;i++){
+ if(tc->user_comments[i]){
+ len=tc->comment_lengths[i];
+ value=malloc(len+1);
+ memcpy(value,tc->user_comments[i],len);
+ value[len]='\0';
+ printf("\t%s\n", value);
+ free(value);
+ }
+ }
+ }
+ return(0);
+}
+
+/* Report the encoder-specified colorspace for the video, if any.
+ We don't actually make use of the information in this example;
+ a real player should attempt to perform color correction for
+ whatever display device it supports. */
+static void report_colorspace(theora_info *ti)
+{
+ switch(ti->colorspace){
+ case OC_CS_UNSPECIFIED:
+ /* nothing to report */
+ break;;
+ case OC_CS_ITU_REC_470M:
+ fprintf(stderr," encoder specified ITU Rec 470M color.\n");
+ break;;
+ case OC_CS_ITU_REC_470BG:
+ fprintf(stderr," encoder specified ITU Rec 470BG color.\n");
+ break;;
+ default:
+ fprintf(stderr,"warning: encoder specified unknown colorspace (%d).\n",
+ ti->colorspace);
+ break;;
+ }
+}
+
+/* Helper; just grab some more compressed bitstream and sync it for
+ page extraction */
+int buffer_data(ogg_sync_state *oy){
+ char *buffer=ogg_sync_buffer(oy,4096);
+ int bytes=fread(buffer,1,4096,infile);
+ ogg_sync_wrote(oy,bytes);
+ return(bytes);
+}
+
+/* helper: push a page into the appropriate stream */
+/* this can be done blindly; a stream won't accept a page
+ that doesn't belong to it */
+static int queue_page(ogg_page *page){
+ if(theora_p)ogg_stream_pagein(&to,page);
+ if(vorbis_p)ogg_stream_pagein(&vo,page);
+ return 0;
+}
+
+void parseHeaders(){
+ /* extracted from player_sample.c test file for theora alpha */
+ ogg_packet op;
+ /* Parse the headers */
+ /* Only interested in Vorbis/Theora streams */
+ while(!stateflag){
+ int ret=buffer_data(&oy);
+ if(ret==0)break;
+ while(ogg_sync_pageout(&oy,&og)>0){
+ ogg_stream_state test;
+
+ /* is this a mandated initial header? If not, stop parsing */
+ if(!ogg_page_bos(&og)){
+ /* don't leak the page; get it into the appropriate stream */
+ queue_page(&og);
+ stateflag=1;
+ break;
+ }
+
+ ogg_stream_init(&test,ogg_page_serialno(&og));
+ ogg_stream_pagein(&test,&og);
+ ogg_stream_packetout(&test,&op);
+
+ /* identify the codec: try theora */
+ if(!theora_p && theora_decode_header(&ti,&tc,&op)>=0){
+ /* it is theora */
+ memcpy(&to,&test,sizeof(test));
+ theora_p=1;
+ }else if(!vorbis_p && vorbis_synthesis_headerin(&vi,&vc,&op)>=0){
+ /* it is vorbis */
+ memcpy(&vo,&test,sizeof(test));
+ vorbis_p=1;
+ }else{
+ /* whatever it is, we don't care about it */
+ ogg_stream_clear(&test);
+ }
+ }
+ }
+
+ /* we've now identified all the bitstreams. parse the secondary header packets. */
+ while((theora_p && theora_p<3) || (vorbis_p && vorbis_p<3)){
+ int ret;
+
+ /* look for further theora headers */
+ while(theora_p && (theora_p<3) && (ret=ogg_stream_packetout(&to,&op))){
+ if(ret<0){
+ printf("Error parsing Theora stream headers; corrupt stream?\n");
+ exit(1);
+ }
+ if(theora_decode_header(&ti,&tc,&op)){
+ printf("Error parsing Theora stream headers; corrupt stream?\n");
+ exit(1);
+ }
+ theora_p++;
+ if(theora_p==3)break;
+ }
+
+ /* look for more vorbis header packets */
+ while(vorbis_p && (vorbis_p<3) && (ret=ogg_stream_packetout(&vo,&op))){
+ if(ret<0){
+ printf("Error parsing Vorbis stream headers; corrupt stream?\n");
+ exit(1);
+ }
+ if(vorbis_synthesis_headerin(&vi,&vc,&op)){
+ printf("Error parsing Vorbis stream headers; corrupt stream?\n");
+ exit(1);
+ }
+ vorbis_p++;
+ if(vorbis_p==3)break;
+ }
+
+ /* The header pages/packets will arrive before anything else we
+ care about, or the stream is not obeying spec */
+
+ if(ogg_sync_pageout(&oy,&og)>0){
+ queue_page(&og); /* demux into the appropriate stream */
+ }else{
+ int ret=buffer_data(&oy);
+ if(ret==0){
+ fprintf(stderr,"End of file while searching for codec headers.\n");
+ exit(1);
+ }
+ }
+ }
+}
+
+int main( int argc, char* argv[] ){
+
+ int i,j;
+ ogg_packet op;
+ SDL_Event event;
+ int hasdatatobuffer = 1;
+ int playbackdone = 0;
+ double now, delay, last_frame_time = 0;
+
+ int frameNum=0;
+ int skipNum=0;
+
+ /* takes first argument as file to play */
+ /* this works better on Windows and is more convenient
+ for drag and drop ogg files over the .exe */
+
+ if( argc != 2 )
+ {
+ usage();
+ exit(0);
+ }
+
+ infile = fopen( argv[1], "rb" );
+
+ /* start up Ogg stream synchronization layer */
+ ogg_sync_init(&oy);
+
+ /* init supporting Vorbis structures needed in header parsing */
+ vorbis_info_init(&vi);
+ vorbis_comment_init(&vc);
+
+ /* init supporting Theora structures needed in header parsing */
+ theora_comment_init(&tc);
+ theora_info_init(&ti);
+
+ parseHeaders();
+
+ /* force audio off */
+ /* vorbis_p = 0; */
+
+ /* initialize decoders */
+ if(theora_p){
+ theora_decode_init(&td,&ti);
+ printf("Ogg logical stream %x is Theora %dx%d %.02f fps video\n"
+ " Frame content is %dx%d with offset (%d,%d).\n",
+ to.serialno,ti.width,ti.height, (double)ti.fps_numerator/ti.fps_denominator,
+ ti.frame_width, ti.frame_height, ti.offset_x, ti.offset_y);
+ report_colorspace(&ti);
+ dump_comments(&tc);
+ }else{
+ /* tear down the partial theora setup */
+ theora_info_clear(&ti);
+ theora_comment_clear(&tc);
+ }
+ if(vorbis_p){
+ vorbis_synthesis_init(&vd,&vi);
+ vorbis_block_init(&vd,&vb);
+ printf("Ogg logical stream %x is Vorbis %d channel %d Hz audio.\n",
+ vo.serialno,vi.channels,vi.rate);
+ }else{
+ /* tear down the partial vorbis setup */
+ vorbis_info_clear(&vi);
+ vorbis_comment_clear(&vc);
+ }
+ /* open audio */
+ if(vorbis_p)open_audio();
+ /* open video */
+ if(theora_p)open_video();
+
+ /* our main loop */
+ while(!playbackdone){
+
+ /* break out on SDL quit event */
+ if ( SDL_PollEvent ( &event ) )
+ {
+ if ( event.type == SDL_QUIT ) break ;
+ }
+
+ /* get some audio data */
+ while(vorbis_p && !audiobuf_ready){
+ int ret;
+ float **pcm;
+ int count = 0;
+ int maxBytesToWrite;
+
+ /* is there pending audio? does it fit our circular buffer without blocking? */
+ ret=vorbis_synthesis_pcmout(&vd,&pcm);
+ maxBytesToWrite = GetAudioStreamWriteable(aOutStream);
+
+ if (maxBytesToWrite<=FRAMES_PER_BUFFER){
+ /* break out until there is a significant amount of
+ data to avoid a series of small write operations. */
+ break;
+ }
+ /* if there's pending, decoded audio, grab it */
+ if((ret>0)&&(maxBytesToWrite>0)){
+
+ for(i=0;i32767)val=32767;
+ if(val<-32768)val=-32768;
+ samples[count]=val;
+ count++;
+ }
+ if(WriteAudioStream( aOutStream, samples, i )) {
+ if(count==maxBytesToWrite){
+ audiobuf_ready=1;
+ }
+ }
+ vorbis_synthesis_read(&vd,i);
+
+ if(vd.granulepos>=0)
+ audiobuf_granulepos=vd.granulepos-ret+i;
+ else
+ audiobuf_granulepos+=i;
+
+ }else{
+
+ /* no pending audio; is there a pending packet to decode? */
+ if(ogg_stream_packetout(&vo,&op)>0){
+ if(vorbis_synthesis(&vb,&op)==0) /* test for success! */
+ vorbis_synthesis_blockin(&vd,&vb);
+ }else /* we need more data; break out to suck in another page */
+ break;
+ }
+ } /* end audio cycle */
+
+ while(theora_p && !videobuf_ready){
+ /* get one video packet... */
+ if(ogg_stream_packetout(&to,&op)>0){
+
+ theora_decode_packetin(&td,&op);
+
+ videobuf_granulepos=td.granulepos;
+ videobuf_time=theora_granule_time(&td,videobuf_granulepos);
+ /* update the frame counter */
+ frameNum++;
+
+ /* check if this frame time has not passed yet.
+ If the frame is late we need to decode additonal
+ ones and keep looping, since theora at this stage
+ needs to decode all frames */
+ now=get_time();
+ delay=videobuf_time-now;
+ if(delay>=0.0){
+ /* got a good frame, not late, ready to break out */
+ videobuf_ready=1;
+ }else if(now-last_frame_time>=1.0){
+ /* display at least one frame per second, regardless */
+ videobuf_ready=1;
+ }else{
+ fprintf(stderr, "dropping frame %d (%.3fs behind)\n",
+ frameNum, -delay);
+ }
+ }else{
+ /* need more data */
+ break;
+ }
+ }
+
+ if(!hasdatatobuffer && !videobuf_ready && !audiobuf_ready){
+ isPlaying = 0;
+ playbackdone = 1;
+ }
+
+ /* if we're set for the next frame, sleep */
+ if((!theora_p || videobuf_ready) &&
+ (!vorbis_p || audiobuf_ready)){
+ int ticks = 1.0e3*(videobuf_time-get_time());
+ if(ticks>0)
+ SDL_Delay(ticks);
+ }
+
+ if(videobuf_ready){
+ /* time to write our cached frame */
+ video_write();
+ videobuf_ready=0;
+ last_frame_time=get_time();
+
+ /* if audio has not started (first frame) then start it */
+ if ((!isPlaying)&&(vorbis_p)){
+ start_audio();
+ isPlaying = 1;
+ }
+ }
+
+ /* HACK: always look for more audio data */
+ audiobuf_ready=0;
+
+ /* buffer compressed data every loop */
+ if(hasdatatobuffer){
+ hasdatatobuffer=buffer_data(&oy);
+ if(hasdatatobuffer==0){
+ printf("Ogg buffering stopped, end of file reached.\n");
+ }
+ }
+
+ if (ogg_sync_pageout(&oy,&og)>0){
+ queue_page(&og);
+ }
+
+ } /* playbackdone */
+
+ /* show number of video frames decoded */
+ printf( "\n");
+ printf( "Frames decoded: %d", frameNum );
+ if(skipNum)
+ printf( " (only %d shown)", frameNum-skipNum);
+ printf( "\n" );
+
+ /* tear it all down */
+ fclose( infile );
+
+ if(vorbis_p){
+ audio_close();
+
+ ogg_stream_clear(&vo);
+ vorbis_block_clear(&vb);
+ vorbis_dsp_clear(&vd);
+ vorbis_comment_clear(&vc);
+ vorbis_info_clear(&vi);
+ }
+ if(theora_p){
+ ogg_stream_clear(&to);
+ theora_clear(&td);
+ theora_comment_clear(&tc);
+ theora_info_clear(&ti);
+ }
+ ogg_sync_clear(&oy);
+
+ printf("\r "
+ "\nDone.\n");
+
+ SDL_Quit();
+
+ return(0);
+
+}
diff --git a/libs/libtheora-1.1/include/Makefile.am b/libs/libtheora-1.1/include/Makefile.am
new file mode 100644
index 00000000..4f369ef8
--- /dev/null
+++ b/libs/libtheora-1.1/include/Makefile.am
@@ -0,0 +1,3 @@
+## Process this file with automake to produce Makefile.in
+
+SUBDIRS = theora
diff --git a/libs/libtheora-1.1/include/theora/Makefile.am b/libs/libtheora-1.1/include/theora/Makefile.am
new file mode 100644
index 00000000..a917c6c6
--- /dev/null
+++ b/libs/libtheora-1.1/include/theora/Makefile.am
@@ -0,0 +1,7 @@
+## Process this file with automake to produce Makefile.in
+
+theoraincludedir = $(includedir)/theora
+
+theorainclude_HEADERS = theora.h theoradec.h theoraenc.h codec.h
+
+noinst_HEADERS = codec.h theoradec.h
diff --git a/libs/libtheora-1.1/include/theora/codec.h b/libs/libtheora-1.1/include/theora/codec.h
new file mode 100644
index 00000000..7d1f2652
--- /dev/null
+++ b/libs/libtheora-1.1/include/theora/codec.h
@@ -0,0 +1,591 @@
+/********************************************************************
+ * *
+ * THIS FILE IS PART OF THE OggTheora SOFTWARE CODEC SOURCE CODE. *
+ * USE, DISTRIBUTION AND REPRODUCTION OF THIS LIBRARY SOURCE IS *
+ * GOVERNED BY A BSD-STYLE SOURCE LICENSE INCLUDED WITH THIS SOURCE *
+ * IN 'COPYING'. PLEASE READ THESE TERMS BEFORE DISTRIBUTING. *
+ * *
+ * THE Theora SOURCE CODE IS COPYRIGHT (C) 2002-2009 *
+ * by the Xiph.Org Foundation http://www.xiph.org/ *
+ * *
+ ********************************************************************
+
+ function:
+ last mod: $Id: theora.h,v 1.8 2004/03/15 22:17:32 derf Exp $
+
+ ********************************************************************/
+
+/**\mainpage
+ *
+ * \section intro Introduction
+ *
+ * This is the documentation for libtheora C API.
+ * The current reference
+ * implementation for Theora, a free,
+ * patent-unencumbered video codec.
+ * Theora is derived from On2's VP3 codec with additional features and
+ * integration with Ogg multimedia formats by
+ * the Xiph.Org Foundation.
+ * Complete documentation of the format itself is available in
+ * the Theora
+ * specification.
+ *
+ * \subsection Organization
+ *
+ * The functions documented here are actually subdivided into three
+ * separate libraries:
+ * - libtheoraenc contains the encoder interface,
+ * described in \ref encfuncs.
+ * - libtheoradec contains the decoder interface and
+ * routines shared with the encoder.
+ * You must also link to this if you link to libtheoraenc.
+ * The routines in this library are described in \ref decfuncs and
+ * \ref basefuncs.
+ * - libtheora contains the \ref oldfuncs.
+ *
+ * New code should link to libtheoradec and, if using encoder
+ * features, libtheoraenc. Together these two export both
+ * the standard and the legacy API, so this is all that is needed by
+ * any code. The older libtheora library is provided just for
+ * compatibility with older build configurations.
+ *
+ * In general the recommended 1.x API symbols can be distinguished
+ * by their th_ or TH_ namespace prefix.
+ * The older, legacy API uses theora_ or OC_
+ * prefixes instead.
+ */
+
+/**\file
+ * The shared libtheoradec and libtheoraenc C API.
+ * You don't need to include this directly.*/
+
+#if !defined(_O_THEORA_CODEC_H_)
+# define _O_THEORA_CODEC_H_ (1)
+# include
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+
+
+/**\name Return codes*/
+/*@{*/
+/**An invalid pointer was provided.*/
+#define TH_EFAULT (-1)
+/**An invalid argument was provided.*/
+#define TH_EINVAL (-10)
+/**The contents of the header were incomplete, invalid, or unexpected.*/
+#define TH_EBADHEADER (-20)
+/**The header does not belong to a Theora stream.*/
+#define TH_ENOTFORMAT (-21)
+/**The bitstream version is too high.*/
+#define TH_EVERSION (-22)
+/**The specified function is not implemented.*/
+#define TH_EIMPL (-23)
+/**There were errors in the video data packet.*/
+#define TH_EBADPACKET (-24)
+/**The decoded packet represented a dropped frame.
+ The player can continue to display the current frame, as the contents of the
+ decoded frame buffer have not changed.*/
+#define TH_DUPFRAME (1)
+/*@}*/
+
+/**The currently defined color space tags.
+ * See the Theora
+ * specification, Chapter 4, for exact details on the meaning
+ * of each of these color spaces.*/
+typedef enum{
+ /**The color space was not specified at the encoder.
+ It may be conveyed by an external means.*/
+ TH_CS_UNSPECIFIED,
+ /**A color space designed for NTSC content.*/
+ TH_CS_ITU_REC_470M,
+ /**A color space designed for PAL/SECAM content.*/
+ TH_CS_ITU_REC_470BG,
+ /**The total number of currently defined color spaces.*/
+ TH_CS_NSPACES
+}th_colorspace;
+
+/**The currently defined pixel format tags.
+ * See the Theora
+ * specification, Section 4.4, for details on the precise sample
+ * locations.*/
+typedef enum{
+ /**Chroma decimation by 2 in both the X and Y directions (4:2:0).
+ The Cb and Cr chroma planes are half the width and half the
+ height of the luma plane.*/
+ TH_PF_420,
+ /**Currently reserved.*/
+ TH_PF_RSVD,
+ /**Chroma decimation by 2 in the X direction (4:2:2).
+ The Cb and Cr chroma planes are half the width of the luma plane, but full
+ height.*/
+ TH_PF_422,
+ /**No chroma decimation (4:4:4).
+ The Cb and Cr chroma planes are full width and full height.*/
+ TH_PF_444,
+ /**The total number of currently defined pixel formats.*/
+ TH_PF_NFORMATS
+}th_pixel_fmt;
+
+
+
+/**A buffer for a single color plane in an uncompressed image.
+ * This contains the image data in a left-to-right, top-down format.
+ * Each row of pixels is stored contiguously in memory, but successive
+ * rows need not be.
+ * Use \a stride to compute the offset of the next row.
+ * The encoder accepts both positive \a stride values (top-down in memory)
+ * and negative (bottom-up in memory).
+ * The decoder currently always generates images with positive strides.*/
+typedef struct{
+ /**The width of this plane.*/
+ int width;
+ /**The height of this plane.*/
+ int height;
+ /**The offset in bytes between successive rows.*/
+ int stride;
+ /**A pointer to the beginning of the first row.*/
+ unsigned char *data;
+}th_img_plane;
+
+/**A complete image buffer for an uncompressed frame.
+ * The chroma planes may be decimated by a factor of two in either
+ * direction, as indicated by th_info#pixel_fmt.
+ * The width and height of the Y' plane must be multiples of 16.
+ * They may need to be cropped for display, using the rectangle
+ * specified by th_info#pic_x, th_info#pic_y, th_info#pic_width,
+ * and th_info#pic_height.
+ * All samples are 8 bits.
+ * \note The term YUV often used to describe a colorspace is ambiguous.
+ * The exact parameters of the RGB to YUV conversion process aside, in
+ * many contexts the U and V channels actually have opposite meanings.
+ * To avoid this confusion, we are explicit: the name of the color
+ * channels are Y'CbCr, and they appear in that order, always.
+ * The prime symbol denotes that the Y channel is non-linear.
+ * Cb and Cr stand for "Chroma blue" and "Chroma red", respectively.*/
+typedef th_img_plane th_ycbcr_buffer[3];
+
+/**Theora bitstream information.
+ * This contains the basic playback parameters for a stream, and corresponds to
+ * the initial 'info' header packet.
+ * To initialize an encoder, the application fills in this structure and
+ * passes it to th_encode_alloc().
+ * A default encoding mode is chosen based on the values of the #quality and
+ * #target_bitrate fields.
+ * On decode, it is filled in by th_decode_headerin(), and then passed to
+ * th_decode_alloc().
+ *
+ * Encoded Theora frames must be a multiple of 16 in size;
+ * this is what the #frame_width and #frame_height members represent.
+ * To handle arbitrary picture sizes, a crop rectangle is specified in the
+ * #pic_x, #pic_y, #pic_width and #pic_height members.
+ *
+ * All frame buffers contain pointers to the full, padded frame.
+ * However, the current encoder will not reference pixels outside of
+ * the cropped picture region, and the application does not need to fill them
+ * in.
+ * The decoder will allocate storage for a full frame, but the
+ * application should not rely on the padding containing sensible
+ * data.
+ *
+ * It is also generally recommended that the offsets and sizes should still be
+ * multiples of 2 to avoid chroma sampling shifts when chroma is sub-sampled.
+ * See the Theora
+ * specification, Section 4.4, for more details.
+ *
+ * Frame rate, in frames per second, is stored as a rational fraction, as is
+ * the pixel aspect ratio.
+ * Note that this refers to the aspect ratio of the individual pixels, not of
+ * the overall frame itself.
+ * The frame aspect ratio can be computed from pixel aspect ratio using the
+ * image dimensions.*/
+typedef struct{
+ /**\name Theora version
+ * Bitstream version information.*/
+ /*@{*/
+ unsigned char version_major;
+ unsigned char version_minor;
+ unsigned char version_subminor;
+ /*@}*/
+ /**The encoded frame width.
+ * This must be a multiple of 16, and less than 1048576.*/
+ ogg_uint32_t frame_width;
+ /**The encoded frame height.
+ * This must be a multiple of 16, and less than 1048576.*/
+ ogg_uint32_t frame_height;
+ /**The displayed picture width.
+ * This must be no larger than width.*/
+ ogg_uint32_t pic_width;
+ /**The displayed picture height.
+ * This must be no larger than height.*/
+ ogg_uint32_t pic_height;
+ /**The X offset of the displayed picture.
+ * This must be no larger than #frame_width-#pic_width or 255, whichever is
+ * smaller.*/
+ ogg_uint32_t pic_x;
+ /**The Y offset of the displayed picture.
+ * This must be no larger than #frame_height-#pic_height, and
+ * #frame_height-#pic_height-#pic_y must be no larger than 255.
+ * This slightly funny restriction is due to the fact that the offset is
+ * specified from the top of the image for consistency with the standard
+ * graphics left-handed coordinate system used throughout this API, while
+ * it is stored in the encoded stream as an offset from the bottom.*/
+ ogg_uint32_t pic_y;
+ /**\name Frame rate
+ * The frame rate, as a fraction.
+ * If either is 0, the frame rate is undefined.*/
+ /*@{*/
+ ogg_uint32_t fps_numerator;
+ ogg_uint32_t fps_denominator;
+ /*@}*/
+ /**\name Aspect ratio
+ * The aspect ratio of the pixels.
+ * If either value is zero, the aspect ratio is undefined.
+ * If not specified by any external means, 1:1 should be assumed.
+ * The aspect ratio of the full picture can be computed as
+ * \code
+ * aspect_numerator*pic_width/(aspect_denominator*pic_height).
+ * \endcode */
+ /*@{*/
+ ogg_uint32_t aspect_numerator;
+ ogg_uint32_t aspect_denominator;
+ /*@}*/
+ /**The color space.*/
+ th_colorspace colorspace;
+ /**The pixel format.*/
+ th_pixel_fmt pixel_fmt;
+ /**The target bit-rate in bits per second.
+ If initializing an encoder with this struct, set this field to a non-zero
+ value to activate CBR encoding by default.*/
+ int target_bitrate;
+ /**The target quality level.
+ Valid values range from 0 to 63, inclusive, with higher values giving
+ higher quality.
+ If initializing an encoder with this struct, and #target_bitrate is set
+ to zero, VBR encoding at this quality will be activated by default.*/
+ /*Currently this is set so that a qi of 0 corresponds to distortions of 24
+ times the JND, and each increase by 16 halves that value.
+ This gives us fine discrimination at low qualities, yet effective rate
+ control at high qualities.
+ The qi value 63 is special, however.
+ For this, the highest quality, we use one half of a JND for our threshold.
+ Due to the lower bounds placed on allowable quantizers in Theora, we will
+ not actually be able to achieve quality this good, but this should
+ provide as close to visually lossless quality as Theora is capable of.
+ We could lift the quantizer restrictions without breaking VP3.1
+ compatibility, but this would result in quantized coefficients that are
+ too large for the current bitstream to be able to store.
+ We'd have to redesign the token syntax to store these large coefficients,
+ which would make transcoding complex.*/
+ int quality;
+ /**The amount to shift to extract the last keyframe number from the granule
+ * position.
+ * This can be at most 31.
+ * th_info_init() will set this to a default value (currently 6,
+ * which is good for streaming applications), but you can set it to 0 to
+ * make every frame a keyframe.
+ * The maximum distance between key frames is
+ * 1<<#keyframe_granule_shift.
+ * The keyframe frequency can be more finely controlled with
+ * #TH_ENCCTL_SET_KEYFRAME_FREQUENCY_FORCE, which can also be adjusted
+ * during encoding (for example, to force the next frame to be a keyframe),
+ * but it cannot be set larger than the amount permitted by this field after
+ * the headers have been output.*/
+ int keyframe_granule_shift;
+}th_info;
+
+/**The comment information.
+ *
+ * This structure holds the in-stream metadata corresponding to
+ * the 'comment' header packet.
+ * The comment header is meant to be used much like someone jotting a quick
+ * note on the label of a video.
+ * It should be a short, to the point text note that can be more than a couple
+ * words, but not more than a short paragraph.
+ *
+ * The metadata is stored as a series of (tag, value) pairs, in
+ * length-encoded string vectors.
+ * The first occurrence of the '=' character delimits the tag and value.
+ * A particular tag may occur more than once, and order is significant.
+ * The character set encoding for the strings is always UTF-8, but the tag
+ * names are limited to ASCII, and treated as case-insensitive.
+ * See the Theora
+ * specification, Section 6.3.3 for details.
+ *
+ * In filling in this structure, th_decode_headerin() will null-terminate
+ * the user_comment strings for safety.
+ * However, the bitstream format itself treats them as 8-bit clean vectors,
+ * possibly containing null characters, and so the length array should be
+ * treated as their authoritative length.
+ */
+typedef struct th_comment{
+ /**The array of comment string vectors.*/
+ char **user_comments;
+ /**An array of the corresponding length of each vector, in bytes.*/
+ int *comment_lengths;
+ /**The total number of comment strings.*/
+ int comments;
+ /**The null-terminated vendor string.
+ This identifies the software used to encode the stream.*/
+ char *vendor;
+}th_comment;
+
+
+
+/**A single base matrix.*/
+typedef unsigned char th_quant_base[64];
+
+/**A set of \a qi ranges.*/
+typedef struct{
+ /**The number of ranges in the set.*/
+ int nranges;
+ /**The size of each of the #nranges ranges.
+ These must sum to 63.*/
+ const int *sizes;
+ /**#nranges +1 base matrices.
+ Matrices \a i and i+1 form the endpoints of range \a i.*/
+ const th_quant_base *base_matrices;
+}th_quant_ranges;
+
+/**A complete set of quantization parameters.
+ The quantizer for each coefficient is calculated as:
+ \code
+ Q=MAX(MIN(qmin[qti][ci!=0],scale[ci!=0][qi]*base[qti][pli][qi][ci]/100),
+ 1024).
+ \endcode
+
+ \a qti is the quantization type index: 0 for intra, 1 for inter.
+ ci!=0 is 0 for the DC coefficient and 1 for AC coefficients.
+ \a qi is the quality index, ranging between 0 (low quality) and 63 (high
+ quality).
+ \a pli is the color plane index: 0 for Y', 1 for Cb, 2 for Cr.
+ \a ci is the DCT coefficient index.
+ Coefficient indices correspond to the normal 2D DCT block
+ ordering--row-major with low frequencies first--\em not zig-zag order.
+
+ Minimum quantizers are constant, and are given by:
+ \code
+ qmin[2][2]={{4,2},{8,4}}.
+ \endcode
+
+ Parameters that can be stored in the bitstream are as follows:
+ - The two scale matrices ac_scale and dc_scale.
+ \code
+ scale[2][64]={dc_scale,ac_scale}.
+ \endcode
+ - The base matrices for each \a qi, \a qti and \a pli (up to 384 in all).
+ In order to avoid storing a full 384 base matrices, only a sparse set of
+ matrices are stored, and the rest are linearly interpolated.
+ This is done as follows.
+ For each \a qti and \a pli, a series of \a n \a qi ranges is defined.
+ The size of each \a qi range can vary arbitrarily, but they must sum to
+ 63.
+ Then, n+1 matrices are specified, one for each endpoint of the
+ ranges.
+ For interpolation purposes, each range's endpoints are the first \a qi
+ value it contains and one past the last \a qi value it contains.
+ Fractional values are rounded to the nearest integer, with ties rounded
+ away from zero.
+
+ Base matrices are stored by reference, so if the same matrices are used
+ multiple times, they will only appear once in the bitstream.
+ The bitstream is also capable of omitting an entire set of ranges and
+ its associated matrices if they are the same as either the previous
+ set (indexed in row-major order) or if the inter set is the same as the
+ intra set.
+
+ - Loop filter limit values.
+ The same limits are used for the loop filter in all color planes, despite
+ potentially differing levels of quantization in each.
+
+ For the current encoder, scale[ci!=0][qi] must be no greater
+ than scale[ci!=0][qi-1] and base[qti][pli][qi][ci] must
+ be no greater than base[qti][pli][qi-1][ci].
+ These two conditions ensure that the actual quantizer for a given \a qti,
+ \a pli, and \a ci does not increase as \a qi increases.
+ This is not required by the decoder.*/
+typedef struct{
+ /**The DC scaling factors.*/
+ ogg_uint16_t dc_scale[64];
+ /**The AC scaling factors.*/
+ ogg_uint16_t ac_scale[64];
+ /**The loop filter limit values.*/
+ unsigned char loop_filter_limits[64];
+ /**The \a qi ranges for each \a ci and \a pli.*/
+ th_quant_ranges qi_ranges[2][3];
+}th_quant_info;
+
+
+
+/**The number of Huffman tables used by Theora.*/
+#define TH_NHUFFMAN_TABLES (80)
+/**The number of DCT token values in each table.*/
+#define TH_NDCT_TOKENS (32)
+
+/**A Huffman code for a Theora DCT token.
+ * Each set of Huffman codes in a given table must form a complete, prefix-free
+ * code.
+ * There is no requirement that all the tokens in a table have a valid code,
+ * but the current encoder is not optimized to take advantage of this.
+ * If each of the five grouops of 16 tables does not contain at least one table
+ * with a code for every token, then the encoder may fail to encode certain
+ * frames.
+ * The complete table in the first group of 16 does not have to be in the same
+ * place as the complete table in the other groups, but the complete tables in
+ * the remaining four groups must all be in the same place.*/
+typedef struct{
+ /**The bit pattern for the code, with the LSbit of the pattern aligned in
+ * the LSbit of the word.*/
+ ogg_uint32_t pattern;
+ /**The number of bits in the code.
+ * This must be between 0 and 32, inclusive.*/
+ int nbits;
+}th_huff_code;
+
+
+
+/**\defgroup basefuncs Functions Shared by Encode and Decode*/
+/*@{*/
+/**\name Basic shared functions*/
+/*@{*/
+/**Retrieves a human-readable string to identify the library vendor and
+ * version.
+ * \return the version string.*/
+extern const char *th_version_string(void);
+/**Retrieves the library version number.
+ * This is the highest bitstream version that the encoder library will produce,
+ * or that the decoder library can decode.
+ * This number is composed of a 16-bit major version, 8-bit minor version
+ * and 8 bit sub-version, composed as follows:
+ * \code
+ * (VERSION_MAJOR<<16)+(VERSION_MINOR<<8)+(VERSION_SUBMINOR)
+ * \endcode
+ * \return the version number.*/
+extern ogg_uint32_t th_version_number(void);
+/**Converts a granule position to an absolute frame index, starting at
+ * 0.
+ * The granule position is interpreted in the context of a given
+ * #th_enc_ctx or #th_dec_ctx handle (either will suffice).
+ * \param _encdec A previously allocated #th_enc_ctx or #th_dec_ctx
+ * handle.
+ * \param _granpos The granule position to convert.
+ * \returns The absolute frame index corresponding to \a _granpos.
+ * \retval -1 The given granule position was invalid (i.e. negative).*/
+extern ogg_int64_t th_granule_frame(void *_encdec,ogg_int64_t _granpos);
+/**Converts a granule position to an absolute time in seconds.
+ * The granule position is interpreted in the context of a given
+ * #th_enc_ctx or #th_dec_ctx handle (either will suffice).
+ * \param _encdec A previously allocated #th_enc_ctx or #th_dec_ctx
+ * handle.
+ * \param _granpos The granule position to convert.
+ * \return The absolute time in seconds corresponding to \a _granpos.
+ * This is the "end time" for the frame, or the latest time it should
+ * be displayed.
+ * It is not the presentation time.
+ * \retval -1 The given granule position was invalid (i.e. negative).*/
+extern double th_granule_time(void *_encdec,ogg_int64_t _granpos);
+/**Determines whether a Theora packet is a header or not.
+ * This function does no verification beyond checking the packet type bit, so
+ * it should not be used for bitstream identification; use
+ * th_decode_headerin() for that.
+ * As per the Theora specification, an empty (0-byte) packet is treated as a
+ * data packet (a delta frame with no coded blocks).
+ * \param _op An ogg_packet containing encoded Theora data.
+ * \retval 1 The packet is a header packet
+ * \retval 0 The packet is a video data packet.*/
+extern int th_packet_isheader(ogg_packet *_op);
+/**Determines whether a theora packet is a key frame or not.
+ * This function does no verification beyond checking the packet type and
+ * key frame bits, so it should not be used for bitstream identification; use
+ * th_decode_headerin() for that.
+ * As per the Theora specification, an empty (0-byte) packet is treated as a
+ * delta frame (with no coded blocks).
+ * \param _op An ogg_packet containing encoded Theora data.
+ * \retval 1 The packet contains a key frame.
+ * \retval 0 The packet contains a delta frame.
+ * \retval -1 The packet is not a video data packet.*/
+extern int th_packet_iskeyframe(ogg_packet *_op);
+/*@}*/
+
+
+/**\name Functions for manipulating header data*/
+/*@{*/
+/**Initializes a th_info structure.
+ * This should be called on a freshly allocated #th_info structure before
+ * attempting to use it.
+ * \param _info The #th_info struct to initialize.*/
+extern void th_info_init(th_info *_info);
+/**Clears a #th_info structure.
+ * This should be called on a #th_info structure after it is no longer
+ * needed.
+ * \param _info The #th_info struct to clear.*/
+extern void th_info_clear(th_info *_info);
+
+/**Initialize a #th_comment structure.
+ * This should be called on a freshly allocated #th_comment structure
+ * before attempting to use it.
+ * \param _tc The #th_comment struct to initialize.*/
+extern void th_comment_init(th_comment *_tc);
+/**Add a comment to an initialized #th_comment structure.
+ * \note Neither th_comment_add() nor th_comment_add_tag() support
+ * comments containing null values, although the bitstream format does
+ * support them.
+ * To add such comments you will need to manipulate the #th_comment
+ * structure directly.
+ * \param _tc The #th_comment struct to add the comment to.
+ * \param _comment Must be a null-terminated UTF-8 string containing the
+ * comment in "TAG=the value" form.*/
+extern void th_comment_add(th_comment *_tc, char *_comment);
+/**Add a comment to an initialized #th_comment structure.
+ * \note Neither th_comment_add() nor th_comment_add_tag() support
+ * comments containing null values, although the bitstream format does
+ * support them.
+ * To add such comments you will need to manipulate the #th_comment
+ * structure directly.
+ * \param _tc The #th_comment struct to add the comment to.
+ * \param _tag A null-terminated string containing the tag associated with
+ * the comment.
+ * \param _val The corresponding value as a null-terminated string.*/
+extern void th_comment_add_tag(th_comment *_tc,char *_tag,char *_val);
+/**Look up a comment value by its tag.
+ * \param _tc An initialized #th_comment structure.
+ * \param _tag The tag to look up.
+ * \param _count The instance of the tag.
+ * The same tag can appear multiple times, each with a distinct
+ * value, so an index is required to retrieve them all.
+ * The order in which these values appear is significant and
+ * should be preserved.
+ * Use th_comment_query_count() to get the legal range for
+ * the \a _count parameter.
+ * \return A pointer to the queried tag's value.
+ * This points directly to data in the #th_comment structure.
+ * It should not be modified or freed by the application, and
+ * modifications to the structure may invalidate the pointer.
+ * \retval NULL If no matching tag is found.*/
+extern char *th_comment_query(th_comment *_tc,char *_tag,int _count);
+/**Look up the number of instances of a tag.
+ * Call this first when querying for a specific tag and then iterate over the
+ * number of instances with separate calls to th_comment_query() to
+ * retrieve all the values for that tag in order.
+ * \param _tc An initialized #th_comment structure.
+ * \param _tag The tag to look up.
+ * \return The number on instances of this particular tag.*/
+extern int th_comment_query_count(th_comment *_tc,char *_tag);
+/**Clears a #th_comment structure.
+ * This should be called on a #th_comment structure after it is no longer
+ * needed.
+ * It will free all memory used by the structure members.
+ * \param _tc The #th_comment struct to clear.*/
+extern void th_comment_clear(th_comment *_tc);
+/*@}*/
+/*@}*/
+
+
+
+#if defined(__cplusplus)
+}
+#endif
+
+#endif
diff --git a/libs/libtheora-1.1/include/theora/theora.h b/libs/libtheora-1.1/include/theora/theora.h
new file mode 100644
index 00000000..a9b0b010
--- /dev/null
+++ b/libs/libtheora-1.1/include/theora/theora.h
@@ -0,0 +1,784 @@
+/********************************************************************
+ * *
+ * THIS FILE IS PART OF THE OggTheora SOFTWARE CODEC SOURCE CODE. *
+ * USE, DISTRIBUTION AND REPRODUCTION OF THIS LIBRARY SOURCE IS *
+ * GOVERNED BY A BSD-STYLE SOURCE LICENSE INCLUDED WITH THIS SOURCE *
+ * IN 'COPYING'. PLEASE READ THESE TERMS BEFORE DISTRIBUTING. *
+ * *
+ * THE Theora SOURCE CODE IS COPYRIGHT (C) 2002-2009 *
+ * by the Xiph.Org Foundation http://www.xiph.org/ *
+ * *
+ ********************************************************************
+
+ function:
+ last mod: $Id: theora.h,v 1.17 2003/12/06 18:06:19 arc Exp $
+
+ ********************************************************************/
+
+#ifndef _O_THEORA_H_
+#define _O_THEORA_H_
+
+#ifdef __cplusplus
+extern "C"
+{
+#endif /* __cplusplus */
+
+#include /* for size_t */
+
+#include
+
+/** \file
+ * The libtheora pre-1.0 legacy C API.
+ *
+ * \ingroup oldfuncs
+ *
+ * \section intro Introduction
+ *
+ * This is the documentation for the libtheora legacy C API, declared in
+ * the theora.h header, which describes the old interface used before
+ * the 1.0 release. This API was widely deployed for several years and
+ * remains supported, but for new code we recommend the cleaner API
+ * declared in theoradec.h and theoraenc.h.
+ *
+ * libtheora is the reference implementation for
+ * Theora, a free video codec.
+ * Theora is derived from On2's VP3 codec with improved integration with
+ * Ogg multimedia formats by Xiph.Org.
+ *
+ * \section overview Overview
+ *
+ * This library will both decode and encode theora packets to/from raw YUV
+ * frames. In either case, the packets will most likely either come from or
+ * need to be embedded in an Ogg stream. Use
+ * libogg or
+ * liboggz
+ * to extract/package these packets.
+ *
+ * \section decoding Decoding Process
+ *
+ * Decoding can be separated into the following steps:
+ * -# initialise theora_info and theora_comment structures using
+ * theora_info_init() and theora_comment_init():
+ \verbatim
+ theora_info info;
+ theora_comment comment;
+
+ theora_info_init(&info);
+ theora_comment_init(&comment);
+ \endverbatim
+ * -# retrieve header packets from Ogg stream (there should be 3) and decode
+ * into theora_info and theora_comment structures using
+ * theora_decode_header(). See \ref identification for more information on
+ * identifying which packets are theora packets.
+ \verbatim
+ int i;
+ for (i = 0; i < 3; i++)
+ {
+ (get a theora packet "op" from the Ogg stream)
+ theora_decode_header(&info, &comment, op);
+ }
+ \endverbatim
+ * -# initialise the decoder based on the information retrieved into the
+ * theora_info struct by theora_decode_header(). You will need a
+ * theora_state struct.
+ \verbatim
+ theora_state state;
+
+ theora_decode_init(&state, &info);
+ \endverbatim
+ * -# pass in packets and retrieve decoded frames! See the yuv_buffer
+ * documentation for information on how to retrieve raw YUV data.
+ \verbatim
+ yuf_buffer buffer;
+ while (last packet was not e_o_s) {
+ (get a theora packet "op" from the Ogg stream)
+ theora_decode_packetin(&state, op);
+ theora_decode_YUVout(&state, &buffer);
+ }
+ \endverbatim
+ *
+ *
+ * \subsection identification Identifying Theora Packets
+ *
+ * All streams inside an Ogg file have a unique serial_no attached to the
+ * stream. Typically, you will want to
+ * - retrieve the serial_no for each b_o_s (beginning of stream) page
+ * encountered within the Ogg file;
+ * - test the first (only) packet on that page to determine if it is a theora
+ * packet;
+ * - once you have found a theora b_o_s page then use the retrieved serial_no
+ * to identify future packets belonging to the same theora stream.
+ *
+ * Note that you \e cannot use theora_packet_isheader() to determine if a
+ * packet is a theora packet or not, as this function does not perform any
+ * checking beyond whether a header bit is present. Instead, use the
+ * theora_decode_header() function and check the return value; or examine the
+ * header bytes at the beginning of the Ogg page.
+ */
+
+
+/** \defgroup oldfuncs Legacy pre-1.0 C API */
+/* @{ */
+
+/**
+ * A YUV buffer for passing uncompressed frames to and from the codec.
+ * This holds a Y'CbCr frame in planar format. The CbCr planes can be
+ * subsampled and have their own separate dimensions and row stride
+ * offsets. Note that the strides may be negative in some
+ * configurations. For theora the width and height of the largest plane
+ * must be a multiple of 16. The actual meaningful picture size and
+ * offset are stored in the theora_info structure; frames returned by
+ * the decoder may need to be cropped for display.
+ *
+ * All samples are 8 bits. Within each plane samples are ordered by
+ * row from the top of the frame to the bottom. Within each row samples
+ * are ordered from left to right.
+ *
+ * During decode, the yuv_buffer struct is allocated by the user, but all
+ * fields (including luma and chroma pointers) are filled by the library.
+ * These pointers address library-internal memory and their contents should
+ * not be modified.
+ *
+ * Conversely, during encode the user allocates the struct and fills out all
+ * fields. The user also manages the data addressed by the luma and chroma
+ * pointers. See the encoder_example.c and dump_video.c example files in
+ * theora/examples/ for more information.
+ */
+typedef struct {
+ int y_width; /**< Width of the Y' luminance plane */
+ int y_height; /**< Height of the luminance plane */
+ int y_stride; /**< Offset in bytes between successive rows */
+
+ int uv_width; /**< Width of the Cb and Cr chroma planes */
+ int uv_height; /**< Height of the chroma planes */
+ int uv_stride; /**< Offset between successive chroma rows */
+ unsigned char *y; /**< Pointer to start of luminance data */
+ unsigned char *u; /**< Pointer to start of Cb data */
+ unsigned char *v; /**< Pointer to start of Cr data */
+
+} yuv_buffer;
+
+/**
+ * A Colorspace.
+ */
+typedef enum {
+ OC_CS_UNSPECIFIED, /**< The colorspace is unknown or unspecified */
+ OC_CS_ITU_REC_470M, /**< This is the best option for 'NTSC' content */
+ OC_CS_ITU_REC_470BG, /**< This is the best option for 'PAL' content */
+ OC_CS_NSPACES /**< This marks the end of the defined colorspaces */
+} theora_colorspace;
+
+/**
+ * A Chroma subsampling
+ *
+ * These enumerate the available chroma subsampling options supported
+ * by the theora format. See Section 4.4 of the specification for
+ * exact definitions.
+ */
+typedef enum {
+ OC_PF_420, /**< Chroma subsampling by 2 in each direction (4:2:0) */
+ OC_PF_RSVD, /**< Reserved value */
+ OC_PF_422, /**< Horizonatal chroma subsampling by 2 (4:2:2) */
+ OC_PF_444 /**< No chroma subsampling at all (4:4:4) */
+} theora_pixelformat;
+
+/**
+ * Theora bitstream info.
+ * Contains the basic playback parameters for a stream,
+ * corresponding to the initial 'info' header packet.
+ *
+ * Encoded theora frames must be a multiple of 16 in width and height.
+ * To handle other frame sizes, a crop rectangle is specified in
+ * frame_height and frame_width, offset_x and * offset_y. The offset
+ * and size should still be a multiple of 2 to avoid chroma sampling
+ * shifts. Offset values in this structure are measured from the
+ * upper left of the image.
+ *
+ * Frame rate, in frames per second, is stored as a rational
+ * fraction. Aspect ratio is also stored as a rational fraction, and
+ * refers to the aspect ratio of the frame pixels, not of the
+ * overall frame itself.
+ *
+ * See
+ * examples/encoder_example.c for usage examples of the
+ * other paramters and good default settings for the encoder parameters.
+ */
+typedef struct {
+ ogg_uint32_t width; /**< encoded frame width */
+ ogg_uint32_t height; /**< encoded frame height */
+ ogg_uint32_t frame_width; /**< display frame width */
+ ogg_uint32_t frame_height; /**< display frame height */
+ ogg_uint32_t offset_x; /**< horizontal offset of the displayed frame */
+ ogg_uint32_t offset_y; /**< vertical offset of the displayed frame */
+ ogg_uint32_t fps_numerator; /**< frame rate numerator **/
+ ogg_uint32_t fps_denominator; /**< frame rate denominator **/
+ ogg_uint32_t aspect_numerator; /**< pixel aspect ratio numerator */
+ ogg_uint32_t aspect_denominator; /**< pixel aspect ratio denominator */
+ theora_colorspace colorspace; /**< colorspace */
+ int target_bitrate; /**< nominal bitrate in bits per second */
+ int quality; /**< Nominal quality setting, 0-63 */
+ int quick_p; /**< Quick encode/decode */
+
+ /* decode only */
+ unsigned char version_major;
+ unsigned char version_minor;
+ unsigned char version_subminor;
+
+ void *codec_setup;
+
+ /* encode only */
+ int dropframes_p;
+ int keyframe_auto_p;
+ ogg_uint32_t keyframe_frequency;
+ ogg_uint32_t keyframe_frequency_force; /* also used for decode init to
+ get granpos shift correct */
+ ogg_uint32_t keyframe_data_target_bitrate;
+ ogg_int32_t keyframe_auto_threshold;
+ ogg_uint32_t keyframe_mindistance;
+ ogg_int32_t noise_sensitivity;
+ ogg_int32_t sharpness;
+
+ theora_pixelformat pixelformat; /**< chroma subsampling mode to expect */
+
+} theora_info;
+
+/** Codec internal state and context.
+ */
+typedef struct{
+ theora_info *i;
+ ogg_int64_t granulepos;
+
+ void *internal_encode;
+ void *internal_decode;
+
+} theora_state;
+
+/**
+ * Comment header metadata.
+ *
+ * This structure holds the in-stream metadata corresponding to
+ * the 'comment' header packet.
+ *
+ * Meta data is stored as a series of (tag, value) pairs, in
+ * length-encoded string vectors. The first occurence of the
+ * '=' character delimits the tag and value. A particular tag
+ * may occur more than once. The character set encoding for
+ * the strings is always UTF-8, but the tag names are limited
+ * to case-insensitive ASCII. See the spec for details.
+ *
+ * In filling in this structure, theora_decode_header() will
+ * null-terminate the user_comment strings for safety. However,
+ * the bitstream format itself treats them as 8-bit clean,
+ * and so the length array should be treated as authoritative
+ * for their length.
+ */
+typedef struct theora_comment{
+ char **user_comments; /**< An array of comment string vectors */
+ int *comment_lengths; /**< An array of corresponding string vector lengths in bytes */
+ int comments; /**< The total number of comment string vectors */
+ char *vendor; /**< The vendor string identifying the encoder, null terminated */
+
+} theora_comment;
+
+
+/**\name theora_control() codes */
+/* \anchor decctlcodes_old
+ * These are the available request codes for theora_control()
+ * when called with a decoder instance.
+ * By convention decoder control codes are odd, to distinguish
+ * them from \ref encctlcodes_old "encoder control codes" which
+ * are even.
+ *
+ * Note that since the 1.0 release, both the legacy and the final
+ * implementation accept all the same control codes, but only the
+ * final API declares the newer codes.
+ *
+ * Keep any experimental or vendor-specific values above \c 0x8000.*/
+
+/*@{*/
+
+/**Get the maximum post-processing level.
+ * The decoder supports a post-processing filter that can improve
+ * the appearance of the decoded images. This returns the highest
+ * level setting for this post-processor, corresponding to maximum
+ * improvement and computational expense.
+ */
+#define TH_DECCTL_GET_PPLEVEL_MAX (1)
+
+/**Set the post-processing level.
+ * Sets the level of post-processing to use when decoding the
+ * compressed stream. This must be a value between zero (off)
+ * and the maximum returned by TH_DECCTL_GET_PPLEVEL_MAX.
+ */
+#define TH_DECCTL_SET_PPLEVEL (3)
+
+/**Sets the maximum distance between key frames.
+ * This can be changed during an encode, but will be bounded by
+ * 1<.
+ * If it is set before encoding begins, th_info#keyframe_granule_shift will
+ * be enlarged appropriately.
+ *
+ * \param[in] buf ogg_uint32_t: The maximum distance between key
+ * frames.
+ * \param[out] buf ogg_uint32_t: The actual maximum distance set.
+ * \retval OC_FAULT \a theora_state or \a buf is NULL.
+ * \retval OC_EINVAL \a buf_sz is not sizeof(ogg_uint32_t).
+ * \retval OC_IMPL Not supported by this implementation.*/
+#define TH_ENCCTL_SET_KEYFRAME_FREQUENCY_FORCE (4)
+
+/**Set the granule position.
+ * Call this after a seek, to update the internal granulepos
+ * in the decoder, to insure that subsequent frames are marked
+ * properly. If you track timestamps yourself and do not use
+ * the granule postion returned by the decoder, then you do
+ * not need to use this control.
+ */
+#define TH_DECCTL_SET_GRANPOS (5)
+
+/**\anchor encctlcodes_old */
+
+/**Sets the quantization parameters to use.
+ * The parameters are copied, not stored by reference, so they can be freed
+ * after this call.
+ * NULL may be specified to revert to the default parameters.
+ *
+ * \param[in] buf #th_quant_info
+ * \retval OC_FAULT \a theora_state is NULL.
+ * \retval OC_EINVAL Encoding has already begun, the quantization parameters
+ * are not acceptable to this version of the encoder,
+ * \a buf is NULL and \a buf_sz is not zero,
+ * or \a buf is non-NULL and \a buf_sz is
+ * not sizeof(#th_quant_info).
+ * \retval OC_IMPL Not supported by this implementation.*/
+#define TH_ENCCTL_SET_QUANT_PARAMS (2)
+
+/**Disables any encoder features that would prevent lossless transcoding back
+ * to VP3.
+ * This primarily means disabling block-level QI values and not using 4MV mode
+ * when any of the luma blocks in a macro block are not coded.
+ * It also includes using the VP3 quantization tables and Huffman codes; if you
+ * set them explicitly after calling this function, the resulting stream will
+ * not be VP3-compatible.
+ * If you enable VP3-compatibility when encoding 4:2:2 or 4:4:4 source
+ * material, or when using a picture region smaller than the full frame (e.g.
+ * a non-multiple-of-16 width or height), then non-VP3 bitstream features will
+ * still be disabled, but the stream will still not be VP3-compatible, as VP3
+ * was not capable of encoding such formats.
+ * If you call this after encoding has already begun, then the quantization
+ * tables and codebooks cannot be changed, but the frame-level features will
+ * be enabled or disabled as requested.
+ *
+ * \param[in] buf int: a non-zero value to enable VP3 compatibility,
+ * or 0 to disable it (the default).
+ * \param[out] buf int: 1 if all bitstream features required for
+ * VP3-compatibility could be set, and 0 otherwise.
+ * The latter will be returned if the pixel format is not
+ * 4:2:0, the picture region is smaller than the full frame,
+ * or if encoding has begun, preventing the quantization
+ * tables and codebooks from being set.
+ * \retval OC_FAULT \a theora_state or \a buf is NULL.
+ * \retval OC_EINVAL \a buf_sz is not sizeof(int).
+ * \retval OC_IMPL Not supported by this implementation.*/
+#define TH_ENCCTL_SET_VP3_COMPATIBLE (10)
+
+/**Gets the maximum speed level.
+ * Higher speed levels favor quicker encoding over better quality per bit.
+ * Depending on the encoding mode, and the internal algorithms used, quality
+ * may actually improve, but in this case bitrate will also likely increase.
+ * In any case, overall rate/distortion performance will probably decrease.
+ * The maximum value, and the meaning of each value, may change depending on
+ * the current encoding mode (VBR vs. CQI, etc.).
+ *
+ * \param[out] buf int: The maximum encoding speed level.
+ * \retval OC_FAULT \a theora_state or \a buf is NULL.
+ * \retval OC_EINVAL \a buf_sz is not sizeof(int).
+ * \retval OC_IMPL Not supported by this implementation in the current
+ * encoding mode.*/
+#define TH_ENCCTL_GET_SPLEVEL_MAX (12)
+
+/**Sets the speed level.
+ * By default a speed value of 1 is used.
+ *
+ * \param[in] buf int: The new encoding speed level.
+ * 0 is slowest, larger values use less CPU.
+ * \retval OC_FAULT \a theora_state or \a buf is NULL.
+ * \retval OC_EINVAL \a buf_sz is not sizeof(int), or the
+ * encoding speed level is out of bounds.
+ * The maximum encoding speed level may be
+ * implementation- and encoding mode-specific, and can be
+ * obtained via #TH_ENCCTL_GET_SPLEVEL_MAX.
+ * \retval OC_IMPL Not supported by this implementation in the current
+ * encoding mode.*/
+#define TH_ENCCTL_SET_SPLEVEL (14)
+
+/*@}*/
+
+#define OC_FAULT -1 /**< General failure */
+#define OC_EINVAL -10 /**< Library encountered invalid internal data */
+#define OC_DISABLED -11 /**< Requested action is disabled */
+#define OC_BADHEADER -20 /**< Header packet was corrupt/invalid */
+#define OC_NOTFORMAT -21 /**< Packet is not a theora packet */
+#define OC_VERSION -22 /**< Bitstream version is not handled */
+#define OC_IMPL -23 /**< Feature or action not implemented */
+#define OC_BADPACKET -24 /**< Packet is corrupt */
+#define OC_NEWPACKET -25 /**< Packet is an (ignorable) unhandled extension */
+#define OC_DUPFRAME 1 /**< Packet is a dropped frame */
+
+/**
+ * Retrieve a human-readable string to identify the encoder vendor and version.
+ * \returns A version string.
+ */
+extern const char *theora_version_string(void);
+
+/**
+ * Retrieve a 32-bit version number.
+ * This number is composed of a 16-bit major version, 8-bit minor version
+ * and 8 bit sub-version, composed as follows:
+
+* \returns The version number.
+*/
+extern ogg_uint32_t theora_version_number(void);
+
+/**
+ * Initialize the theora encoder.
+ * \param th The theora_state handle to initialize for encoding.
+ * \param ti A theora_info struct filled with the desired encoding parameters.
+ * \retval 0 Success
+ */
+extern int theora_encode_init(theora_state *th, theora_info *ti);
+
+/**
+ * Submit a YUV buffer to the theora encoder.
+ * \param t A theora_state handle previously initialized for encoding.
+ * \param yuv A buffer of YUV data to encode. Note that both the yuv_buffer
+ * struct and the luma/chroma buffers within should be allocated by
+ * the user.
+ * \retval OC_EINVAL Encoder is not ready, or is finished.
+ * \retval -1 The size of the given frame differs from those previously input
+ * \retval 0 Success
+ */
+extern int theora_encode_YUVin(theora_state *t, yuv_buffer *yuv);
+
+/**
+ * Request the next packet of encoded video.
+ * The encoded data is placed in a user-provided ogg_packet structure.
+ * \param t A theora_state handle previously initialized for encoding.
+ * \param last_p whether this is the last packet the encoder should produce.
+ * \param op An ogg_packet structure to fill. libtheora will set all
+ * elements of this structure, including a pointer to encoded
+ * data. The memory for the encoded data is owned by libtheora.
+ * \retval 0 No internal storage exists OR no packet is ready
+ * \retval -1 The encoding process has completed
+ * \retval 1 Success
+ */
+extern int theora_encode_packetout( theora_state *t, int last_p,
+ ogg_packet *op);
+
+/**
+ * Request a packet containing the initial header.
+ * A pointer to the header data is placed in a user-provided ogg_packet
+ * structure.
+ * \param t A theora_state handle previously initialized for encoding.
+ * \param op An ogg_packet structure to fill. libtheora will set all
+ * elements of this structure, including a pointer to the header
+ * data. The memory for the header data is owned by libtheora.
+ * \retval 0 Success
+ */
+extern int theora_encode_header(theora_state *t, ogg_packet *op);
+
+/**
+ * Request a comment header packet from provided metadata.
+ * A pointer to the comment data is placed in a user-provided ogg_packet
+ * structure.
+ * \param tc A theora_comment structure filled with the desired metadata
+ * \param op An ogg_packet structure to fill. libtheora will set all
+ * elements of this structure, including a pointer to the encoded
+ * comment data. The memory for the comment data is owned by
+ * libtheora.
+ * \retval 0 Success
+ */
+extern int theora_encode_comment(theora_comment *tc, ogg_packet *op);
+
+/**
+ * Request a packet containing the codebook tables for the stream.
+ * A pointer to the codebook data is placed in a user-provided ogg_packet
+ * structure.
+ * \param t A theora_state handle previously initialized for encoding.
+ * \param op An ogg_packet structure to fill. libtheora will set all
+ * elements of this structure, including a pointer to the codebook
+ * data. The memory for the header data is owned by libtheora.
+ * \retval 0 Success
+ */
+extern int theora_encode_tables(theora_state *t, ogg_packet *op);
+
+/**
+ * Decode an Ogg packet, with the expectation that the packet contains
+ * an initial header, comment data or codebook tables.
+ *
+ * \param ci A theora_info structure to fill. This must have been previously
+ * initialized with theora_info_init(). If \a op contains an initial
+ * header, theora_decode_header() will fill \a ci with the
+ * parsed header values. If \a op contains codebook tables,
+ * theora_decode_header() will parse these and attach an internal
+ * representation to \a ci->codec_setup.
+ * \param cc A theora_comment structure to fill. If \a op contains comment
+ * data, theora_decode_header() will fill \a cc with the parsed
+ * comments.
+ * \param op An ogg_packet structure which you expect contains an initial
+ * header, comment data or codebook tables.
+ *
+ * \retval OC_BADHEADER \a op is NULL; OR the first byte of \a op->packet
+ * has the signature of an initial packet, but op is
+ * not a b_o_s packet; OR this packet has the signature
+ * of an initial header packet, but an initial header
+ * packet has already been seen; OR this packet has the
+ * signature of a comment packet, but the initial header
+ * has not yet been seen; OR this packet has the signature
+ * of a comment packet, but contains invalid data; OR
+ * this packet has the signature of codebook tables,
+ * but the initial header or comments have not yet
+ * been seen; OR this packet has the signature of codebook
+ * tables, but contains invalid data;
+ * OR the stream being decoded has a compatible version
+ * but this packet does not have the signature of a
+ * theora initial header, comments, or codebook packet
+ * \retval OC_VERSION The packet data of \a op is an initial header with
+ * a version which is incompatible with this version of
+ * libtheora.
+ * \retval OC_NEWPACKET the stream being decoded has an incompatible (future)
+ * version and contains an unknown signature.
+ * \retval 0 Success
+ *
+ * \note The normal usage is that theora_decode_header() be called on the
+ * first three packets of a theora logical bitstream in succession.
+ */
+extern int theora_decode_header(theora_info *ci, theora_comment *cc,
+ ogg_packet *op);
+
+/**
+ * Initialize a theora_state handle for decoding.
+ * \param th The theora_state handle to initialize.
+ * \param c A theora_info struct filled with the desired decoding parameters.
+ * This is of course usually obtained from a previous call to
+ * theora_decode_header().
+ * \retval 0 Success
+ */
+extern int theora_decode_init(theora_state *th, theora_info *c);
+
+/**
+ * Input a packet containing encoded data into the theora decoder.
+ * \param th A theora_state handle previously initialized for decoding.
+ * \param op An ogg_packet containing encoded theora data.
+ * \retval 0 Success
+ * \retval OC_BADPACKET \a op does not contain encoded video data
+ */
+extern int theora_decode_packetin(theora_state *th,ogg_packet *op);
+
+/**
+ * Output the next available frame of decoded YUV data.
+ * \param th A theora_state handle previously initialized for decoding.
+ * \param yuv A yuv_buffer in which libtheora should place the decoded data.
+ * Note that the buffer struct itself is allocated by the user, but
+ * that the luma and chroma pointers will be filled in by the
+ * library. Also note that these luma and chroma regions should be
+ * considered read-only by the user.
+ * \retval 0 Success
+ */
+extern int theora_decode_YUVout(theora_state *th,yuv_buffer *yuv);
+
+/**
+ * Report whether a theora packet is a header or not
+ * This function does no verification beyond checking the header
+ * flag bit so it should not be used for bitstream identification;
+ * use theora_decode_header() for that.
+ *
+ * \param op An ogg_packet containing encoded theora data.
+ * \retval 1 The packet is a header packet
+ * \retval 0 The packet is not a header packet (and so contains frame data)
+ *
+ * Thus function was added in the 1.0alpha4 release.
+ */
+extern int theora_packet_isheader(ogg_packet *op);
+
+/**
+ * Report whether a theora packet is a keyframe or not
+ *
+ * \param op An ogg_packet containing encoded theora data.
+ * \retval 1 The packet contains a keyframe image
+ * \retval 0 The packet is contains an interframe delta
+ * \retval -1 The packet is not an image data packet at all
+ *
+ * Thus function was added in the 1.0alpha4 release.
+ */
+extern int theora_packet_iskeyframe(ogg_packet *op);
+
+/**
+ * Report the granulepos shift radix
+ *
+ * When embedded in Ogg, Theora uses a two-part granulepos,
+ * splitting the 64-bit field into two pieces. The more-significant
+ * section represents the frame count at the last keyframe,
+ * and the less-significant section represents the count of
+ * frames since the last keyframe. In this way the overall
+ * field is still non-decreasing with time, but usefully encodes
+ * a pointer to the last keyframe, which is necessary for
+ * correctly restarting decode after a seek.
+ *
+ * This function reports the number of bits used to represent
+ * the distance to the last keyframe, and thus how the granulepos
+ * field must be shifted or masked to obtain the two parts.
+ *
+ * Since libtheora returns compressed data in an ogg_packet
+ * structure, this may be generally useful even if the Theora
+ * packets are not being used in an Ogg container.
+ *
+ * \param ti A previously initialized theora_info struct
+ * \returns The bit shift dividing the two granulepos fields
+ *
+ * This function was added in the 1.0alpha5 release.
+ */
+int theora_granule_shift(theora_info *ti);
+
+/**
+ * Convert a granulepos to an absolute frame index, starting at 0.
+ * The granulepos is interpreted in the context of a given theora_state handle.
+ *
+ * Note that while the granulepos encodes the frame count (i.e. starting
+ * from 1) this call returns the frame index, starting from zero. Thus
+ * One can calculate the presentation time by multiplying the index by
+ * the rate.
+ *
+ * \param th A previously initialized theora_state handle (encode or decode)
+ * \param granulepos The granulepos to convert.
+ * \returns The frame index corresponding to \a granulepos.
+ * \retval -1 The given granulepos is undefined (i.e. negative)
+ *
+ * Thus function was added in the 1.0alpha4 release.
+ */
+extern ogg_int64_t theora_granule_frame(theora_state *th,ogg_int64_t granulepos);
+
+/**
+ * Convert a granulepos to absolute time in seconds. The granulepos is
+ * interpreted in the context of a given theora_state handle, and gives
+ * the end time of a frame's presentation as used in Ogg mux ordering.
+ *
+ * \param th A previously initialized theora_state handle (encode or decode)
+ * \param granulepos The granulepos to convert.
+ * \returns The absolute time in seconds corresponding to \a granulepos.
+ * This is the "end time" for the frame, or the latest time it should
+ * be displayed.
+ * It is not the presentation time.
+ * \retval -1. The given granulepos is undefined (i.e. negative), or
+ * \retval -1. The function has been disabled because floating
+ * point support is not available.
+ */
+extern double theora_granule_time(theora_state *th,ogg_int64_t granulepos);
+
+/**
+ * Initialize a theora_info structure. All values within the given theora_info
+ * structure are initialized, and space is allocated within libtheora for
+ * internal codec setup data.
+ * \param c A theora_info struct to initialize.
+ */
+extern void theora_info_init(theora_info *c);
+
+/**
+ * Clear a theora_info structure. All values within the given theora_info
+ * structure are cleared, and associated internal codec setup data is freed.
+ * \param c A theora_info struct to initialize.
+ */
+extern void theora_info_clear(theora_info *c);
+
+/**
+ * Free all internal data associated with a theora_state handle.
+ * \param t A theora_state handle.
+ */
+extern void theora_clear(theora_state *t);
+
+/**
+ * Initialize an allocated theora_comment structure
+ * \param tc An allocated theora_comment structure
+ **/
+extern void theora_comment_init(theora_comment *tc);
+
+/**
+ * Add a comment to an initialized theora_comment structure
+ * \param tc A previously initialized theora comment structure
+ * \param comment A null-terminated string encoding the comment in the form
+ * "TAG=the value"
+ *
+ * Neither theora_comment_add() nor theora_comment_add_tag() support
+ * comments containing null values, although the bitstream format
+ * supports this. To add such comments you will need to manipulate
+ * the theora_comment structure directly.
+ **/
+
+extern void theora_comment_add(theora_comment *tc, char *comment);
+
+/**
+ * Add a comment to an initialized theora_comment structure.
+ * \param tc A previously initialized theora comment structure
+ * \param tag A null-terminated string containing the tag
+ * associated with the comment.
+ * \param value The corresponding value as a null-terminated string
+ *
+ * Neither theora_comment_add() nor theora_comment_add_tag() support
+ * comments containing null values, although the bitstream format
+ * supports this. To add such comments you will need to manipulate
+ * the theora_comment structure directly.
+ **/
+extern void theora_comment_add_tag(theora_comment *tc,
+ char *tag, char *value);
+
+/**
+ * Look up a comment value by tag.
+ * \param tc Tn initialized theora_comment structure
+ * \param tag The tag to look up
+ * \param count The instance of the tag. The same tag can appear multiple
+ * times, each with a distinct and ordered value, so an index
+ * is required to retrieve them all.
+ * \returns A pointer to the queried tag's value
+ * \retval NULL No matching tag is found
+ *
+ * \note Use theora_comment_query_count() to get the legal range for the
+ * count parameter.
+ **/
+
+extern char *theora_comment_query(theora_comment *tc, char *tag, int count);
+
+/** Look up the number of instances of a tag.
+ * \param tc An initialized theora_comment structure
+ * \param tag The tag to look up
+ * \returns The number on instances of a particular tag.
+ *
+ * Call this first when querying for a specific tag and then interate
+ * over the number of instances with separate calls to
+ * theora_comment_query() to retrieve all instances in order.
+ **/
+extern int theora_comment_query_count(theora_comment *tc, char *tag);
+
+/**
+ * Clear an allocated theora_comment struct so that it can be freed.
+ * \param tc An allocated theora_comment structure.
+ **/
+extern void theora_comment_clear(theora_comment *tc);
+
+/**Encoder control function.
+ * This is used to provide advanced control the encoding process.
+ * \param th A #theora_state handle.
+ * \param req The control code to process.
+ * See \ref encctlcodes_old "the list of available
+ * control codes" for details.
+ * \param buf The parameters for this control code.
+ * \param buf_sz The size of the parameter buffer.*/
+extern int theora_control(theora_state *th,int req,void *buf,size_t buf_sz);
+
+/* @} */ /* end oldfuncs doxygen group */
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* _O_THEORA_H_ */
diff --git a/libs/libtheora-1.1/include/theora/theoradec.h b/libs/libtheora-1.1/include/theora/theoradec.h
new file mode 100644
index 00000000..41bacb1f
--- /dev/null
+++ b/libs/libtheora-1.1/include/theora/theoradec.h
@@ -0,0 +1,325 @@
+/********************************************************************
+ * *
+ * THIS FILE IS PART OF THE OggTheora SOFTWARE CODEC SOURCE CODE. *
+ * USE, DISTRIBUTION AND REPRODUCTION OF THIS LIBRARY SOURCE IS *
+ * GOVERNED BY A BSD-STYLE SOURCE LICENSE INCLUDED WITH THIS SOURCE *
+ * IN 'COPYING'. PLEASE READ THESE TERMS BEFORE DISTRIBUTING. *
+ * *
+ * THE Theora SOURCE CODE IS COPYRIGHT (C) 2002-2009 *
+ * by the Xiph.Org Foundation http://www.xiph.org/ *
+ * *
+ ********************************************************************
+
+ function:
+ last mod: $Id: theora.h,v 1.8 2004/03/15 22:17:32 derf Exp $
+
+ ********************************************************************/
+
+/**\file
+ * The libtheoradec C decoding API.*/
+
+#if !defined(_O_THEORA_THEORADEC_H_)
+# define _O_THEORA_THEORADEC_H_ (1)
+# include
+# include
+# include "codec.h"
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+
+
+/**\name th_decode_ctl() codes
+ * \anchor decctlcodes
+ * These are the available request codes for th_decode_ctl().
+ * By convention, these are odd, to distinguish them from the
+ * \ref encctlcodes "encoder control codes".
+ * Keep any experimental or vendor-specific values above \c 0x8000.*/
+/*@{*/
+/**Gets the maximum post-processing level.
+ * The decoder supports a post-processing filter that can improve
+ * the appearance of the decoded images. This returns the highest
+ * level setting for this post-processor, corresponding to maximum
+ * improvement and computational expense.
+ *
+ * \param[out] _buf int: The maximum post-processing level.
+ * \retval TH_EFAULT \a _dec_ctx or \a _buf is NULL.
+ * \retval TH_EINVAL \a _buf_sz is not sizeof(int).
+ * \retval TH_EIMPL Not supported by this implementation.*/
+#define TH_DECCTL_GET_PPLEVEL_MAX (1)
+/**Sets the post-processing level.
+ * By default, post-processing is disabled.
+ *
+ * Sets the level of post-processing to use when decoding the
+ * compressed stream. This must be a value between zero (off)
+ * and the maximum returned by TH_DECCTL_GET_PPLEVEL_MAX.
+ *
+ * \param[in] _buf int: The new post-processing level.
+ * 0 to disable; larger values use more CPU.
+ * \retval TH_EFAULT \a _dec_ctx or \a _buf is NULL.
+ * \retval TH_EINVAL \a _buf_sz is not sizeof(int), or the
+ * post-processing level is out of bounds.
+ * The maximum post-processing level may be
+ * implementation-specific, and can be obtained via
+ * #TH_DECCTL_GET_PPLEVEL_MAX.
+ * \retval TH_EIMPL Not supported by this implementation.*/
+#define TH_DECCTL_SET_PPLEVEL (3)
+/**Sets the granule position.
+ * Call this after a seek, before decoding the first frame, to ensure that the
+ * proper granule position is returned for all subsequent frames.
+ * If you track timestamps yourself and do not use the granule position
+ * returned by the decoder, then you need not call this function.
+ *
+ * \param[in] _buf ogg_int64_t: The granule position of the next
+ * frame.
+ * \retval TH_EFAULT \a _dec_ctx or \a _buf is NULL.
+ * \retval TH_EINVAL \a _buf_sz is not sizeof(ogg_int64_t), or the
+ * granule position is negative.*/
+#define TH_DECCTL_SET_GRANPOS (5)
+/**Sets the striped decode callback function.
+ * If set, this function will be called as each piece of a frame is fully
+ * decoded in th_decode_packetin().
+ * You can pass in a #th_stripe_callback with
+ * th_stripe_callback#stripe_decoded set to NULL to disable the
+ * callbacks at any point.
+ * Enabling striped decode does not prevent you from calling
+ * th_decode_ycbcr_out() after the frame is fully decoded.
+ *
+ * \param[in] _buf #th_stripe_callback: The callback parameters.
+ * \retval TH_EFAULT \a _dec_ctx or \a _buf is NULL.
+ * \retval TH_EINVAL \a _buf_sz is not
+ * sizeof(th_stripe_callback).*/
+#define TH_DECCTL_SET_STRIPE_CB (7)
+
+/**Enables telemetry and sets the macroblock display mode */
+#define TH_DECCTL_SET_TELEMETRY_MBMODE (9)
+/**Enables telemetry and sets the motion vector display mode */
+#define TH_DECCTL_SET_TELEMETRY_MV (11)
+/**Enables telemetry and sets the adaptive quantization display mode */
+#define TH_DECCTL_SET_TELEMETRY_QI (13)
+/**Enables telemetry and sets the bitstream breakdown visualization mode */
+#define TH_DECCTL_SET_TELEMETRY_BITS (15)
+/*@}*/
+
+
+
+/**A callback function for striped decode.
+ * This is a function pointer to an application-provided function that will be
+ * called each time a section of the image is fully decoded in
+ * th_decode_packetin().
+ * This allows the application to process the section immediately, while it is
+ * still in cache.
+ * Note that the frame is decoded bottom to top, so \a _yfrag0 will steadily
+ * decrease with each call until it reaches 0, at which point the full frame
+ * is decoded.
+ * The number of fragment rows made available in each call depends on the pixel
+ * format and the number of post-processing filters enabled, and may not even
+ * be constant for the entire frame.
+ * If a non-NULL \a _granpos pointer is passed to
+ * th_decode_packetin(), the granule position for the frame will be stored
+ * in it before the first callback is made.
+ * If an entire frame is dropped (a 0-byte packet), then no callbacks will be
+ * made at all for that frame.
+ * \param _ctx An application-provided context pointer.
+ * \param _buf The image buffer for the decoded frame.
+ * \param _yfrag0 The Y coordinate of the first row of 8x8 fragments
+ * decoded.
+ * Multiply this by 8 to obtain the pixel row number in the
+ * luma plane.
+ * If the chroma planes are subsampled in the Y direction,
+ * this will always be divisible by two.
+ * \param _yfrag_end The Y coordinate of the first row of 8x8 fragments past
+ * the newly decoded section.
+ * If the chroma planes are subsampled in the Y direction,
+ * this will always be divisible by two.
+ * I.e., this section contains fragment rows
+ * \a _yfrag0 ...\a _yfrag_end -1.*/
+typedef void (*th_stripe_decoded_func)(void *_ctx,th_ycbcr_buffer _buf,
+ int _yfrag0,int _yfrag_end);
+
+/**The striped decode callback data to pass to #TH_DECCTL_SET_STRIPE_CB.*/
+typedef struct{
+ /**An application-provided context pointer.
+ * This will be passed back verbatim to the application.*/
+ void *ctx;
+ /**The callback function pointer.*/
+ th_stripe_decoded_func stripe_decoded;
+}th_stripe_callback;
+
+
+
+/**\name Decoder state
+ The following data structures are opaque, and their contents are not
+ publicly defined by this API.
+ Referring to their internals directly is unsupported, and may break without
+ warning.*/
+/*@{*/
+/**The decoder context.*/
+typedef struct th_dec_ctx th_dec_ctx;
+/**Setup information.
+ This contains auxiliary information (Huffman tables and quantization
+ parameters) decoded from the setup header by th_decode_headerin() to be
+ passed to th_decode_alloc().
+ It can be re-used to initialize any number of decoders, and can be freed
+ via th_setup_free() at any time.*/
+typedef struct th_setup_info th_setup_info;
+/*@}*/
+
+
+
+/**\defgroup decfuncs Functions for Decoding*/
+/*@{*/
+/**\name Functions for decoding
+ * You must link to libtheoradec if you use any of the
+ * functions in this section.
+ *
+ * The functions are listed in the order they are used in a typical decode.
+ * The basic steps are:
+ * - Parse the header packets by repeatedly calling th_decode_headerin().
+ * - Allocate a #th_dec_ctx handle with th_decode_alloc().
+ * - Call th_setup_free() to free any memory used for codec setup
+ * information.
+ * - Perform any additional decoder configuration with th_decode_ctl().
+ * - For each video data packet:
+ * - Submit the packet to the decoder via th_decode_packetin().
+ * - Retrieve the uncompressed video data via th_decode_ycbcr_out().
+ * - Call th_decode_free() to release all decoder memory.*/
+/*@{*/
+/**Decodes the header packets of a Theora stream.
+ * This should be called on the initial packets of the stream, in succession,
+ * until it returns 0, indicating that all headers have been
+ * processed, or an error is encountered.
+ * At least three header packets are required, and additional optional header
+ * packets may follow.
+ * This can be used on the first packet of any logical stream to determine if
+ * that stream is a Theora stream.
+ * \param _info A #th_info structure to fill in.
+ * This must have been previously initialized with
+ * th_info_init().
+ * The application may immediately begin using the contents of
+ * this structure after the first header is decoded, though it
+ * must continue to be passed in on all subsequent calls.
+ * \param _tc A #th_comment structure to fill in.
+ * The application may immediately begin using the contents of
+ * this structure after the second header is decoded, though it
+ * must continue to be passed in on all subsequent calls.
+ * \param _setup Returns a pointer to additional, private setup information
+ * needed by the decoder.
+ * The contents of this pointer must be initialized to
+ * NULL on the first call, and the returned value must
+ * continue to be passed in on all subsequent calls.
+ * \param _op An ogg_packet structure which contains one of the
+ * initial packets of an Ogg logical stream.
+ * \return A positive value indicates that a Theora header was successfully
+ * processed.
+ * \retval 0 The first video data packet was encountered after all
+ * required header packets were parsed.
+ * The packet just passed in on this call should be saved
+ * and fed to th_decode_packetin() to begin decoding
+ * video data.
+ * \retval TH_EFAULT One of \a _info, \a _tc, or \a _setup was
+ * NULL.
+ * \retval TH_EBADHEADER \a _op was NULL, the packet was not the next
+ * header packet in the expected sequence, or the format
+ * of the header data was invalid.
+ * \retval TH_EVERSION The packet data was a Theora info header, but for a
+ * bitstream version not decodable with this version of
+ * libtheoradec.
+ * \retval TH_ENOTFORMAT The packet was not a Theora header.
+ */
+extern int th_decode_headerin(th_info *_info,th_comment *_tc,
+ th_setup_info **_setup,ogg_packet *_op);
+/**Allocates a decoder instance.
+ *
+ * Security Warning: The Theora format supports very large frame sizes,
+ * potentially even larger than the address space of a 32-bit machine, and
+ * creating a decoder context allocates the space for several frames of data.
+ * If the allocation fails here, your program will crash, possibly at some
+ * future point because the OS kernel returned a valid memory range and will
+ * only fail when it tries to map the pages in it the first time they are
+ * used.
+ * Even if it succeeds, you may experience a denial of service if the frame
+ * size is large enough to cause excessive paging.
+ * If you are integrating libtheora in a larger application where such things
+ * are undesirable, it is highly recommended that you check the frame size in
+ * \a _info before calling this function and refuse to decode streams where it
+ * is larger than some reasonable maximum.
+ * libtheora will not check this for you, because there may be machines that
+ * can handle such streams and applications that wish to.
+ * \param _info A #th_info struct filled via th_decode_headerin().
+ * \param _setup A #th_setup_info handle returned via
+ * th_decode_headerin().
+ * \return The initialized #th_dec_ctx handle.
+ * \retval NULL If the decoding parameters were invalid.*/
+extern th_dec_ctx *th_decode_alloc(const th_info *_info,
+ const th_setup_info *_setup);
+/**Releases all storage used for the decoder setup information.
+ * This should be called after you no longer want to create any decoders for
+ * a stream whose headers you have parsed with th_decode_headerin().
+ * \param _setup The setup information to free.
+ * This can safely be NULL.*/
+extern void th_setup_free(th_setup_info *_setup);
+/**Decoder control function.
+ * This is used to provide advanced control of the decoding process.
+ * \param _dec A #th_dec_ctx handle.
+ * \param _req The control code to process.
+ * See \ref decctlcodes "the list of available control codes"
+ * for details.
+ * \param _buf The parameters for this control code.
+ * \param _buf_sz The size of the parameter buffer.*/
+extern int th_decode_ctl(th_dec_ctx *_dec,int _req,void *_buf,
+ size_t _buf_sz);
+/**Submits a packet containing encoded video data to the decoder.
+ * \param _dec A #th_dec_ctx handle.
+ * \param _op An ogg_packet containing encoded video data.
+ * \param _granpos Returns the granule position of the decoded packet.
+ * If non-NULL, the granule position for this specific
+ * packet is stored in this location.
+ * This is computed incrementally from previously decoded
+ * packets.
+ * After a seek, the correct granule position must be set via
+ * #TH_DECCTL_SET_GRANPOS for this to work properly.
+ * \retval 0 Success.
+ * A new decoded frame can be retrieved by calling
+ * th_decode_ycbcr_out().
+ * \retval TH_DUPFRAME The packet represented a dropped (0-byte) frame.
+ * The player can skip the call to th_decode_ycbcr_out(),
+ * as the contents of the decoded frame buffer have not
+ * changed.
+ * \retval TH_EFAULT \a _dec or \a _op was NULL.
+ * \retval TH_EBADPACKET \a _op does not contain encoded video data.
+ * \retval TH_EIMPL The video data uses bitstream features which this
+ * library does not support.*/
+extern int th_decode_packetin(th_dec_ctx *_dec,const ogg_packet *_op,
+ ogg_int64_t *_granpos);
+/**Outputs the next available frame of decoded Y'CbCr data.
+ * If a striped decode callback has been set with #TH_DECCTL_SET_STRIPE_CB,
+ * then the application does not need to call this function.
+ * \param _dec A #th_dec_ctx handle.
+ * \param _ycbcr A video buffer structure to fill in.
+ * libtheoradec will fill in all the members of this
+ * structure, including the pointers to the uncompressed video
+ * data.
+ * The memory for this video data is owned by
+ * libtheoradec.
+ * It may be freed or overwritten without notification when
+ * subsequent frames are decoded.
+ * \retval 0 Success
+ * \retval TH_EFAULT \a _dec or \a _ycbcr was NULL.
+ */
+extern int th_decode_ycbcr_out(th_dec_ctx *_dec,
+ th_ycbcr_buffer _ycbcr);
+/**Frees an allocated decoder instance.
+ * \param _dec A #th_dec_ctx handle.*/
+extern void th_decode_free(th_dec_ctx *_dec);
+/*@}*/
+/*@}*/
+
+
+
+#if defined(__cplusplus)
+}
+#endif
+
+#endif
diff --git a/libs/libtheora-1.1/include/theora/theoraenc.h b/libs/libtheora-1.1/include/theora/theoraenc.h
new file mode 100644
index 00000000..b0b34434
--- /dev/null
+++ b/libs/libtheora-1.1/include/theora/theoraenc.h
@@ -0,0 +1,500 @@
+/********************************************************************
+ * *
+ * THIS FILE IS PART OF THE OggTheora SOFTWARE CODEC SOURCE CODE. *
+ * USE, DISTRIBUTION AND REPRODUCTION OF THIS LIBRARY SOURCE IS *
+ * GOVERNED BY A BSD-STYLE SOURCE LICENSE INCLUDED WITH THIS SOURCE *
+ * IN 'COPYING'. PLEASE READ THESE TERMS BEFORE DISTRIBUTING. *
+ * *
+ * THE Theora SOURCE CODE IS COPYRIGHT (C) 2002-2009 *
+ * by the Xiph.Org Foundation http://www.xiph.org/ *
+ * *
+ ********************************************************************
+
+ function:
+ last mod: $Id: theora.h,v 1.8 2004/03/15 22:17:32 derf Exp $
+
+ ********************************************************************/
+
+/**\file
+ * The libtheoraenc C encoding API.*/
+
+#if !defined(_O_THEORA_THEORAENC_H_)
+# define _O_THEORA_THEORAENC_H_ (1)
+# include
+# include
+# include "codec.h"
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+
+
+/**\name th_encode_ctl() codes
+ * \anchor encctlcodes
+ * These are the available request codes for th_encode_ctl().
+ * By convention, these are even, to distinguish them from the
+ * \ref decctlcodes "decoder control codes".
+ * Keep any experimental or vendor-specific values above \c 0x8000.*/
+/*@{*/
+/**Sets the Huffman tables to use.
+ * The tables are copied, not stored by reference, so they can be freed after
+ * this call.
+ * NULL may be specified to revert to the default tables.
+ *
+ * \param[in] _buf #th_huff_code[#TH_NHUFFMAN_TABLES][#TH_NDCT_TOKENS]
+ * \retval TH_EFAULT \a _enc_ctx is NULL.
+ * \retval TH_EINVAL Encoding has already begun or one or more of the given
+ * tables is not full or prefix-free, \a _buf is
+ * NULL and \a _buf_sz is not zero, or \a _buf is
+ * non-NULL and \a _buf_sz is not
+ * sizeof(#th_huff_code)*#TH_NHUFFMAN_TABLES*#TH_NDCT_TOKENS.
+ * \retval TH_EIMPL Not supported by this implementation.*/
+#define TH_ENCCTL_SET_HUFFMAN_CODES (0)
+/**Sets the quantization parameters to use.
+ * The parameters are copied, not stored by reference, so they can be freed
+ * after this call.
+ * NULL may be specified to revert to the default parameters.
+ *
+ * \param[in] _buf #th_quant_info
+ * \retval TH_EFAULT \a _enc_ctx is NULL.
+ * \retval TH_EINVAL Encoding has already begun, \a _buf is
+ * NULL and \a _buf_sz is not zero,
+ * or \a _buf is non-NULL and
+ * \a _buf_sz is not sizeof(#th_quant_info).
+ * \retval TH_EIMPL Not supported by this implementation.*/
+#define TH_ENCCTL_SET_QUANT_PARAMS (2)
+/**Sets the maximum distance between key frames.
+ * This can be changed during an encode, but will be bounded by
+ * 1<.
+ * If it is set before encoding begins, th_info#keyframe_granule_shift will
+ * be enlarged appropriately.
+ *
+ * \param[in] _buf ogg_uint32_t: The maximum distance between key
+ * frames.
+ * \param[out] _buf ogg_uint32_t: The actual maximum distance set.
+ * \retval TH_EFAULT \a _enc_ctx or \a _buf is NULL.
+ * \retval TH_EINVAL \a _buf_sz is not sizeof(ogg_uint32_t).
+ * \retval TH_EIMPL Not supported by this implementation.*/
+#define TH_ENCCTL_SET_KEYFRAME_FREQUENCY_FORCE (4)
+/**Disables any encoder features that would prevent lossless transcoding back
+ * to VP3.
+ * This primarily means disabling block-adaptive quantization and always coding
+ * all four luma blocks in a macro block when 4MV is used.
+ * It also includes using the VP3 quantization tables and Huffman codes; if you
+ * set them explicitly after calling this function, the resulting stream will
+ * not be VP3-compatible.
+ * If you enable VP3-compatibility when encoding 4:2:2 or 4:4:4 source
+ * material, or when using a picture region smaller than the full frame (e.g.
+ * a non-multiple-of-16 width or height), then non-VP3 bitstream features will
+ * still be disabled, but the stream will still not be VP3-compatible, as VP3
+ * was not capable of encoding such formats.
+ * If you call this after encoding has already begun, then the quantization
+ * tables and codebooks cannot be changed, but the frame-level features will
+ * be enabled or disabled as requested.
+ *
+ * \param[in] _buf int: a non-zero value to enable VP3 compatibility,
+ * or 0 to disable it (the default).
+ * \param[out] _buf int: 1 if all bitstream features required for
+ * VP3-compatibility could be set, and 0 otherwise.
+ * The latter will be returned if the pixel format is not
+ * 4:2:0, the picture region is smaller than the full frame,
+ * or if encoding has begun, preventing the quantization
+ * tables and codebooks from being set.
+ * \retval TH_EFAULT \a _enc_ctx or \a _buf is NULL.
+ * \retval TH_EINVAL \a _buf_sz is not sizeof(int).
+ * \retval TH_EIMPL Not supported by this implementation.*/
+#define TH_ENCCTL_SET_VP3_COMPATIBLE (10)
+/**Gets the maximum speed level.
+ * Higher speed levels favor quicker encoding over better quality per bit.
+ * Depending on the encoding mode, and the internal algorithms used, quality
+ * may actually improve, but in this case bitrate will also likely increase.
+ * In any case, overall rate/distortion performance will probably decrease.
+ * The maximum value, and the meaning of each value, may change depending on
+ * the current encoding mode (VBR vs. constant quality, etc.).
+ *
+ * \param[out] _buf int: The maximum encoding speed level.
+ * \retval TH_EFAULT \a _enc_ctx or \a _buf is NULL.
+ * \retval TH_EINVAL \a _buf_sz is not sizeof(int).
+ * \retval TH_EIMPL Not supported by this implementation in the current
+ * encoding mode.*/
+#define TH_ENCCTL_GET_SPLEVEL_MAX (12)
+/**Sets the speed level.
+ * The current speed level may be retrieved using #TH_ENCCTL_GET_SPLEVEL.
+ *
+ * \param[in] _buf int: The new encoding speed level.
+ * 0 is slowest, larger values use less CPU.
+ * \retval TH_EFAULT \a _enc_ctx or \a _buf is NULL.
+ * \retval TH_EINVAL \a _buf_sz is not sizeof(int), or the
+ * encoding speed level is out of bounds.
+ * The maximum encoding speed level may be
+ * implementation- and encoding mode-specific, and can be
+ * obtained via #TH_ENCCTL_GET_SPLEVEL_MAX.
+ * \retval TH_EIMPL Not supported by this implementation in the current
+ * encoding mode.*/
+#define TH_ENCCTL_SET_SPLEVEL (14)
+/**Gets the current speed level.
+ * The default speed level may vary according to encoder implementation, but if
+ * this control code is not supported (it returns #TH_EIMPL), the default may
+ * be assumed to be the slowest available speed (0).
+ * The maximum encoding speed level may be implementation- and encoding
+ * mode-specific, and can be obtained via #TH_ENCCTL_GET_SPLEVEL_MAX.
+ *
+ * \param[out] _buf int: The current encoding speed level.
+ * 0 is slowest, larger values use less CPU.
+ * \retval TH_EFAULT \a _enc_ctx or \a _buf is NULL.
+ * \retval TH_EINVAL \a _buf_sz is not sizeof(int).
+ * \retval TH_EIMPL Not supported by this implementation in the current
+ * encoding mode.*/
+#define TH_ENCCTL_GET_SPLEVEL (16)
+/**Sets the number of duplicates of the next frame to produce.
+ * Although libtheora can encode duplicate frames very cheaply, it costs some
+ * amount of CPU to detect them, and a run of duplicates cannot span a
+ * keyframe boundary.
+ * This control code tells the encoder to produce the specified number of extra
+ * duplicates of the next frame.
+ * This allows the encoder to make smarter keyframe placement decisions and
+ * rate control decisions, and reduces CPU usage as well, when compared to
+ * just submitting the same frame for encoding multiple times.
+ * This setting only applies to the next frame submitted for encoding.
+ * You MUST call th_encode_packetout() repeatedly until it returns 0, or the
+ * extra duplicate frames will be lost.
+ *
+ * \param[in] _buf int: The number of duplicates to produce.
+ * If this is negative or zero, no duplicates will be produced.
+ * \retval TH_EFAULT \a _enc_ctx or \a _buf is NULL.
+ * \retval TH_EINVAL \a _buf_sz is not sizeof(int), or the
+ * number of duplicates is greater than or equal to the
+ * maximum keyframe interval.
+ * In the latter case, NO duplicate frames will be produced.
+ * You must ensure that the maximum keyframe interval is set
+ * larger than the maximum number of duplicates you will
+ * ever wish to insert prior to encoding.
+ * \retval TH_EIMPL Not supported by this implementation in the current
+ * encoding mode.*/
+#define TH_ENCCTL_SET_DUP_COUNT (18)
+/**Modifies the default bitrate management behavior.
+ * Use to allow or disallow frame dropping, and to enable or disable capping
+ * bit reservoir overflows and underflows.
+ * See \ref encctlcodes "the list of available flags".
+ * The flags are set by default to
+ * #TH_RATECTL_DROP_FRAMES|#TH_RATECTL_CAP_OVERFLOW.
+ *
+ * \param[in] _buf int: Any combination of
+ * \ref ratectlflags "the available flags":
+ * - #TH_RATECTL_DROP_FRAMES: Enable frame dropping.
+ * - #TH_RATECTL_CAP_OVERFLOW: Don't bank excess bits for later
+ * use.
+ * - #TH_RATECTL_CAP_UNDERFLOW: Don't try to make up shortfalls
+ * later.
+ * \retval TH_EFAULT \a _enc_ctx or \a _buf is NULL.
+ * \retval TH_EINVAL \a _buf_sz is not sizeof(int) or rate control
+ * is not enabled.
+ * \retval TH_EIMPL Not supported by this implementation in the current
+ * encoding mode.*/
+#define TH_ENCCTL_SET_RATE_FLAGS (20)
+/**Sets the size of the bitrate management bit reservoir as a function
+ * of number of frames.
+ * The reservoir size affects how quickly bitrate management reacts to
+ * instantaneous changes in the video complexity.
+ * Larger reservoirs react more slowly, and provide better overall quality, but
+ * require more buffering by a client, adding more latency to live streams.
+ * By default, libtheora sets the reservoir to the maximum distance between
+ * keyframes, subject to a minimum and maximum limit.
+ * This call may be used to increase or decrease the reservoir, increasing or
+ * decreasing the allowed temporary variance in bitrate.
+ * An implementation may impose some limits on the size of a reservoir it can
+ * handle, in which case the actual reservoir size may not be exactly what was
+ * requested.
+ * The actual value set will be returned.
+ *
+ * \param[in] _buf int: Requested size of the reservoir measured in
+ * frames.
+ * \param[out] _buf int: The actual size of the reservoir set.
+ * \retval TH_EFAULT \a _enc_ctx or \a _buf is NULL.
+ * \retval TH_EINVAL \a _buf_sz is not sizeof(int), or rate control
+ * is not enabled. The buffer has an implementation
+ * defined minimum and maximum size and the value in _buf
+ * will be adjusted to match the actual value set.
+ * \retval TH_EIMPL Not supported by this implementation in the current
+ * encoding mode.*/
+#define TH_ENCCTL_SET_RATE_BUFFER (22)
+/**Enable pass 1 of two-pass encoding mode and retrieve the first pass metrics.
+ * Pass 1 mode must be enabled before the first frame is encoded, and a target
+ * bitrate must have already been specified to the encoder.
+ * Although this does not have to be the exact rate that will be used in the
+ * second pass, closer values may produce better results.
+ * The first call returns the size of the two-pass header data, along with some
+ * placeholder content, and sets the encoder into pass 1 mode implicitly.
+ * This call sets the encoder to pass 1 mode implicitly.
+ * Then, a subsequent call must be made after each call to
+ * th_encode_ycbcr_in() to retrieve the metrics for that frame.
+ * An additional, final call must be made to retrieve the summary data,
+ * containing such information as the total number of frames, etc.
+ * This must be stored in place of the placeholder data that was returned
+ * in the first call, before the frame metrics data.
+ * All of this data must be presented back to the encoder during pass 2 using
+ * #TH_ENCCTL_2PASS_IN.
+ *
+ * \param[out] char *_buf: Returns a pointer to internal storage
+ * containing the two pass metrics data.
+ * This storage is only valid until the next call, or until the
+ * encoder context is freed, and must be copied by the
+ * application.
+ * \retval >=0 The number of bytes of metric data available in the
+ * returned buffer.
+ * \retval TH_EFAULT \a _enc_ctx or \a _buf is NULL.
+ * \retval TH_EINVAL \a _buf_sz is not sizeof(char *), no target
+ * bitrate has been set, or the first call was made after
+ * the first frame was submitted for encoding.
+ * \retval TH_EIMPL Not supported by this implementation.*/
+#define TH_ENCCTL_2PASS_OUT (24)
+/**Submits two-pass encoding metric data collected the first encoding pass to
+ * the second pass.
+ * The first call must be made before the first frame is encoded, and a target
+ * bitrate must have already been specified to the encoder.
+ * It sets the encoder to pass 2 mode implicitly; this cannot be disabled.
+ * The encoder may require reading data from some or all of the frames in
+ * advance, depending on, e.g., the reservoir size used in the second pass.
+ * You must call this function repeatedly before each frame to provide data
+ * until either a) it fails to consume all of the data presented or b) all of
+ * the pass 1 data has been consumed.
+ * In the first case, you must save the remaining data to be presented after
+ * the next frame.
+ * You can call this function with a NULL argument to get an upper bound on
+ * the number of bytes that will be required before the next frame.
+ *
+ * When pass 2 is first enabled, the default bit reservoir is set to the entire
+ * file; this gives maximum flexibility but can lead to very high peak rates.
+ * You can subsequently set it to another value with #TH_ENCCTL_SET_RATE_BUFFER
+ * (e.g., to set it to the keyframe interval for non-live streaming), however,
+ * you may then need to provide more data before the next frame.
+ *
+ * \param[in] _buf char[]: A buffer containing the data returned by
+ * #TH_ENCCTL_2PASS_OUT in pass 1.
+ * You may pass NULL for \a _buf to return an upper
+ * bound on the number of additional bytes needed before the
+ * next frame.
+ * The summary data returned at the end of pass 1 must be at
+ * the head of the buffer on the first call with a
+ * non-NULL \a _buf, and the placeholder data
+ * returned at the start of pass 1 should be omitted.
+ * After each call you should advance this buffer by the number
+ * of bytes consumed.
+ * \retval >0 The number of bytes of metric data required/consumed.
+ * \retval 0 No more data is required before the next frame.
+ * \retval TH_EFAULT \a _enc_ctx is NULL.
+ * \retval TH_EINVAL No target bitrate has been set, or the first call was
+ * made after the first frame was submitted for
+ * encoding.
+ * \retval TH_ENOTFORMAT The data did not appear to be pass 1 from a compatible
+ * implementation of this library.
+ * \retval TH_EBADHEADER The data was invalid; this may be returned when
+ * attempting to read an aborted pass 1 file that still
+ * has the placeholder data in place of the summary
+ * data.
+ * \retval TH_EIMPL Not supported by this implementation.*/
+#define TH_ENCCTL_2PASS_IN (26)
+/**Sets the current encoding quality.
+ * This is only valid so long as no bitrate has been specified, either through
+ * the #th_info struct used to initialize the encoder or through
+ * #TH_ENCCTL_SET_BITRATE (this restriction may be relaxed in a future
+ * version).
+ * If it is set before the headers are emitted, the target quality encoded in
+ * them will be updated.
+ *
+ * \param[in] _buf int: The new target quality, in the range 0...63,
+ * inclusive.
+ * \retval 0 Success.
+ * \retval TH_EFAULT \a _enc_ctx or \a _buf is NULL.
+ * \retval TH_EINVAL A target bitrate has already been specified, or the
+ * quality index was not in the range 0...63.
+ * \retval TH_EIMPL Not supported by this implementation.*/
+#define TH_ENCCTL_SET_QUALITY (28)
+/**Sets the current encoding bitrate.
+ * Once a bitrate is set, the encoder must use a rate-controlled mode for all
+ * future frames (this restriction may be relaxed in a future version).
+ * If it is set before the headers are emitted, the target bitrate encoded in
+ * them will be updated.
+ * Due to the buffer delay, the exact bitrate of each section of the encode is
+ * not guaranteed.
+ * The encoder may have already used more bits than allowed for the frames it
+ * has encoded, expecting to make them up in future frames, or it may have
+ * used fewer, holding the excess in reserve.
+ * The exact transition between the two bitrates is not well-defined by this
+ * API, but may be affected by flags set with #TH_ENCCTL_SET_RATE_FLAGS.
+ * After a number of frames equal to the buffer delay, one may expect further
+ * output to average at the target bitrate.
+ *
+ * \param[in] _buf long: The new target bitrate, in bits per second.
+ * \retval 0 Success.
+ * \retval TH_EFAULT \a _enc_ctx or \a _buf is NULL.
+ * \retval TH_EINVAL The target bitrate was not positive.
+ * \retval TH_EIMPL Not supported by this implementation.*/
+#define TH_ENCCTL_SET_BITRATE (30)
+
+/*@}*/
+
+
+/**\name TH_ENCCTL_SET_RATE_FLAGS flags
+ * \anchor ratectlflags
+ * These are the flags available for use with #TH_ENCCTL_SET_RATE_FLAGS.*/
+/*@{*/
+/**Drop frames to keep within bitrate buffer constraints.
+ * This can have a severe impact on quality, but is the only way to ensure that
+ * bitrate targets are met at low rates during sudden bursts of activity.*/
+#define TH_RATECTL_DROP_FRAMES (0x1)
+/**Ignore bitrate buffer overflows.
+ * If the encoder uses so few bits that the reservoir of available bits
+ * overflows, ignore the excess.
+ * The encoder will not try to use these extra bits in future frames.
+ * At high rates this may cause the result to be undersized, but allows a
+ * client to play the stream using a finite buffer; it should normally be
+ * enabled.*/
+#define TH_RATECTL_CAP_OVERFLOW (0x2)
+/**Ignore bitrate buffer underflows.
+ * If the encoder uses so many bits that the reservoir of available bits
+ * underflows, ignore the deficit.
+ * The encoder will not try to make up these extra bits in future frames.
+ * At low rates this may cause the result to be oversized; it should normally
+ * be disabled.*/
+#define TH_RATECTL_CAP_UNDERFLOW (0x4)
+/*@}*/
+
+
+
+/**The quantization parameters used by VP3.*/
+extern const th_quant_info TH_VP31_QUANT_INFO;
+
+/**The Huffman tables used by VP3.*/
+extern const th_huff_code
+ TH_VP31_HUFF_CODES[TH_NHUFFMAN_TABLES][TH_NDCT_TOKENS];
+
+
+
+/**\name Encoder state
+ The following data structure is opaque, and its contents are not publicly
+ defined by this API.
+ Referring to its internals directly is unsupported, and may break without
+ warning.*/
+/*@{*/
+/**The encoder context.*/
+typedef struct th_enc_ctx th_enc_ctx;
+/*@}*/
+
+
+
+/**\defgroup encfuncs Functions for Encoding*/
+/*@{*/
+/**\name Functions for encoding
+ * You must link to libtheoraenc and libtheoradec
+ * if you use any of the functions in this section.
+ *
+ * The functions are listed in the order they are used in a typical encode.
+ * The basic steps are:
+ * - Fill in a #th_info structure with details on the format of the video you
+ * wish to encode.
+ * - Allocate a #th_enc_ctx handle with th_encode_alloc().
+ * - Perform any additional encoder configuration required with
+ * th_encode_ctl().
+ * - Repeatedly call th_encode_flushheader() to retrieve all the header
+ * packets.
+ * - For each uncompressed frame:
+ * - Submit the uncompressed frame via th_encode_ycbcr_in()
+ * - Repeatedly call th_encode_packetout() to retrieve any video data packets
+ * that are ready.
+ * - Call th_encode_free() to release all encoder memory.*/
+/*@{*/
+/**Allocates an encoder instance.
+ * \param _info A #th_info struct filled with the desired encoding parameters.
+ * \return The initialized #th_enc_ctx handle.
+ * \retval NULL If the encoding parameters were invalid.*/
+extern th_enc_ctx *th_encode_alloc(const th_info *_info);
+/**Encoder control function.
+ * This is used to provide advanced control the encoding process.
+ * \param _enc A #th_enc_ctx handle.
+ * \param _req The control code to process.
+ * See \ref encctlcodes "the list of available control codes"
+ * for details.
+ * \param _buf The parameters for this control code.
+ * \param _buf_sz The size of the parameter buffer.*/
+extern int th_encode_ctl(th_enc_ctx *_enc,int _req,void *_buf,size_t _buf_sz);
+/**Outputs the next header packet.
+ * This should be called repeatedly after encoder initialization until it
+ * returns 0 in order to get all of the header packets, in order, before
+ * encoding actual video data.
+ * \param _enc A #th_enc_ctx handle.
+ * \param _comments The metadata to place in the comment header, when it is
+ * encoded.
+ * \param _op An ogg_packet structure to fill.
+ * All of the elements of this structure will be set,
+ * including a pointer to the header data.
+ * The memory for the header data is owned by
+ * libtheoraenc, and may be invalidated when the
+ * next encoder function is called.
+ * \return A positive value indicates that a header packet was successfully
+ * produced.
+ * \retval 0 No packet was produced, and no more header packets remain.
+ * \retval TH_EFAULT \a _enc, \a _comments, or \a _op was NULL.*/
+extern int th_encode_flushheader(th_enc_ctx *_enc,
+ th_comment *_comments,ogg_packet *_op);
+/**Submits an uncompressed frame to the encoder.
+ * \param _enc A #th_enc_ctx handle.
+ * \param _ycbcr A buffer of Y'CbCr data to encode.
+ * If the width and height of the buffer matches the frame size
+ * the encoder was initialized with, the encoder will only
+ * reference the portion inside the picture region.
+ * Any data outside this region will be ignored, and need not map
+ * to a valid address.
+ * Alternatively, you can pass a buffer equal to the size of the
+ * picture region, if this is less than the full frame size.
+ * When using subsampled chroma planes, odd picture sizes or odd
+ * picture offsets may require an unexpected chroma plane size,
+ * and their use is generally discouraged, as they will not be
+ * well-supported by players and other media frameworks.
+ * See Section 4.4 of
+ * the Theora
+ * specification for details if you wish to use them anyway.
+ * \retval 0 Success.
+ * \retval TH_EFAULT \a _enc or \a _ycbcr is NULL.
+ * \retval TH_EINVAL The buffer size matches neither the frame size nor the
+ * picture size the encoder was initialized with, or
+ * encoding has already completed.*/
+extern int th_encode_ycbcr_in(th_enc_ctx *_enc,th_ycbcr_buffer _ycbcr);
+/**Retrieves encoded video data packets.
+ * This should be called repeatedly after each frame is submitted to flush any
+ * encoded packets, until it returns 0.
+ * The encoder will not buffer these packets as subsequent frames are
+ * compressed, so a failure to do so will result in lost video data.
+ * \note Currently the encoder operates in a one-frame-in, one-packet-out
+ * manner.
+ * However, this may be changed in the future.
+ * \param _enc A #th_enc_ctx handle.
+ * \param _last Set this flag to a non-zero value if no more uncompressed
+ * frames will be submitted.
+ * This ensures that a proper EOS flag is set on the last packet.
+ * \param _op An ogg_packet structure to fill.
+ * All of the elements of this structure will be set, including a
+ * pointer to the video data.
+ * The memory for the video data is owned by
+ * libtheoraenc, and may be invalidated when the next
+ * encoder function is called.
+ * \return A positive value indicates that a video data packet was successfully
+ * produced.
+ * \retval 0 No packet was produced, and no more encoded video data
+ * remains.
+ * \retval TH_EFAULT \a _enc or \a _op was NULL.*/
+extern int th_encode_packetout(th_enc_ctx *_enc,int _last,ogg_packet *_op);
+/**Frees an allocated encoder instance.
+ * \param _enc A #th_enc_ctx handle.*/
+extern void th_encode_free(th_enc_ctx *_enc);
+/*@}*/
+/*@}*/
+
+
+
+#if defined(__cplusplus)
+}
+#endif
+
+#endif
diff --git a/libs/libtheora-1.1/lib/Makefile.am b/libs/libtheora-1.1/lib/Makefile.am
new file mode 100644
index 00000000..bcd8e67c
--- /dev/null
+++ b/libs/libtheora-1.1/lib/Makefile.am
@@ -0,0 +1,177 @@
+INCLUDES = -I$(top_srcdir)/include
+AM_CFLAGS = $(OGG_CFLAGS) $(CAIRO_CFLAGS)
+
+EXTRA_DIST = \
+ cpu.c \
+ encoder_disabled.c \
+ x86/mmxencfrag.c \
+ x86/mmxfdct.c \
+ x86/sse2fdct.c \
+ x86/x86enc.c \
+ x86/x86enc.h \
+ x86/mmxfrag.c \
+ x86/mmxfrag.h \
+ x86/mmxidct.c \
+ x86/mmxloop.h \
+ x86/mmxstate.c \
+ x86/x86int.h \
+ x86/x86state.c \
+ x86_vc
+
+lib_LTLIBRARIES = libtheoradec.la libtheoraenc.la libtheora.la
+
+if THEORA_DISABLE_ENCODE
+encoder_uniq_sources = \
+ encoder_disabled.c
+
+encoder_sources = \
+ $(encoder_uniq_sources)
+else
+encoder_uniq_x86_sources = \
+ x86/mmxencfrag.c \
+ x86/mmxfdct.c \
+ x86/x86enc.c
+
+encoder_uniq_x86_64_sources = \
+ x86/sse2fdct.c
+
+encoder_shared_x86_sources = \
+ x86/mmxfrag.c \
+ x86/mmxidct.c \
+ x86/mmxstate.c \
+ x86/x86state.c
+
+encoder_shared_x86_64_sources =
+
+if CPU_x86_64
+encoder_uniq_arch_sources = \
+ $(encoder_uniq_x86_sources) \
+ $(encoder_uniq_x86_64_sources)
+encoder_shared_arch_sources = \
+ $(encoder_shared_x86_sources) \
+ $(encoder_shared_x86_64_sources)
+else
+if CPU_x86_32
+encoder_uniq_arch_sources = $(encoder_uniq_x86_sources)
+encoder_shared_arch_sources = $(encoder_shared_x86_sources)
+else
+encoder_uniq_arch_sources =
+encoder_shared_arch_sources =
+endif
+endif
+
+encoder_uniq_sources = \
+ analyze.c \
+ fdct.c \
+ encfrag.c \
+ encapiwrapper.c \
+ encinfo.c \
+ encode.c \
+ enquant.c \
+ huffenc.c \
+ mathops.c \
+ mcenc.c \
+ rate.c \
+ tokenize.c \
+ $(encoder_uniq_arch_sources)
+
+encoder_sources = \
+ apiwrapper.c \
+ fragment.c \
+ idct.c \
+ internal.c \
+ state.c \
+ quant.c \
+ $(encoder_shared_arch_sources) \
+ $(encoder_uniq_sources)
+
+endif
+
+decoder_x86_sources = \
+ x86/mmxidct.c \
+ x86/mmxfrag.c \
+ x86/mmxstate.c \
+ x86/x86state.c
+if CPU_x86_64
+decoder_arch_sources = $(decoder_x86_sources)
+else
+if CPU_x86_32
+decoder_arch_sources = $(decoder_x86_sources)
+else
+decoder_arch_sources =
+endif
+endif
+
+decoder_sources = \
+ apiwrapper.c \
+ bitpack.c \
+ decapiwrapper.c \
+ decinfo.c \
+ decode.c \
+ dequant.c \
+ fragment.c \
+ huffdec.c \
+ idct.c \
+ info.c \
+ internal.c \
+ quant.c \
+ state.c \
+ $(decoder_arch_sources)
+
+noinst_HEADERS = \
+ cpu.h \
+ internal.h \
+ encint.h \
+ enquant.h \
+ huffenc.h \
+ mathops.h \
+ modedec.h \
+ x86/x86enc.h \
+ apiwrapper.h \
+ bitpack.h \
+ dct.h \
+ decint.h \
+ dequant.h \
+ huffdec.h \
+ huffman.h \
+ ocintrin.h \
+ quant.h \
+ x86/mmxfrag.h \
+ x86/mmxloop.h \
+ x86/x86int.h
+
+libtheoradec_la_SOURCES = \
+ $(decoder_sources) \
+ Version_script-dec theoradec.exp
+libtheoradec_la_LDFLAGS = \
+ -version-info @THDEC_LIB_CURRENT@:@THDEC_LIB_REVISION@:@THDEC_LIB_AGE@ \
+ @THEORADEC_LDFLAGS@ @CAIRO_LIBS@ \
+ -no-undefined
+
+libtheoraenc_la_SOURCES = \
+ $(encoder_sources) \
+ Version_script-enc theoraenc.exp
+libtheoraenc_la_LDFLAGS = \
+ -version-info @THENC_LIB_CURRENT@:@THENC_LIB_REVISION@:@THENC_LIB_AGE@ \
+ @THEORAENC_LDFLAGS@ $(OGG_LIBS) \
+ -no-undefined
+libtheoraenc_la_LIBADD = libtheoradec.la
+
+libtheora_la_SOURCES = \
+ $(decoder_sources) \
+ $(encoder_uniq_sources) \
+ Version_script theora.exp
+libtheora_la_LDFLAGS = \
+ -version-info @TH_LIB_CURRENT@:@TH_LIB_REVISION@:@TH_LIB_AGE@ \
+ @THEORA_LDFLAGS@ @CAIRO_LIBS@ $(OGG_LIBS) \
+ -no-undefined
+
+debug:
+ $(MAKE) all CFLAGS="@DEBUG@"
+
+profile:
+ $(MAKE) all CFLAGS="@PROFILE@"
+
+# contstruct various symbol export list files
+.def.exp : defexp.awk
+ awk -f defexp.awk $< > $@
diff --git a/libs/libtheora-1.1/lib/Version_script b/libs/libtheora-1.1/lib/Version_script
new file mode 100644
index 00000000..2ecb5e43
--- /dev/null
+++ b/libs/libtheora-1.1/lib/Version_script
@@ -0,0 +1,53 @@
+#
+# Export file for libtheora
+#
+# Only the symbols listed in the global section will be callable from
+# applications linking to the libraries.
+#
+
+# We use something that looks like a versioned so filename here
+# to define the old API because of a historical confusion. This
+# label must be kept to maintain ABI compatibility.
+
+libtheora.so.1.0
+{
+ global:
+ theora_version_string;
+ theora_version_number;
+
+ theora_encode_init;
+ theora_encode_YUVin;
+ theora_encode_packetout;
+ theora_encode_header;
+ theora_encode_comment;
+ theora_encode_tables;
+
+ theora_decode_header;
+ theora_decode_init;
+ theora_decode_packetin;
+ theora_decode_YUVout;
+
+ theora_control;
+
+ theora_packet_isheader;
+ theora_packet_iskeyframe;
+
+ theora_granule_shift;
+ theora_granule_frame;
+ theora_granule_time;
+
+ theora_info_init;
+ theora_info_clear;
+
+ theora_clear;
+
+ theora_comment_init;
+ theora_comment_add;
+ theora_comment_add_tag;
+ theora_comment_query;
+ theora_comment_query_count;
+ theora_comment_clear;
+
+ local:
+ *;
+};
diff --git a/libs/libtheora-1.1/lib/Version_script-dec b/libs/libtheora-1.1/lib/Version_script-dec
new file mode 100644
index 00000000..cab36839
--- /dev/null
+++ b/libs/libtheora-1.1/lib/Version_script-dec
@@ -0,0 +1,82 @@
+#
+# Export file for libtheoradec
+#
+# Only the symbols listed in the global section will be callable from
+# applications linking to the libraries.
+#
+
+# The 1.x API
+libtheoradec_1.0
+{
+ global:
+ th_version_string;
+ th_version_number;
+
+ th_decode_headerin;
+ th_decode_alloc;
+ th_setup_free;
+ th_decode_ctl;
+ th_decode_packetin;
+ th_decode_ycbcr_out;
+ th_decode_free;
+
+ th_packet_isheader;
+ th_packet_iskeyframe;
+
+ th_granule_frame;
+ th_granule_time;
+
+ th_info_init;
+ th_info_clear;
+
+ th_comment_init;
+ th_comment_add;
+ th_comment_add_tag;
+ th_comment_query;
+ th_comment_query_count;
+ th_comment_clear;
+
+ local:
+ *;
+};
+
+# The deprecated legacy api from the libtheora alpha releases.
+# We use something that looks like a versioned so filename here
+# to define the old API because of a historical confusion. This
+# label must be kept to maintain ABI compatibility.
+
+libtheora.so.1.0
+{
+ global:
+ theora_version_string;
+ theora_version_number;
+
+ theora_decode_header;
+ theora_decode_init;
+ theora_decode_packetin;
+ theora_decode_YUVout;
+
+ theora_control;
+
+ theora_packet_isheader;
+ theora_packet_iskeyframe;
+
+ theora_granule_shift;
+ theora_granule_frame;
+ theora_granule_time;
+
+ theora_info_init;
+ theora_info_clear;
+
+ theora_clear;
+
+ theora_comment_init;
+ theora_comment_add;
+ theora_comment_add_tag;
+ theora_comment_query;
+ theora_comment_query_count;
+ theora_comment_clear;
+
+ local:
+ *;
+};
diff --git a/libs/libtheora-1.1/lib/Version_script-enc b/libs/libtheora-1.1/lib/Version_script-enc
new file mode 100644
index 00000000..37699edd
--- /dev/null
+++ b/libs/libtheora-1.1/lib/Version_script-enc
@@ -0,0 +1,43 @@
+#
+# Export file for libtheora
+#
+# Only the symbols listed in the global section will be callable from
+# applications linking to the libraries.
+#
+
+# The 1.x encoder API
+libtheoraenc_1.0
+{
+ global:
+ th_encode_alloc;
+ th_encode_ctl;
+ th_encode_flushheader;
+ th_encode_ycbcr_in;
+ th_encode_packetout;
+ th_encode_free;
+
+ TH_VP31_QUANT_INFO;
+ TH_VP31_HUFF_CODES;
+
+ local:
+ *;
+};
+
+# The encoder portion of the deprecated alpha release api.
+# We use something that looks like a versioned so filename here
+# to define the old API because of a historical confusion. This
+# label must be kept to maintain ABI compatibility.
+
+libtheora.so.1.0
+{
+ global:
+ theora_encode_init;
+ theora_encode_YUVin;
+ theora_encode_packetout;
+ theora_encode_header;
+ theora_encode_comment;
+ theora_encode_tables;
+
+ local:
+ *;
+};
diff --git a/libs/libtheora-1.1/lib/analyze.c b/libs/libtheora-1.1/lib/analyze.c
new file mode 100644
index 00000000..8a366c7a
--- /dev/null
+++ b/libs/libtheora-1.1/lib/analyze.c
@@ -0,0 +1,2701 @@
+/********************************************************************
+ * *
+ * THIS FILE IS PART OF THE OggTheora SOFTWARE CODEC SOURCE CODE. *
+ * USE, DISTRIBUTION AND REPRODUCTION OF THIS LIBRARY SOURCE IS *
+ * GOVERNED BY A BSD-STYLE SOURCE LICENSE INCLUDED WITH THIS SOURCE *
+ * IN 'COPYING'. PLEASE READ THESE TERMS BEFORE DISTRIBUTING. *
+ * *
+ * THE Theora SOURCE CODE IS COPYRIGHT (C) 2002-2009 *
+ * by the Xiph.Org Foundation http://www.xiph.org/ *
+ * *
+ ********************************************************************
+
+ function: mode selection code
+ last mod: $Id$
+
+ ********************************************************************/
+#include
+#include
+#include "encint.h"
+#include "modedec.h"
+
+
+
+typedef struct oc_fr_state oc_fr_state;
+typedef struct oc_qii_state oc_qii_state;
+typedef struct oc_enc_pipeline_state oc_enc_pipeline_state;
+typedef struct oc_rd_metric oc_rd_metric;
+typedef struct oc_mode_choice oc_mode_choice;
+
+
+
+/*There are 8 possible schemes used to encode macro block modes.
+ Schemes 0-6 use a maximally-skewed Huffman code to code each of the modes.
+ The same set of Huffman codes is used for each of these 7 schemes, but the
+ mode assigned to each codeword varies.
+ Scheme 0 writes a custom mapping from codeword to MB mode to the bitstream,
+ while schemes 1-6 have a fixed mapping.
+ Scheme 7 just encodes each mode directly in 3 bits.*/
+
+/*The mode orderings for the various mode coding schemes.
+ Scheme 0 uses a custom alphabet, which is not stored in this table.
+ This is the inverse of the equivalent table OC_MODE_ALPHABETS in the
+ decoder.*/
+static const unsigned char OC_MODE_RANKS[7][OC_NMODES]={
+ /*Last MV dominates.*/
+ /*L P M N I G GM 4*/
+ {3,4,2,0,1,5,6,7},
+ /*L P N M I G GM 4*/
+ {2,4,3,0,1,5,6,7},
+ /*L M P N I G GM 4*/
+ {3,4,1,0,2,5,6,7},
+ /*L M N P I G GM 4*/
+ {2,4,1,0,3,5,6,7},
+ /*No MV dominates.*/
+ /*N L P M I G GM 4*/
+ {0,4,3,1,2,5,6,7},
+ /*N G L P M I GM 4*/
+ {0,5,4,2,3,1,6,7},
+ /*Default ordering.*/
+ /*N I M L P G GM 4*/
+ {0,1,2,3,4,5,6,7}
+};
+
+
+
+/*Initialize the mode scheme chooser.
+ This need only be called once per encoder.*/
+void oc_mode_scheme_chooser_init(oc_mode_scheme_chooser *_chooser){
+ int si;
+ _chooser->mode_ranks[0]=_chooser->scheme0_ranks;
+ for(si=1;si<8;si++)_chooser->mode_ranks[si]=OC_MODE_RANKS[si-1];
+}
+
+/*Reset the mode scheme chooser.
+ This needs to be called once for each frame, including the first.*/
+static void oc_mode_scheme_chooser_reset(oc_mode_scheme_chooser *_chooser){
+ int si;
+ memset(_chooser->mode_counts,0,OC_NMODES*sizeof(*_chooser->mode_counts));
+ /*Scheme 0 starts with 24 bits to store the mode list in.*/
+ _chooser->scheme_bits[0]=24;
+ memset(_chooser->scheme_bits+1,0,7*sizeof(*_chooser->scheme_bits));
+ for(si=0;si<8;si++){
+ /*Scheme 7 should always start first, and scheme 0 should always start
+ last.*/
+ _chooser->scheme_list[si]=7-si;
+ _chooser->scheme0_list[si]=_chooser->scheme0_ranks[si]=si;
+ }
+}
+
+
+/*This is the real purpose of this data structure: not actually selecting a
+ mode scheme, but estimating the cost of coding a given mode given all the
+ modes selected so far.
+ This is done via opportunity cost: the cost is defined as the number of bits
+ required to encode all the modes selected so far including the current one
+ using the best possible scheme, minus the number of bits required to encode
+ all the modes selected so far not including the current one using the best
+ possible scheme.
+ The computational expense of doing this probably makes it overkill.
+ Just be happy we take a greedy approach instead of trying to solve the
+ global mode-selection problem (which is NP-hard).
+ _mb_mode: The mode to determine the cost of.
+ Return: The number of bits required to code this mode.*/
+static int oc_mode_scheme_chooser_cost(oc_mode_scheme_chooser *_chooser,
+ int _mb_mode){
+ int scheme0;
+ int scheme1;
+ int best_bits;
+ int mode_bits;
+ int si;
+ int scheme_bits;
+ scheme0=_chooser->scheme_list[0];
+ scheme1=_chooser->scheme_list[1];
+ best_bits=_chooser->scheme_bits[scheme0];
+ mode_bits=OC_MODE_BITS[scheme0+1>>3][_chooser->mode_ranks[scheme0][_mb_mode]];
+ /*Typical case: If the difference between the best scheme and the next best
+ is greater than 6 bits, then adding just one mode cannot change which
+ scheme we use.*/
+ if(_chooser->scheme_bits[scheme1]-best_bits>6)return mode_bits;
+ /*Otherwise, check to see if adding this mode selects a different scheme as
+ the best.*/
+ si=1;
+ best_bits+=mode_bits;
+ do{
+ /*For any scheme except 0, we can just use the bit cost of the mode's rank
+ in that scheme.*/
+ if(scheme1!=0){
+ scheme_bits=_chooser->scheme_bits[scheme1]+
+ OC_MODE_BITS[scheme1+1>>3][_chooser->mode_ranks[scheme1][_mb_mode]];
+ }
+ else{
+ int ri;
+ /*For scheme 0, incrementing the mode count could potentially change the
+ mode's rank.
+ Find the index where the mode would be moved to in the optimal list,
+ and use its bit cost instead of the one for the mode's current
+ position in the list.*/
+ /*We don't recompute scheme bits; this is computing opportunity cost, not
+ an update.*/
+ for(ri=_chooser->scheme0_ranks[_mb_mode];ri>0&&
+ _chooser->mode_counts[_mb_mode]>=
+ _chooser->mode_counts[_chooser->scheme0_list[ri-1]];ri--);
+ scheme_bits=_chooser->scheme_bits[0]+OC_MODE_BITS[0][ri];
+ }
+ if(scheme_bits=8)break;
+ scheme1=_chooser->scheme_list[si];
+ }
+ while(_chooser->scheme_bits[scheme1]-_chooser->scheme_bits[scheme0]<=6);
+ return best_bits-_chooser->scheme_bits[scheme0];
+}
+
+/*Incrementally update the mode counts and per-scheme bit counts and re-order
+ the scheme lists once a mode has been selected.
+ _mb_mode: The mode that was chosen.*/
+static void oc_mode_scheme_chooser_update(oc_mode_scheme_chooser *_chooser,
+ int _mb_mode){
+ int ri;
+ int si;
+ _chooser->mode_counts[_mb_mode]++;
+ /*Re-order the scheme0 mode list if necessary.*/
+ for(ri=_chooser->scheme0_ranks[_mb_mode];ri>0;ri--){
+ int pmode;
+ pmode=_chooser->scheme0_list[ri-1];
+ if(_chooser->mode_counts[pmode]>=_chooser->mode_counts[_mb_mode])break;
+ /*Reorder the mode ranking.*/
+ _chooser->scheme0_ranks[pmode]++;
+ _chooser->scheme0_list[ri]=pmode;
+ }
+ _chooser->scheme0_ranks[_mb_mode]=ri;
+ _chooser->scheme0_list[ri]=_mb_mode;
+ /*Now add the bit cost for the mode to each scheme.*/
+ for(si=0;si<8;si++){
+ _chooser->scheme_bits[si]+=
+ OC_MODE_BITS[si+1>>3][_chooser->mode_ranks[si][_mb_mode]];
+ }
+ /*Finally, re-order the list of schemes.*/
+ for(si=1;si<8;si++){
+ int sj;
+ int scheme0;
+ int bits0;
+ sj=si;
+ scheme0=_chooser->scheme_list[si];
+ bits0=_chooser->scheme_bits[scheme0];
+ do{
+ int scheme1;
+ scheme1=_chooser->scheme_list[sj-1];
+ if(bits0>=_chooser->scheme_bits[scheme1])break;
+ _chooser->scheme_list[sj]=scheme1;
+ }
+ while(--sj>0);
+ _chooser->scheme_list[sj]=scheme0;
+ }
+}
+
+
+
+/*The number of bits required to encode a super block run.
+ _run_count: The desired run count; must be positive and less than 4130.*/
+static int oc_sb_run_bits(int _run_count){
+ int i;
+ for(i=0;_run_count>=OC_SB_RUN_VAL_MIN[i+1];i++);
+ return OC_SB_RUN_CODE_NBITS[i];
+}
+
+/*The number of bits required to encode a block run.
+ _run_count: The desired run count; must be positive and less than 30.*/
+static int oc_block_run_bits(int _run_count){
+ return OC_BLOCK_RUN_CODE_NBITS[_run_count-1];
+}
+
+
+
+/*State to track coded block flags and their bit cost.*/
+struct oc_fr_state{
+ ptrdiff_t bits;
+ unsigned sb_partial_count:16;
+ unsigned sb_full_count:16;
+ unsigned b_coded_count_prev:8;
+ unsigned b_coded_count:8;
+ unsigned b_count:8;
+ signed int sb_partial:2;
+ signed int sb_full:2;
+ signed int b_coded_prev:2;
+ signed int b_coded:2;
+};
+
+
+
+static void oc_fr_state_init(oc_fr_state *_fr){
+ _fr->bits=0;
+ _fr->sb_partial_count=0;
+ _fr->sb_full_count=0;
+ _fr->b_coded_count_prev=0;
+ _fr->b_coded_count=0;
+ _fr->b_count=0;
+ _fr->sb_partial=-1;
+ _fr->sb_full=-1;
+ _fr->b_coded_prev=-1;
+ _fr->b_coded=-1;
+}
+
+
+static void oc_fr_state_advance_sb(oc_fr_state *_fr,
+ int _sb_partial,int _sb_full){
+ ptrdiff_t bits;
+ int sb_partial_count;
+ int sb_full_count;
+ bits=_fr->bits;
+ /*Extend the sb_partial run, or start a new one.*/
+ sb_partial_count=_fr->sb_partial;
+ if(_fr->sb_partial==_sb_partial){
+ if(sb_partial_count>=4129){
+ bits++;
+ sb_partial_count=0;
+ }
+ else bits-=oc_sb_run_bits(sb_partial_count);
+ }
+ else sb_partial_count=0;
+ sb_partial_count++;
+ bits+=oc_sb_run_bits(sb_partial_count);
+ if(!_sb_partial){
+ /*Extend the sb_full run, or start a new one.*/
+ sb_full_count=_fr->sb_full_count;
+ if(_fr->sb_full==_sb_full){
+ if(sb_full_count>=4129){
+ bits++;
+ sb_full_count=0;
+ }
+ else bits-=oc_sb_run_bits(sb_full_count);
+ }
+ else sb_full_count=0;
+ sb_full_count++;
+ bits+=oc_sb_run_bits(sb_full_count);
+ _fr->sb_full=_sb_full;
+ _fr->sb_full_count=sb_full_count;
+ }
+ _fr->bits=bits;
+ _fr->sb_partial=_sb_partial;
+ _fr->sb_partial_count=sb_partial_count;
+}
+
+/*Flush any outstanding block flags for a SB (e.g., one with fewer than 16
+ blocks).*/
+static void oc_fr_state_flush_sb(oc_fr_state *_fr){
+ ptrdiff_t bits;
+ int sb_partial;
+ int sb_full=sb_full;
+ int b_coded_count;
+ int b_coded;
+ int b_count;
+ b_count=_fr->b_count;
+ if(b_count>0){
+ bits=_fr->bits;
+ b_coded=_fr->b_coded;
+ b_coded_count=_fr->b_coded_count;
+ if(b_coded_count>=b_count){
+ /*This SB was fully coded/uncoded; roll back the partial block flags.*/
+ bits-=oc_block_run_bits(b_coded_count);
+ if(b_coded_count>b_count)bits+=oc_block_run_bits(b_coded_count-b_count);
+ sb_partial=0;
+ sb_full=b_coded;
+ b_coded=_fr->b_coded_prev;
+ b_coded_count=_fr->b_coded_count_prev;
+ }
+ else{
+ /*It was partially coded.*/
+ sb_partial=1;
+ /*sb_full is unused.*/
+ }
+ _fr->bits=bits;
+ _fr->b_coded_count=b_coded_count;
+ _fr->b_coded_count_prev=b_coded_count;
+ _fr->b_count=0;
+ _fr->b_coded=b_coded;
+ _fr->b_coded_prev=b_coded;
+ oc_fr_state_advance_sb(_fr,sb_partial,sb_full);
+ }
+}
+
+static void oc_fr_state_advance_block(oc_fr_state *_fr,int _b_coded){
+ ptrdiff_t bits;
+ int b_coded_count;
+ int b_count;
+ int sb_partial;
+ int sb_full=sb_full;
+ bits=_fr->bits;
+ /*Extend the b_coded run, or start a new one.*/
+ b_coded_count=_fr->b_coded_count;
+ if(_fr->b_coded==_b_coded)bits-=oc_block_run_bits(b_coded_count);
+ else b_coded_count=0;
+ b_coded_count++;
+ b_count=_fr->b_count+1;
+ if(b_count>=16){
+ /*We finished a superblock.*/
+ if(b_coded_count>=16){
+ /*It was fully coded/uncoded; roll back the partial block flags.*/
+ if(b_coded_count>16)bits+=oc_block_run_bits(b_coded_count-16);
+ sb_partial=0;
+ sb_full=_b_coded;
+ _b_coded=_fr->b_coded_prev;
+ b_coded_count=_fr->b_coded_count_prev;
+ }
+ else{
+ bits+=oc_block_run_bits(b_coded_count);
+ /*It was partially coded.*/
+ sb_partial=1;
+ /*sb_full is unused.*/
+ }
+ _fr->bits=bits;
+ _fr->b_coded_count=b_coded_count;
+ _fr->b_coded_count_prev=b_coded_count;
+ _fr->b_count=0;
+ _fr->b_coded=_b_coded;
+ _fr->b_coded_prev=_b_coded;
+ oc_fr_state_advance_sb(_fr,sb_partial,sb_full);
+ }
+ else{
+ bits+=oc_block_run_bits(b_coded_count);
+ _fr->bits=bits;
+ _fr->b_coded_count=b_coded_count;
+ _fr->b_count=b_count;
+ _fr->b_coded=_b_coded;
+ }
+}
+
+static void oc_fr_skip_block(oc_fr_state *_fr){
+ oc_fr_state_advance_block(_fr,0);
+}
+
+static void oc_fr_code_block(oc_fr_state *_fr){
+ oc_fr_state_advance_block(_fr,1);
+}
+
+static int oc_fr_cost1(const oc_fr_state *_fr){
+ oc_fr_state tmp;
+ ptrdiff_t bits;
+ *&tmp=*_fr;
+ oc_fr_skip_block(&tmp);
+ bits=tmp.bits;
+ *&tmp=*_fr;
+ oc_fr_code_block(&tmp);
+ return (int)(tmp.bits-bits);
+}
+
+static int oc_fr_cost4(const oc_fr_state *_pre,const oc_fr_state *_post){
+ oc_fr_state tmp;
+ *&tmp=*_pre;
+ oc_fr_skip_block(&tmp);
+ oc_fr_skip_block(&tmp);
+ oc_fr_skip_block(&tmp);
+ oc_fr_skip_block(&tmp);
+ return (int)(_post->bits-tmp.bits);
+}
+
+
+
+struct oc_qii_state{
+ ptrdiff_t bits;
+ unsigned qi01_count:14;
+ signed int qi01:2;
+ unsigned qi12_count:14;
+ signed int qi12:2;
+};
+
+
+
+static void oc_qii_state_init(oc_qii_state *_qs){
+ _qs->bits=0;
+ _qs->qi01_count=0;
+ _qs->qi01=-1;
+ _qs->qi12_count=0;
+ _qs->qi12=-1;
+}
+
+
+static void oc_qii_state_advance(oc_qii_state *_qd,
+ const oc_qii_state *_qs,int _qii){
+ ptrdiff_t bits;
+ int qi01;
+ int qi01_count;
+ int qi12;
+ int qi12_count;
+ bits=_qs->bits;
+ qi01=_qii+1>>1;
+ qi01_count=_qs->qi01_count;
+ if(qi01==_qs->qi01){
+ if(qi01_count>=4129){
+ bits++;
+ qi01_count=0;
+ }
+ else bits-=oc_sb_run_bits(qi01_count);
+ }
+ else qi01_count=0;
+ qi01_count++;
+ bits+=oc_sb_run_bits(qi01_count);
+ qi12_count=_qs->qi12_count;
+ if(_qii){
+ qi12=_qii>>1;
+ if(qi12==_qs->qi12){
+ if(qi12_count>=4129){
+ bits++;
+ qi12_count=0;
+ }
+ else bits-=oc_sb_run_bits(qi12_count);
+ }
+ else qi12_count=0;
+ qi12_count++;
+ bits+=oc_sb_run_bits(qi12_count);
+ }
+ else qi12=_qs->qi12;
+ _qd->bits=bits;
+ _qd->qi01=qi01;
+ _qd->qi01_count=qi01_count;
+ _qd->qi12=qi12;
+ _qd->qi12_count=qi12_count;
+}
+
+
+
+/*Temporary encoder state for the analysis pipeline.*/
+struct oc_enc_pipeline_state{
+ int bounding_values[256];
+ oc_fr_state fr[3];
+ oc_qii_state qs[3];
+ /*Condensed dequantization tables.*/
+ const ogg_uint16_t *dequant[3][3][2];
+ /*Condensed quantization tables.*/
+ const oc_iquant *enquant[3][3][2];
+ /*Skip SSD storage for the current MCU in each plane.*/
+ unsigned *skip_ssd[3];
+ /*Coded/uncoded fragment lists for each plane for the current MCU.*/
+ ptrdiff_t *coded_fragis[3];
+ ptrdiff_t *uncoded_fragis[3];
+ ptrdiff_t ncoded_fragis[3];
+ ptrdiff_t nuncoded_fragis[3];
+ /*The starting fragment for the current MCU in each plane.*/
+ ptrdiff_t froffset[3];
+ /*The starting row for the current MCU in each plane.*/
+ int fragy0[3];
+ /*The ending row for the current MCU in each plane.*/
+ int fragy_end[3];
+ /*The starting superblock for the current MCU in each plane.*/
+ unsigned sbi0[3];
+ /*The ending superblock for the current MCU in each plane.*/
+ unsigned sbi_end[3];
+ /*The number of tokens for zzi=1 for each color plane.*/
+ int ndct_tokens1[3];
+ /*The outstanding eob_run count for zzi=1 for each color plane.*/
+ int eob_run1[3];
+ /*Whether or not the loop filter is enabled.*/
+ int loop_filter;
+};
+
+
+static void oc_enc_pipeline_init(oc_enc_ctx *_enc,oc_enc_pipeline_state *_pipe){
+ ptrdiff_t *coded_fragis;
+ unsigned mcu_nvsbs;
+ ptrdiff_t mcu_nfrags;
+ int hdec;
+ int vdec;
+ int pli;
+ int qii;
+ int qti;
+ /*Initialize the per-plane coded block flag trackers.
+ These are used for bit-estimation purposes only; the real flag bits span
+ all three planes, so we can't compute them in parallel.*/
+ for(pli=0;pli<3;pli++)oc_fr_state_init(_pipe->fr+pli);
+ for(pli=0;pli<3;pli++)oc_qii_state_init(_pipe->qs+pli);
+ /*Set up the per-plane skip SSD storage pointers.*/
+ mcu_nvsbs=_enc->mcu_nvsbs;
+ mcu_nfrags=mcu_nvsbs*_enc->state.fplanes[0].nhsbs*16;
+ hdec=!(_enc->state.info.pixel_fmt&1);
+ vdec=!(_enc->state.info.pixel_fmt&2);
+ _pipe->skip_ssd[0]=_enc->mcu_skip_ssd;
+ _pipe->skip_ssd[1]=_pipe->skip_ssd[0]+mcu_nfrags;
+ _pipe->skip_ssd[2]=_pipe->skip_ssd[1]+(mcu_nfrags>>hdec+vdec);
+ /*Set up per-plane pointers to the coded and uncoded fragments lists.
+ Unlike the decoder, each planes' coded and uncoded fragment list is kept
+ separate during the analysis stage; we only make the coded list for all
+ three planes contiguous right before the final packet is output
+ (destroying the uncoded lists, which are no longer needed).*/
+ coded_fragis=_enc->state.coded_fragis;
+ for(pli=0;pli<3;pli++){
+ _pipe->coded_fragis[pli]=coded_fragis;
+ coded_fragis+=_enc->state.fplanes[pli].nfrags;
+ _pipe->uncoded_fragis[pli]=coded_fragis;
+ }
+ memset(_pipe->ncoded_fragis,0,sizeof(_pipe->ncoded_fragis));
+ memset(_pipe->nuncoded_fragis,0,sizeof(_pipe->nuncoded_fragis));
+ /*Set up condensed quantizer tables.*/
+ for(pli=0;pli<3;pli++){
+ for(qii=0;qii<_enc->state.nqis;qii++){
+ int qi;
+ qi=_enc->state.qis[qii];
+ for(qti=0;qti<2;qti++){
+ _pipe->dequant[pli][qii][qti]=_enc->state.dequant_tables[qi][pli][qti];
+ _pipe->enquant[pli][qii][qti]=_enc->enquant_tables[qi][pli][qti];
+ }
+ }
+ }
+ /*Initialize the tokenization state.*/
+ for(pli=0;pli<3;pli++){
+ _pipe->ndct_tokens1[pli]=0;
+ _pipe->eob_run1[pli]=0;
+ }
+ /*Initialize the bounding value array for the loop filter.*/
+ _pipe->loop_filter=!oc_state_loop_filter_init(&_enc->state,
+ _pipe->bounding_values);
+}
+
+/*Sets the current MCU stripe to super block row _sby.
+ Return: A non-zero value if this was the last MCU.*/
+static int oc_enc_pipeline_set_stripe(oc_enc_ctx *_enc,
+ oc_enc_pipeline_state *_pipe,int _sby){
+ const oc_fragment_plane *fplane;
+ unsigned mcu_nvsbs;
+ int sby_end;
+ int notdone;
+ int vdec;
+ int pli;
+ mcu_nvsbs=_enc->mcu_nvsbs;
+ sby_end=_enc->state.fplanes[0].nvsbs;
+ notdone=_sby+mcu_nvsbsstate.fplanes+pli;
+ _pipe->sbi0[pli]=fplane->sboffset+(_sby>>vdec)*fplane->nhsbs;
+ _pipe->fragy0[pli]=_sby<<2-vdec;
+ _pipe->froffset[pli]=fplane->froffset
+ +_pipe->fragy0[pli]*(ptrdiff_t)fplane->nhfrags;
+ if(notdone){
+ _pipe->sbi_end[pli]=fplane->sboffset+(sby_end>>vdec)*fplane->nhsbs;
+ _pipe->fragy_end[pli]=sby_end<<2-vdec;
+ }
+ else{
+ _pipe->sbi_end[pli]=fplane->sboffset+fplane->nsbs;
+ _pipe->fragy_end[pli]=fplane->nvfrags;
+ }
+ vdec=!(_enc->state.info.pixel_fmt&2);
+ }
+ return notdone;
+}
+
+static void oc_enc_pipeline_finish_mcu_plane(oc_enc_ctx *_enc,
+ oc_enc_pipeline_state *_pipe,int _pli,int _sdelay,int _edelay){
+ int refi;
+ /*Copy over all the uncoded fragments from this plane and advance the uncoded
+ fragment list.*/
+ _pipe->uncoded_fragis[_pli]-=_pipe->nuncoded_fragis[_pli];
+ oc_state_frag_copy_list(&_enc->state,_pipe->uncoded_fragis[_pli],
+ _pipe->nuncoded_fragis[_pli],OC_FRAME_SELF,OC_FRAME_PREV,_pli);
+ _pipe->nuncoded_fragis[_pli]=0;
+ /*Perform DC prediction.*/
+ oc_enc_pred_dc_frag_rows(_enc,_pli,
+ _pipe->fragy0[_pli],_pipe->fragy_end[_pli]);
+ /*Finish DC tokenization.*/
+ oc_enc_tokenize_dc_frag_list(_enc,_pli,
+ _pipe->coded_fragis[_pli],_pipe->ncoded_fragis[_pli],
+ _pipe->ndct_tokens1[_pli],_pipe->eob_run1[_pli]);
+ _pipe->ndct_tokens1[_pli]=_enc->ndct_tokens[_pli][1];
+ _pipe->eob_run1[_pli]=_enc->eob_run[_pli][1];
+ /*And advance the coded fragment list.*/
+ _enc->state.ncoded_fragis[_pli]+=_pipe->ncoded_fragis[_pli];
+ _pipe->coded_fragis[_pli]+=_pipe->ncoded_fragis[_pli];
+ _pipe->ncoded_fragis[_pli]=0;
+ /*Apply the loop filter if necessary.*/
+ refi=_enc->state.ref_frame_idx[OC_FRAME_SELF];
+ if(_pipe->loop_filter){
+ oc_state_loop_filter_frag_rows(&_enc->state,_pipe->bounding_values,
+ refi,_pli,_pipe->fragy0[_pli]-_sdelay,_pipe->fragy_end[_pli]-_edelay);
+ }
+ else _sdelay=_edelay=0;
+ /*To fill borders, we have an additional two pixel delay, since a fragment
+ in the next row could filter its top edge, using two pixels from a
+ fragment in this row.
+ But there's no reason to delay a full fragment between the two.*/
+ oc_state_borders_fill_rows(&_enc->state,refi,_pli,
+ (_pipe->fragy0[_pli]-_sdelay<<3)-(_sdelay<<1),
+ (_pipe->fragy_end[_pli]-_edelay<<3)-(_edelay<<1));
+}
+
+
+
+/*Cost information about the coded blocks in a MB.*/
+struct oc_rd_metric{
+ int uncoded_ac_ssd;
+ int coded_ac_ssd;
+ int ac_bits;
+ int dc_flag;
+};
+
+
+
+static int oc_enc_block_transform_quantize(oc_enc_ctx *_enc,
+ oc_enc_pipeline_state *_pipe,int _pli,ptrdiff_t _fragi,int _overhead_bits,
+ oc_rd_metric *_mo,oc_token_checkpoint **_stack){
+ OC_ALIGN16(ogg_int16_t dct[64]);
+ OC_ALIGN16(ogg_int16_t data[64]);
+ ogg_uint16_t dc_dequant;
+ const ogg_uint16_t *dequant;
+ const oc_iquant *enquant;
+ ptrdiff_t frag_offs;
+ int ystride;
+ const unsigned char *src;
+ const unsigned char *ref;
+ unsigned char *dst;
+ int frame_type;
+ int nonzero;
+ unsigned uncoded_ssd;
+ unsigned coded_ssd;
+ int coded_dc;
+ oc_token_checkpoint *checkpoint;
+ oc_fragment *frags;
+ int mb_mode;
+ int mv_offs[2];
+ int nmv_offs;
+ int ac_bits;
+ int borderi;
+ int qti;
+ int qii;
+ int pi;
+ int zzi;
+ int v;
+ int val;
+ int d;
+ int s;
+ int dc;
+ frags=_enc->state.frags;
+ frag_offs=_enc->state.frag_buf_offs[_fragi];
+ ystride=_enc->state.ref_ystride[_pli];
+ src=_enc->state.ref_frame_data[OC_FRAME_IO]+frag_offs;
+ borderi=frags[_fragi].borderi;
+ qii=frags[_fragi].qii;
+ if(qii&~3){
+#if !defined(OC_COLLECT_METRICS)
+ if(_enc->sp_level>=OC_SP_LEVEL_EARLY_SKIP){
+ /*Enable early skip detection.*/
+ frags[_fragi].coded=0;
+ return 0;
+ }
+#endif
+ /*Try and code this block anyway.*/
+ qii&=3;
+ frags[_fragi].qii=qii;
+ }
+ mb_mode=frags[_fragi].mb_mode;
+ ref=_enc->state.ref_frame_data[
+ _enc->state.ref_frame_idx[OC_FRAME_FOR_MODE(mb_mode)]]+frag_offs;
+ dst=_enc->state.ref_frame_data[_enc->state.ref_frame_idx[OC_FRAME_SELF]]
+ +frag_offs;
+ /*Motion compensation:*/
+ switch(mb_mode){
+ case OC_MODE_INTRA:{
+ nmv_offs=0;
+ oc_enc_frag_sub_128(_enc,data,src,ystride);
+ }break;
+ case OC_MODE_GOLDEN_NOMV:
+ case OC_MODE_INTER_NOMV:{
+ nmv_offs=1;
+ mv_offs[0]=0;
+ oc_enc_frag_sub(_enc,data,src,ref,ystride);
+ }break;
+ default:{
+ const oc_mv *frag_mvs;
+ frag_mvs=(const oc_mv *)_enc->state.frag_mvs;
+ nmv_offs=oc_state_get_mv_offsets(&_enc->state,mv_offs,_pli,
+ frag_mvs[_fragi][0],frag_mvs[_fragi][1]);
+ if(nmv_offs>1){
+ oc_enc_frag_copy2(_enc,dst,
+ ref+mv_offs[0],ref+mv_offs[1],ystride);
+ oc_enc_frag_sub(_enc,data,src,dst,ystride);
+ }
+ else oc_enc_frag_sub(_enc,data,src,ref+mv_offs[0],ystride);
+ }break;
+ }
+#if defined(OC_COLLECT_METRICS)
+ {
+ unsigned satd;
+ switch(nmv_offs){
+ case 0:satd=oc_enc_frag_intra_satd(_enc,src,ystride);break;
+ case 1:{
+ satd=oc_enc_frag_satd_thresh(_enc,src,ref+mv_offs[0],ystride,UINT_MAX);
+ }break;
+ default:{
+ satd=oc_enc_frag_satd_thresh(_enc,src,dst,ystride,UINT_MAX);
+ }
+ }
+ _enc->frag_satd[_fragi]=satd;
+ }
+#endif
+ /*Transform:*/
+ oc_enc_fdct8x8(_enc,dct,data);
+ /*Quantize the DC coefficient:*/
+ qti=mb_mode!=OC_MODE_INTRA;
+ enquant=_pipe->enquant[_pli][0][qti];
+ dc_dequant=_pipe->dequant[_pli][0][qti][0];
+ v=dct[0];
+ val=v<<1;
+ s=OC_SIGNMASK(val);
+ val+=dc_dequant+s^s;
+ val=((enquant[0].m*(ogg_int32_t)val>>16)+val>>enquant[0].l)-s;
+ dc=OC_CLAMPI(-580,val,580);
+ nonzero=0;
+ /*Quantize the AC coefficients:*/
+ dequant=_pipe->dequant[_pli][qii][qti];
+ enquant=_pipe->enquant[_pli][qii][qti];
+ for(zzi=1;zzi<64;zzi++){
+ v=dct[OC_FZIG_ZAG[zzi]];
+ d=dequant[zzi];
+ val=v<<1;
+ v=abs(val);
+ if(v>=d){
+ s=OC_SIGNMASK(val);
+ /*The bias added here rounds ties away from zero, since token
+ optimization can only decrease the magnitude of the quantized
+ value.*/
+ val+=d+s^s;
+ /*Note the arithmetic right shift is not guaranteed by ANSI C.
+ Hopefully no one still uses ones-complement architectures.*/
+ val=((enquant[zzi].m*(ogg_int32_t)val>>16)+val>>enquant[zzi].l)-s;
+ data[zzi]=OC_CLAMPI(-580,val,580);
+ nonzero=zzi;
+ }
+ else data[zzi]=0;
+ }
+ /*Tokenize.*/
+ checkpoint=*_stack;
+ ac_bits=oc_enc_tokenize_ac(_enc,_pli,_fragi,data,dequant,dct,nonzero+1,
+ _stack,qti?0:3);
+ /*Reconstruct.
+ TODO: nonzero may need to be adjusted after tokenization.*/
+ if(nonzero==0){
+ ogg_int16_t p;
+ int ci;
+ /*We round this dequant product (and not any of the others) because there's
+ no iDCT rounding.*/
+ p=(ogg_int16_t)(dc*(ogg_int32_t)dc_dequant+15>>5);
+ /*LOOP VECTORIZES.*/
+ for(ci=0;ci<64;ci++)data[ci]=p;
+ }
+ else{
+ data[0]=dc*dc_dequant;
+ oc_idct8x8(&_enc->state,data,nonzero+1);
+ }
+ if(!qti)oc_enc_frag_recon_intra(_enc,dst,ystride,data);
+ else{
+ oc_enc_frag_recon_inter(_enc,dst,
+ nmv_offs==1?ref+mv_offs[0]:dst,ystride,data);
+ }
+ frame_type=_enc->state.frame_type;
+#if !defined(OC_COLLECT_METRICS)
+ if(frame_type!=OC_INTRA_FRAME)
+#endif
+ {
+ /*In retrospect, should we have skipped this block?*/
+ oc_enc_frag_sub(_enc,data,src,dst,ystride);
+ coded_ssd=coded_dc=0;
+ if(borderi<0){
+ for(pi=0;pi<64;pi++){
+ coded_ssd+=data[pi]*data[pi];
+ coded_dc+=data[pi];
+ }
+ }
+ else{
+ ogg_int64_t mask;
+ mask=_enc->state.borders[borderi].mask;
+ for(pi=0;pi<64;pi++,mask>>=1)if(mask&1){
+ coded_ssd+=data[pi]*data[pi];
+ coded_dc+=data[pi];
+ }
+ }
+ /*Scale to match DCT domain.*/
+ coded_ssd<<=4;
+ /*We actually only want the AC contribution to the SSD.*/
+ coded_ssd-=coded_dc*coded_dc>>2;
+#if defined(OC_COLLECT_METRICS)
+ _enc->frag_ssd[_fragi]=coded_ssd;
+ }
+ if(frame_type!=OC_INTRA_FRAME){
+#endif
+ uncoded_ssd=_pipe->skip_ssd[_pli][_fragi-_pipe->froffset[_pli]];
+ if(uncoded_ssdlambda&&
+ /*Don't allow luma blocks to be skipped in 4MV mode when VP3
+ compatibility is enabled.*/
+ (!_enc->vp3_compatible||mb_mode!=OC_MODE_INTER_MV_FOUR||_pli)){
+ /*Hm, not worth it; roll back.*/
+ oc_enc_tokenlog_rollback(_enc,checkpoint,(*_stack)-checkpoint);
+ *_stack=checkpoint;
+ frags[_fragi].coded=0;
+ return 0;
+ }
+ }
+ else _mo->dc_flag=1;
+ _mo->uncoded_ac_ssd+=uncoded_ssd;
+ _mo->coded_ac_ssd+=coded_ssd;
+ _mo->ac_bits+=ac_bits;
+ }
+ oc_qii_state_advance(_pipe->qs+_pli,_pipe->qs+_pli,qii);
+ frags[_fragi].dc=dc;
+ frags[_fragi].coded=1;
+ return 1;
+}
+
+static int oc_enc_mb_transform_quantize_luma(oc_enc_ctx *_enc,
+ oc_enc_pipeline_state *_pipe,unsigned _mbi,int _mode_overhead){
+ /*Worst case token stack usage for 4 fragments.*/
+ oc_token_checkpoint stack[64*4];
+ oc_token_checkpoint *stackptr;
+ const oc_sb_map *sb_maps;
+ signed char *mb_modes;
+ oc_fragment *frags;
+ ptrdiff_t *coded_fragis;
+ ptrdiff_t ncoded_fragis;
+ ptrdiff_t *uncoded_fragis;
+ ptrdiff_t nuncoded_fragis;
+ oc_rd_metric mo;
+ oc_fr_state fr_checkpoint;
+ oc_qii_state qs_checkpoint;
+ int mb_mode;
+ int ncoded;
+ ptrdiff_t fragi;
+ int bi;
+ *&fr_checkpoint=*(_pipe->fr+0);
+ *&qs_checkpoint=*(_pipe->qs+0);
+ sb_maps=(const oc_sb_map *)_enc->state.sb_maps;
+ mb_modes=_enc->state.mb_modes;
+ frags=_enc->state.frags;
+ coded_fragis=_pipe->coded_fragis[0];
+ ncoded_fragis=_pipe->ncoded_fragis[0];
+ uncoded_fragis=_pipe->uncoded_fragis[0];
+ nuncoded_fragis=_pipe->nuncoded_fragis[0];
+ mb_mode=mb_modes[_mbi];
+ ncoded=0;
+ stackptr=stack;
+ memset(&mo,0,sizeof(mo));
+ for(bi=0;bi<4;bi++){
+ fragi=sb_maps[_mbi>>2][_mbi&3][bi];
+ frags[fragi].mb_mode=mb_mode;
+ if(oc_enc_block_transform_quantize(_enc,
+ _pipe,0,fragi,oc_fr_cost1(_pipe->fr+0),&mo,&stackptr)){
+ oc_fr_code_block(_pipe->fr+0);
+ coded_fragis[ncoded_fragis++]=fragi;
+ ncoded++;
+ }
+ else{
+ *(uncoded_fragis-++nuncoded_fragis)=fragi;
+ oc_fr_skip_block(_pipe->fr+0);
+ }
+ }
+ if(_enc->state.frame_type!=OC_INTRA_FRAME){
+ if(ncoded>0&&!mo.dc_flag){
+ int cost;
+ /*Some individual blocks were worth coding.
+ See if that's still true when accounting for mode and MV overhead.*/
+ cost=mo.coded_ac_ssd+_enc->lambda*(mo.ac_bits
+ +oc_fr_cost4(&fr_checkpoint,_pipe->fr+0)+_mode_overhead);
+ if(mo.uncoded_ac_ssd<=cost){
+ /*Taking macroblock overhead into account, it is not worth coding this
+ MB.*/
+ oc_enc_tokenlog_rollback(_enc,stack,stackptr-stack);
+ *(_pipe->fr+0)=*&fr_checkpoint;
+ *(_pipe->qs+0)=*&qs_checkpoint;
+ for(bi=0;bi<4;bi++){
+ fragi=sb_maps[_mbi>>2][_mbi&3][bi];
+ if(frags[fragi].coded){
+ *(uncoded_fragis-++nuncoded_fragis)=fragi;
+ frags[fragi].coded=0;
+ }
+ oc_fr_skip_block(_pipe->fr+0);
+ }
+ ncoded_fragis-=ncoded;
+ ncoded=0;
+ }
+ }
+ /*If no luma blocks coded, the mode is forced.*/
+ if(ncoded==0)mb_modes[_mbi]=OC_MODE_INTER_NOMV;
+ /*Assume that a 1MV with a single coded block is always cheaper than a 4MV
+ with a single coded block.
+ This may not be strictly true: a 4MV computes chroma MVs using (0,0) for
+ skipped blocks, while a 1MV does not.*/
+ else if(ncoded==1&&mb_mode==OC_MODE_INTER_MV_FOUR){
+ mb_modes[_mbi]=OC_MODE_INTER_MV;
+ }
+ }
+ _pipe->ncoded_fragis[0]=ncoded_fragis;
+ _pipe->nuncoded_fragis[0]=nuncoded_fragis;
+ return ncoded;
+}
+
+static void oc_enc_sb_transform_quantize_chroma(oc_enc_ctx *_enc,
+ oc_enc_pipeline_state *_pipe,int _pli,int _sbi_start,int _sbi_end){
+ const oc_sb_map *sb_maps;
+ oc_sb_flags *sb_flags;
+ ptrdiff_t *coded_fragis;
+ ptrdiff_t ncoded_fragis;
+ ptrdiff_t *uncoded_fragis;
+ ptrdiff_t nuncoded_fragis;
+ int sbi;
+ sb_maps=(const oc_sb_map *)_enc->state.sb_maps;
+ sb_flags=_enc->state.sb_flags;
+ coded_fragis=_pipe->coded_fragis[_pli];
+ ncoded_fragis=_pipe->ncoded_fragis[_pli];
+ uncoded_fragis=_pipe->uncoded_fragis[_pli];
+ nuncoded_fragis=_pipe->nuncoded_fragis[_pli];
+ for(sbi=_sbi_start;sbi<_sbi_end;sbi++){
+ /*Worst case token stack usage for 1 fragment.*/
+ oc_token_checkpoint stack[64];
+ oc_rd_metric mo;
+ int quadi;
+ int bi;
+ memset(&mo,0,sizeof(mo));
+ for(quadi=0;quadi<4;quadi++)for(bi=0;bi<4;bi++){
+ ptrdiff_t fragi;
+ fragi=sb_maps[sbi][quadi][bi];
+ if(fragi>=0){
+ oc_token_checkpoint *stackptr;
+ stackptr=stack;
+ if(oc_enc_block_transform_quantize(_enc,
+ _pipe,_pli,fragi,oc_fr_cost1(_pipe->fr+_pli),&mo,&stackptr)){
+ coded_fragis[ncoded_fragis++]=fragi;
+ oc_fr_code_block(_pipe->fr+_pli);
+ }
+ else{
+ *(uncoded_fragis-++nuncoded_fragis)=fragi;
+ oc_fr_skip_block(_pipe->fr+_pli);
+ }
+ }
+ }
+ oc_fr_state_flush_sb(_pipe->fr+_pli);
+ sb_flags[sbi].coded_fully=_pipe->fr[_pli].sb_full;
+ sb_flags[sbi].coded_partially=_pipe->fr[_pli].sb_partial;
+ }
+ _pipe->ncoded_fragis[_pli]=ncoded_fragis;
+ _pipe->nuncoded_fragis[_pli]=nuncoded_fragis;
+}
+
+/*Mode decision is done by exhaustively examining all potential choices.
+ Obviously, doing the motion compensation, fDCT, tokenization, and then
+ counting the bits each token uses is computationally expensive.
+ Theora's EOB runs can also split the cost of these tokens across multiple
+ fragments, and naturally we don't know what the optimal choice of Huffman
+ codes will be until we know all the tokens we're going to encode in all the
+ fragments.
+ So we use a simple approach to estimating the bit cost and distortion of each
+ mode based upon the SATD value of the residual before coding.
+ The mathematics behind the technique are outlined by Kim \cite{Kim03}, but
+ the process (modified somewhat from that of the paper) is very simple.
+ We build a non-linear regression of the mappings from
+ (pre-transform+quantization) SATD to (post-transform+quantization) bits and
+ SSD for each qi.
+ A separate set of mappings is kept for each quantization type and color
+ plane.
+ The mappings are constructed by partitioning the SATD values into a small
+ number of bins (currently 24) and using a linear regression in each bin
+ (as opposed to the 0th-order regression used by Kim).
+ The bit counts and SSD measurements are obtained by examining actual encoded
+ frames, with appropriate lambda values and optimal Huffman codes selected.
+ EOB bits are assigned to the fragment that started the EOB run (as opposed to
+ dividing them among all the blocks in the run; though the latter approach
+ seems more theoretically correct, Monty's testing showed a small improvement
+ with the former, though that may have been merely statistical noise).
+
+ @ARTICLE{Kim03,
+ author="Hyun Mun Kim",
+ title="Adaptive Rate Control Using Nonlinear Regression",
+ journal="IEEE Transactions on Circuits and Systems for Video Technology",
+ volume=13,
+ number=5,
+ pages="432--439",
+ month=May,
+ year=2003
+ }*/
+
+/*Computes (_ssd+_lambda*_rate)/(1<>OC_BIT_SCALE)+((_rate)>>OC_BIT_SCALE)*(_lambda) \
+ +(((_ssd)&(1<>1)>>OC_BIT_SCALE)
+
+/*Estimate the R-D cost of the DCT coefficients given the SATD of a block after
+ prediction.*/
+static unsigned oc_dct_cost2(unsigned *_ssd,
+ int _qi,int _pli,int _qti,int _satd){
+ unsigned rmse;
+ int bin;
+ int dx;
+ int y0;
+ int z0;
+ int dy;
+ int dz;
+ /*SATD metrics for chroma planes vary much less than luma, so we scale them
+ by 4 to distribute them into the mode decision bins more evenly.*/
+ _satd<<=_pli+1&2;
+ bin=OC_MINI(_satd>>OC_SAD_SHIFT,OC_SAD_BINS-2);
+ dx=_satd-(bin<>OC_SAD_SHIFT),0);
+ *_ssd=rmse*rmse>>2*OC_RMSE_SCALE-OC_BIT_SCALE;
+ return OC_MAXI(y0+(dy*dx>>OC_SAD_SHIFT),0);
+}
+
+/*Select luma block-level quantizers for a MB in an INTRA frame.*/
+static unsigned oc_analyze_intra_mb_luma(oc_enc_ctx *_enc,
+ const oc_qii_state *_qs,unsigned _mbi){
+ const unsigned char *src;
+ const ptrdiff_t *frag_buf_offs;
+ const oc_sb_map *sb_maps;
+ oc_fragment *frags;
+ ptrdiff_t frag_offs;
+ ptrdiff_t fragi;
+ oc_qii_state qs[4][3];
+ unsigned cost[4][3];
+ unsigned ssd[4][3];
+ unsigned rate[4][3];
+ int prev[3][3];
+ unsigned satd;
+ unsigned best_cost;
+ unsigned best_ssd;
+ unsigned best_rate;
+ int best_qii;
+ int qii;
+ int lambda;
+ int ystride;
+ int nqis;
+ int bi;
+ frag_buf_offs=_enc->state.frag_buf_offs;
+ sb_maps=(const oc_sb_map *)_enc->state.sb_maps;
+ src=_enc->state.ref_frame_data[OC_FRAME_IO];
+ ystride=_enc->state.ref_ystride[0];
+ fragi=sb_maps[_mbi>>2][_mbi&3][0];
+ frag_offs=frag_buf_offs[fragi];
+ satd=oc_enc_frag_intra_satd(_enc,src+frag_offs,ystride);
+ nqis=_enc->state.nqis;
+ lambda=_enc->lambda;
+ for(qii=0;qiistate.qis[qii],0,0,satd)
+ +(qs[0][qii].bits-_qs->bits<>2][_mbi&3][bi];
+ frag_offs=frag_buf_offs[fragi];
+ satd=oc_enc_frag_intra_satd(_enc,src+frag_offs,ystride);
+ for(qii=0;qiistate.qis[qii],0,0,satd);
+ best_ssd=ssd[bi-1][0]+cur_ssd;
+ best_rate=rate[bi-1][0]+cur_rate
+ +(qt[0].bits-qs[bi-1][0].bits<state.frags;
+ for(bi=3;;){
+ fragi=sb_maps[_mbi>>2][_mbi&3][bi];
+ frags[fragi].qii=best_qii;
+ if(bi--<=0)break;
+ best_qii=prev[bi][best_qii];
+ }
+ return best_cost;
+}
+
+/*Select a block-level quantizer for a single chroma block in an INTRA frame.*/
+static unsigned oc_analyze_intra_chroma_block(oc_enc_ctx *_enc,
+ const oc_qii_state *_qs,int _pli,ptrdiff_t _fragi){
+ const unsigned char *src;
+ oc_fragment *frags;
+ ptrdiff_t frag_offs;
+ oc_qii_state qt[3];
+ unsigned cost[3];
+ unsigned satd;
+ unsigned best_cost;
+ int best_qii;
+ int qii;
+ int lambda;
+ int ystride;
+ int nqis;
+ src=_enc->state.ref_frame_data[OC_FRAME_IO];
+ ystride=_enc->state.ref_ystride[_pli];
+ frag_offs=_enc->state.frag_buf_offs[_fragi];
+ satd=oc_enc_frag_intra_satd(_enc,src+frag_offs,ystride);
+ nqis=_enc->state.nqis;
+ lambda=_enc->lambda;
+ best_qii=0;
+ for(qii=0;qiistate.qis[qii],_pli,0,satd)
+ +(qt[qii].bits-_qs->bits<state.frags;
+ frags[_fragi].qii=best_qii;
+ return best_cost;
+}
+
+static void oc_enc_sb_transform_quantize_intra_chroma(oc_enc_ctx *_enc,
+ oc_enc_pipeline_state *_pipe,int _pli,int _sbi_start,int _sbi_end){
+ const oc_sb_map *sb_maps;
+ ptrdiff_t *coded_fragis;
+ ptrdiff_t ncoded_fragis;
+ int sbi;
+ sb_maps=(const oc_sb_map *)_enc->state.sb_maps;
+ coded_fragis=_pipe->coded_fragis[_pli];
+ ncoded_fragis=_pipe->ncoded_fragis[_pli];
+ for(sbi=_sbi_start;sbi<_sbi_end;sbi++){
+ /*Worst case token stack usage for 1 fragment.*/
+ oc_token_checkpoint stack[64];
+ int quadi;
+ int bi;
+ for(quadi=0;quadi<4;quadi++)for(bi=0;bi<4;bi++){
+ ptrdiff_t fragi;
+ fragi=sb_maps[sbi][quadi][bi];
+ if(fragi>=0){
+ oc_token_checkpoint *stackptr;
+ oc_analyze_intra_chroma_block(_enc,_pipe->qs+_pli,_pli,fragi);
+ stackptr=stack;
+ oc_enc_block_transform_quantize(_enc,
+ _pipe,_pli,fragi,0,NULL,&stackptr);
+ coded_fragis[ncoded_fragis++]=fragi;
+ }
+ }
+ }
+ _pipe->ncoded_fragis[_pli]=ncoded_fragis;
+}
+
+/*Analysis stage for an INTRA frame.*/
+void oc_enc_analyze_intra(oc_enc_ctx *_enc,int _recode){
+ oc_enc_pipeline_state pipe;
+ const unsigned char *map_idxs;
+ int nmap_idxs;
+ oc_sb_flags *sb_flags;
+ signed char *mb_modes;
+ const oc_mb_map *mb_maps;
+ oc_fragment *frags;
+ unsigned stripe_sby;
+ unsigned mcu_nvsbs;
+ int notstart;
+ int notdone;
+ int refi;
+ int pli;
+ _enc->state.frame_type=OC_INTRA_FRAME;
+ oc_enc_tokenize_start(_enc);
+ oc_enc_pipeline_init(_enc,&pipe);
+ /*Choose MVs and MB modes and quantize and code luma.
+ Must be done in Hilbert order.*/
+ map_idxs=OC_MB_MAP_IDXS[_enc->state.info.pixel_fmt];
+ nmap_idxs=OC_MB_MAP_NIDXS[_enc->state.info.pixel_fmt];
+ _enc->state.ncoded_fragis[0]=0;
+ _enc->state.ncoded_fragis[1]=0;
+ _enc->state.ncoded_fragis[2]=0;
+ sb_flags=_enc->state.sb_flags;
+ mb_modes=_enc->state.mb_modes;
+ mb_maps=(const oc_mb_map *)_enc->state.mb_maps;
+ frags=_enc->state.frags;
+ notstart=0;
+ notdone=1;
+ mcu_nvsbs=_enc->mcu_nvsbs;
+ for(stripe_sby=0;notdone;stripe_sby+=mcu_nvsbs){
+ unsigned sbi;
+ unsigned sbi_end;
+ notdone=oc_enc_pipeline_set_stripe(_enc,&pipe,stripe_sby);
+ sbi_end=pipe.sbi_end[0];
+ for(sbi=pipe.sbi0[0];sbistate.curframe_num>0)oc_mcenc_search(_enc,mbi);
+ oc_analyze_intra_mb_luma(_enc,pipe.qs+0,mbi);
+ mb_modes[mbi]=OC_MODE_INTRA;
+ oc_enc_mb_transform_quantize_luma(_enc,&pipe,mbi,0);
+ /*Propagate final MB mode and MVs to the chroma blocks.*/
+ for(mapii=4;mapii>2;
+ bi=mapi&3;
+ fragi=mb_maps[mbi][pli][bi];
+ frags[fragi].mb_mode=OC_MODE_INTRA;
+ }
+ }
+ }
+ oc_enc_pipeline_finish_mcu_plane(_enc,&pipe,0,notstart,notdone);
+ /*Code chroma planes.*/
+ for(pli=1;pli<3;pli++){
+ oc_enc_sb_transform_quantize_intra_chroma(_enc,&pipe,
+ pli,pipe.sbi0[pli],pipe.sbi_end[pli]);
+ oc_enc_pipeline_finish_mcu_plane(_enc,&pipe,pli,notstart,notdone);
+ }
+ notstart=1;
+ }
+ /*Finish filling in the reference frame borders.*/
+ refi=_enc->state.ref_frame_idx[OC_FRAME_SELF];
+ for(pli=0;pli<3;pli++)oc_state_borders_fill_caps(&_enc->state,refi,pli);
+ _enc->state.ntotal_coded_fragis=_enc->state.nfrags;
+}
+
+
+
+/*Cost information about a MB mode.*/
+struct oc_mode_choice{
+ unsigned cost;
+ unsigned ssd;
+ unsigned rate;
+ unsigned overhead;
+ unsigned char qii[12];
+};
+
+
+
+static void oc_mode_set_cost(oc_mode_choice *_modec,int _lambda){
+ _modec->cost=OC_MODE_RD_COST(_modec->ssd,
+ _modec->rate+_modec->overhead,_lambda);
+}
+
+/*A set of skip SSD's to use to disable early skipping.*/
+static const unsigned OC_NOSKIP[12]={
+ UINT_MAX,UINT_MAX,UINT_MAX,UINT_MAX,
+ UINT_MAX,UINT_MAX,UINT_MAX,UINT_MAX,
+ UINT_MAX,UINT_MAX,UINT_MAX,UINT_MAX
+};
+
+/*The estimated number of bits used by a coded chroma block to specify the AC
+ quantizer.
+ TODO: Currently this is just 0.5*log2(3) (estimating about 50% compression);
+ measurements suggest this is in the right ballpark, but it varies somewhat
+ with lambda.*/
+#define OC_CHROMA_QII_RATE ((0xCAE00D1DU>>31-OC_BIT_SCALE)+1>>1)
+
+static void oc_analyze_mb_mode_luma(oc_enc_ctx *_enc,
+ oc_mode_choice *_modec,const oc_fr_state *_fr,const oc_qii_state *_qs,
+ const unsigned _frag_satd[12],const unsigned _skip_ssd[12],int _qti){
+ oc_fr_state fr;
+ oc_qii_state qs;
+ unsigned ssd;
+ unsigned rate;
+ int overhead;
+ unsigned satd;
+ unsigned best_ssd;
+ unsigned best_rate;
+ int best_overhead;
+ int best_fri;
+ int best_qii;
+ unsigned cur_cost;
+ unsigned cur_ssd;
+ unsigned cur_rate;
+ int cur_overhead;
+ int lambda;
+ int nqis;
+ int nskipped;
+ int bi;
+ int qii;
+ lambda=_enc->lambda;
+ nqis=_enc->state.nqis;
+ /*We could do a trellis optimization here, but we don't make final skip
+ decisions until after transform+quantization, so the result wouldn't be
+ optimal anyway.
+ Instead we just use a greedy approach; for most SATD values, the
+ differences between the qiis are large enough to drown out the cost to
+ code the flags, anyway.*/
+ *&fr=*_fr;
+ *&qs=*_qs;
+ ssd=rate=overhead=nskipped=0;
+ for(bi=0;bi<4;bi++){
+ oc_fr_state ft[2];
+ oc_qii_state qt[3];
+ unsigned best_cost;
+ satd=_frag_satd[bi];
+ *(ft+0)=*&fr;
+ oc_fr_code_block(ft+0);
+ oc_qii_state_advance(qt+0,&qs,0);
+ best_overhead=(ft[0].bits-fr.bits<state.qis[0],0,_qti,satd)
+ +(qt[0].bits-qs.bits<state.qis[qii],0,_qti,satd)
+ +(qt[qii].bits-qs.bits<qii[bi]=best_qii;
+ }
+ _modec->ssd=ssd;
+ _modec->rate=rate;
+ _modec->overhead=OC_MAXI(overhead,0);
+}
+
+static void oc_analyze_mb_mode_chroma(oc_enc_ctx *_enc,
+ oc_mode_choice *_modec,const oc_fr_state *_fr,const oc_qii_state *_qs,
+ const unsigned _frag_satd[12],const unsigned _skip_ssd[12],int _qti){
+ unsigned ssd;
+ unsigned rate;
+ unsigned satd;
+ unsigned best_ssd;
+ unsigned best_rate;
+ int best_qii;
+ unsigned cur_cost;
+ unsigned cur_ssd;
+ unsigned cur_rate;
+ int lambda;
+ int nblocks;
+ int nqis;
+ int pli;
+ int bi;
+ int qii;
+ lambda=_enc->lambda;
+ nqis=_enc->state.nqis;
+ ssd=_modec->ssd;
+ rate=_modec->rate;
+ /*Because (except in 4:4:4 mode) we aren't considering chroma blocks in coded
+ order, we assume a constant overhead for coded block and qii flags.*/
+ nblocks=OC_MB_MAP_NIDXS[_enc->state.info.pixel_fmt];
+ nblocks=(nblocks-4>>1)+4;
+ bi=4;
+ for(pli=1;pli<3;pli++){
+ for(;bistate.qis[0],pli,_qti,satd)
+ +OC_CHROMA_QII_RATE;
+ best_cost=OC_MODE_RD_COST(ssd+best_ssd,rate+best_rate,lambda);
+ best_qii=0;
+ for(qii=1;qiistate.qis[qii],0,_qti,satd)
+ +OC_CHROMA_QII_RATE;
+ cur_cost=OC_MODE_RD_COST(ssd+cur_ssd,rate+cur_rate,lambda);
+ if(cur_costqii[bi]=best_qii;
+ }
+ nblocks=(nblocks-4<<1)+4;
+ }
+ _modec->ssd=ssd;
+ _modec->rate=rate;
+}
+
+static void oc_skip_cost(oc_enc_ctx *_enc,oc_enc_pipeline_state *_pipe,
+ unsigned _mbi,unsigned _ssd[12]){
+ OC_ALIGN16(ogg_int16_t buffer[64]);
+ const unsigned char *src;
+ const unsigned char *ref;
+ int ystride;
+ const oc_fragment *frags;
+ const ptrdiff_t *frag_buf_offs;
+ const ptrdiff_t *sb_map;
+ const oc_mb_map_plane *mb_map;
+ const unsigned char *map_idxs;
+ int map_nidxs;
+ ogg_int64_t mask;
+ unsigned uncoded_ssd;
+ int uncoded_dc;
+ unsigned dc_dequant;
+ int dc_flag;
+ int mapii;
+ int mapi;
+ int pli;
+ int bi;
+ ptrdiff_t fragi;
+ ptrdiff_t frag_offs;
+ int borderi;
+ int pi;
+ src=_enc->state.ref_frame_data[OC_FRAME_IO];
+ ref=_enc->state.ref_frame_data[_enc->state.ref_frame_idx[OC_FRAME_PREV]];
+ ystride=_enc->state.ref_ystride[0];
+ frags=_enc->state.frags;
+ frag_buf_offs=_enc->state.frag_buf_offs;
+ sb_map=_enc->state.sb_maps[_mbi>>2][_mbi&3];
+ dc_dequant=_enc->state.dequant_tables[_enc->state.qis[0]][0][1][0];
+ for(bi=0;bi<4;bi++){
+ fragi=sb_map[bi];
+ frag_offs=frag_buf_offs[fragi];
+ oc_enc_frag_sub(_enc,buffer,src+frag_offs,ref+frag_offs,ystride);
+ borderi=frags[fragi].borderi;
+ uncoded_ssd=uncoded_dc=0;
+ if(borderi<0){
+ for(pi=0;pi<64;pi++){
+ uncoded_ssd+=buffer[pi]*buffer[pi];
+ uncoded_dc+=buffer[pi];
+ }
+ }
+ else{
+ ogg_int64_t mask;
+ mask=_enc->state.borders[borderi].mask;
+ for(pi=0;pi<64;pi++,mask>>=1)if(mask&1){
+ uncoded_ssd+=buffer[pi]*buffer[pi];
+ uncoded_dc+=buffer[pi];
+ }
+ }
+ /*Scale to match DCT domain.*/
+ uncoded_ssd<<=4;
+ /*We actually only want the AC contribution to the SSD.*/
+ uncoded_ssd-=uncoded_dc*uncoded_dc>>2;
+ /*DC is a special case; if there's more than a full-quantizer improvement
+ in the effective DC component, always force-code the block.*/
+ dc_flag=abs(uncoded_dc)>dc_dequant<<1;
+ uncoded_ssd|=-dc_flag;
+ _pipe->skip_ssd[0][fragi-_pipe->froffset[0]]=_ssd[bi]=uncoded_ssd;
+ }
+ mb_map=(const oc_mb_map_plane *)_enc->state.mb_maps[_mbi];
+ map_nidxs=OC_MB_MAP_NIDXS[_enc->state.info.pixel_fmt];
+ map_idxs=OC_MB_MAP_IDXS[_enc->state.info.pixel_fmt];
+ map_nidxs=(map_nidxs-4>>1)+4;
+ mapii=4;
+ for(pli=1;pli<3;pli++){
+ ystride=_enc->state.ref_ystride[pli];
+ dc_dequant=_enc->state.dequant_tables[_enc->state.qis[0]][pli][1][0];
+ for(;mapiistate.borders[borderi].mask;
+ for(pi=0;pi<64;pi++,mask>>=1)if(mask&1){
+ uncoded_ssd+=buffer[pi]*buffer[pi];
+ uncoded_dc+=buffer[pi];
+ }
+ }
+ /*Scale to match DCT domain.*/
+ uncoded_ssd<<=4;
+ /*We actually only want the AC contribution to the SSD.*/
+ uncoded_ssd-=uncoded_dc*uncoded_dc>>2;
+ /*DC is a special case; if there's more than a full-quantizer improvement
+ in the effective DC component, always force-code the block.*/
+ dc_flag=abs(uncoded_dc)>dc_dequant<<1;
+ uncoded_ssd|=-dc_flag;
+ _pipe->skip_ssd[pli][fragi-_pipe->froffset[pli]]=_ssd[mapii]=uncoded_ssd;
+ }
+ map_nidxs=(map_nidxs-4<<1)+4;
+ }
+}
+
+static void oc_mb_intra_satd(oc_enc_ctx *_enc,unsigned _mbi,
+ unsigned _frag_satd[12]){
+ const unsigned char *src;
+ const ptrdiff_t *frag_buf_offs;
+ const ptrdiff_t *sb_map;
+ const oc_mb_map_plane *mb_map;
+ const unsigned char *map_idxs;
+ int map_nidxs;
+ int mapii;
+ int mapi;
+ int ystride;
+ int pli;
+ int bi;
+ ptrdiff_t fragi;
+ ptrdiff_t frag_offs;
+ frag_buf_offs=_enc->state.frag_buf_offs;
+ sb_map=_enc->state.sb_maps[_mbi>>2][_mbi&3];
+ src=_enc->state.ref_frame_data[OC_FRAME_IO];
+ ystride=_enc->state.ref_ystride[0];
+ for(bi=0;bi<4;bi++){
+ fragi=sb_map[bi];
+ frag_offs=frag_buf_offs[fragi];
+ _frag_satd[bi]=oc_enc_frag_intra_satd(_enc,src+frag_offs,ystride);
+ }
+ mb_map=(const oc_mb_map_plane *)_enc->state.mb_maps[_mbi];
+ map_idxs=OC_MB_MAP_IDXS[_enc->state.info.pixel_fmt];
+ map_nidxs=OC_MB_MAP_NIDXS[_enc->state.info.pixel_fmt];
+ /*Note: This assumes ref_ystride[1]==ref_ystride[2].*/
+ ystride=_enc->state.ref_ystride[1];
+ for(mapii=4;mapii>2;
+ bi=mapi&3;
+ fragi=mb_map[pli][bi];
+ frag_offs=frag_buf_offs[fragi];
+ _frag_satd[mapii]=oc_enc_frag_intra_satd(_enc,src+frag_offs,ystride);
+ }
+}
+
+static void oc_cost_intra(oc_enc_ctx *_enc,oc_mode_choice *_modec,
+ unsigned _mbi,const oc_fr_state *_fr,const oc_qii_state *_qs,
+ const unsigned _frag_satd[12],const unsigned _skip_ssd[12]){
+ oc_analyze_mb_mode_luma(_enc,_modec,_fr,_qs,_frag_satd,_skip_ssd,0);
+ oc_analyze_mb_mode_chroma(_enc,_modec,_fr,_qs,_frag_satd,_skip_ssd,0);
+ _modec->overhead+=
+ oc_mode_scheme_chooser_cost(&_enc->chooser,OC_MODE_INTRA)<lambda);
+}
+
+static void oc_cost_inter(oc_enc_ctx *_enc,oc_mode_choice *_modec,
+ unsigned _mbi,int _mb_mode,const signed char *_mv,
+ const oc_fr_state *_fr,const oc_qii_state *_qs,const unsigned _skip_ssd[12]){
+ unsigned frag_satd[12];
+ const unsigned char *src;
+ const unsigned char *ref;
+ int ystride;
+ const ptrdiff_t *frag_buf_offs;
+ const ptrdiff_t *sb_map;
+ const oc_mb_map_plane *mb_map;
+ const unsigned char *map_idxs;
+ int map_nidxs;
+ int mapii;
+ int mapi;
+ int mv_offs[2];
+ int dx;
+ int dy;
+ int pli;
+ int bi;
+ ptrdiff_t fragi;
+ ptrdiff_t frag_offs;
+ src=_enc->state.ref_frame_data[OC_FRAME_IO];
+ ref=_enc->state.ref_frame_data[
+ _enc->state.ref_frame_idx[OC_FRAME_FOR_MODE(_mb_mode)]];
+ ystride=_enc->state.ref_ystride[0];
+ frag_buf_offs=_enc->state.frag_buf_offs;
+ sb_map=_enc->state.sb_maps[_mbi>>2][_mbi&3];
+ dx=_mv[0];
+ dy=_mv[1];
+ _modec->rate=_modec->ssd=0;
+ if(oc_state_get_mv_offsets(&_enc->state,mv_offs,0,dx,dy)>1){
+ for(bi=0;bi<4;bi++){
+ fragi=sb_map[bi];
+ frag_offs=frag_buf_offs[fragi];
+ frag_satd[bi]=oc_enc_frag_satd2_thresh(_enc,src+frag_offs,
+ ref+frag_offs+mv_offs[0],ref+frag_offs+mv_offs[1],ystride,UINT_MAX);
+ }
+ }
+ else{
+ for(bi=0;bi<4;bi++){
+ fragi=sb_map[bi];
+ frag_offs=frag_buf_offs[fragi];
+ frag_satd[bi]=oc_enc_frag_satd_thresh(_enc,src+frag_offs,
+ ref+frag_offs+mv_offs[0],ystride,UINT_MAX);
+ }
+ }
+ mb_map=(const oc_mb_map_plane *)_enc->state.mb_maps[_mbi];
+ map_idxs=OC_MB_MAP_IDXS[_enc->state.info.pixel_fmt];
+ map_nidxs=OC_MB_MAP_NIDXS[_enc->state.info.pixel_fmt];
+ /*Note: This assumes ref_ystride[1]==ref_ystride[2].*/
+ ystride=_enc->state.ref_ystride[1];
+ if(oc_state_get_mv_offsets(&_enc->state,mv_offs,1,dx,dy)>1){
+ for(mapii=4;mapii>2;
+ bi=mapi&3;
+ fragi=mb_map[pli][bi];
+ frag_offs=frag_buf_offs[fragi];
+ frag_satd[mapii]=oc_enc_frag_satd2_thresh(_enc,src+frag_offs,
+ ref+frag_offs+mv_offs[0],ref+frag_offs+mv_offs[1],ystride,UINT_MAX);
+ }
+ }
+ else{
+ for(mapii=4;mapii>2;
+ bi=mapi&3;
+ fragi=mb_map[pli][bi];
+ frag_offs=frag_buf_offs[fragi];
+ frag_satd[mapii]=oc_enc_frag_satd_thresh(_enc,src+frag_offs,
+ ref+frag_offs+mv_offs[0],ystride,UINT_MAX);
+ }
+ }
+ oc_analyze_mb_mode_luma(_enc,_modec,_fr,_qs,frag_satd,_skip_ssd,1);
+ oc_analyze_mb_mode_chroma(_enc,_modec,_fr,_qs,frag_satd,_skip_ssd,1);
+ _modec->overhead+=
+ oc_mode_scheme_chooser_cost(&_enc->chooser,_mb_mode)<