Add libogg

LICENSE.md

@@ -106,6 +106,22 @@ The [Guidelines Support Library](https://github.com/Microsoft/GSL) is released u
 > 
 > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 
+### `[ogg]` libogg
+
+libogg is released under the **3-clause BSD license**.
+
+> Copyright (c) 2002, 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.
+
 ### `[pocketsphinx]` PocketSphinx
 
 The [PocketSphinx](https://github.com/cmusphinx/pocketsphinx) library is released under a variation of the **2-clause BSD License**.

rhubarb/CMakeLists.txt

@@ -232,6 +232,16 @@ target_include_directories(utf8proc SYSTEM PUBLIC "lib/utf8proc-2a2f97e1")
 target_compile_options(utf8proc PRIVATE ${disableWarningsFlags})
 set_target_properties(utf8proc PROPERTIES FOLDER lib)
 
+# ... Ogg
+add_library(ogg
+	lib/ogg-1.3.3/include/ogg/ogg.h
+	lib/ogg-1.3.3/src/bitwise.c
+	lib/ogg-1.3.3/src/framing.c
+)
+target_include_directories(ogg SYSTEM PUBLIC "lib/ogg-1.3.3/include")
+target_compile_options(ogg PRIVATE ${disableWarningsFlags})
+set_target_properties(ogg PROPERTIES FOLDER lib)
+
 # Define Rhubarb libraries
 
 include_directories("src")

rhubarb/lib/ogg-1.3.3/.gitignore

@@ -0,0 +1,33 @@
+aclocal.m4
+autom4te.cache
+ChangeLog
+compile
+config.guess
+config.h
+config.h.in
+config.h.in~
+config.log
+config.status
+config.sub
+configure
+depcomp
+install-sh
+libogg.spec
+libtool
+ltmain.sh
+Makefile
+Makefile.in
+missing
+mkinstalldirs
+ogg.pc
+ogg-uninstalled.pc
+stamp-h1
+.project
+include/ogg/config_types.h
+src/*.o
+src/*.lo
+src/lib*.la
+src/.libs
+src/.deps
+src/test_*
+macosx/build/

rhubarb/lib/ogg-1.3.3/.travis.yml

@@ -0,0 +1,17 @@
+language: c
+dist: trusty
+
+env:
+  - BUILD=AUTOTOOLS
+  - BUILD=CMAKE
+
+script:
+  - if [[ "$BUILD" == "AUTOTOOLS" ]] ; then ./autogen.sh ; fi
+  - if [[ "$BUILD" == "AUTOTOOLS" ]] ; then ./configure ; fi
+  - if [[ "$BUILD" == "AUTOTOOLS" ]] ; then make distcheck ; fi
+  - if [[ "$BUILD" == "CMAKE" ]] ; then mkdir build ; fi
+  - if [[ "$BUILD" == "CMAKE" ]] ; then pushd build ; fi
+  - if [[ "$BUILD" == "CMAKE" ]] ; then cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$PWD/_inst .. ; fi
+  - if [[ "$BUILD" == "CMAKE" ]] ; then cmake --build . ; fi
+  - if [[ "$BUILD" == "CMAKE" ]] ; then cmake --build . --target install ; fi
+  - if [[ "$BUILD" == "CMAKE" ]] ; then popd ; fi

rhubarb/lib/ogg-1.3.3/AUTHORS

@@ -0,0 +1,7 @@
+Monty <monty@xiph.org>
+Greg Maxwell <greg@xiph.org>
+Ralph Giles <giles@xiph.org>
+Cristian Adam <cristian.adam@gmail.com>
+Tim Terriberry <tterribe@xiph.org>
+
+and the rest of the Xiph.Org Foundation.

rhubarb/lib/ogg-1.3.3/CHANGES

@@ -0,0 +1,94 @@
+Version 1.3.3 (2017 November 7)
+
+ * Fix and issue with corrupt continued packet handling.
+ * Update Windows projects and build settings.
+ * Remove Mac OS 9 build support.
+
+Version 1.3.2 (2014 May 27)
+
+ * Fix an bug in oggpack_writecopy().
+
+Version 1.3.1 (2013 May 12)
+
+* Guard against very large packets.
+* Respect the configure --docdir override.
+* Documentation fixes.
+* More Windows build fixes.
+
+Version 1.3.0 (2011 August 4)
+
+* Add ogg_stream_flush_fill() call
+  This produces longer packets on flush, similar to
+  what ogg_stream_pageout_fill() does for single pages.
+* Windows build fixes
+
+Version 1.2.2 (2010 December 07)
+
+* Build fix (types correction) for Mac OS X
+* Update win32 project files to Visual Studio 2008
+* ogg_stream_pageout_fill documentation fix
+
+Version 1.2.1 (2010 November 01)
+
+* Various build updates (see SVN)
+* Add ogg_stream_pageout_fill() to API to allow applications
+  greater explicit flexibility in page sizing.
+* Documentation updates including multiplexing description,
+  terminology and API (incl. ogg_packet_clear(),
+  ogg_stream_pageout_fill())
+* Correct possible buffer overwrite in stream encoding on 32 bit
+  when a single packet exceed 250MB.
+* Correct read-buffer overrun [without side effects] under
+  similar circumstances.
+* Update unit testing to work properly with new page spill
+  heuristic.
+
+Version 1.2.0 (2010 March 25)
+
+* Alter default flushing behavior to span less often and use larger page
+  sizes when packet sizes are large.
+* Build fixes for additional compilers
+* Documentation updates
+
+Version 1.1.4 (2009 June 24)
+
+* New async error reporting mechanism. Calls made after a fatal error are
+  now safely handled in the event an error code is ignored
+* Added allocation checks useful to some embedded applications
+* fix possible read past end of buffer when reading 0 bits
+* Updates to API documentation
+* Build fixes
+
+Version 1.1.3 (2005 November 27)
+
+ * Correct a bug in the granulepos field of pages where no packet ends
+ * New VS2003 and XCode builds, minor fixes to other builds
+ * documentation fixes and cleanup
+
+Version 1.1.2 (2004 September 23)
+
+ * fix a bug with multipage packet assembly after seek
+
+Version 1.1.1 (2004 September 12)
+
+ * various bugfixes
+ * important bugfix for 64-bit platforms
+ * various portability fixes
+ * autotools cleanup from Thomas Vander Stichele
+ * Symbian OS build support from Colin Ward at CSIRO
+ * new multiplexed Ogg stream documentation
+
+Version 1.1 (2003 November 17)
+
+ * big-endian bitpacker routines for Theora
+ * various portability fixes
+ * improved API documenation
+ * RFC 3533 documentation of the format by Silvia Pfeiffer at CSIRO
+ * RFC 3534 documentation of the application/ogg mime-type by Linus Walleij
+
+Version 1.0 (2002 July 19)
+
+ * First stable release
+ * little-endian bitpacker routines for Vorbis
+ * basic Ogg bitstream sync and coding support
+

rhubarb/lib/ogg-1.3.3/CMakeLists.txt

@@ -0,0 +1,116 @@
+cmake_minimum_required(VERSION 2.8.7)
+project(libogg)
+
+# Required modules
+include(GNUInstallDirs)
+include(CheckIncludeFiles)
+
+# Build options
+option(BUILD_SHARED_LIBS "Build shared library" OFF)
+if(APPLE)
+    option(BUILD_FRAMEWORK "Build Framework bundle for OSX" OFF)
+endif()
+
+# Extract project version from configure.ac
+file(READ configure.ac CONFIGURE_AC_CONTENTS)
+string(REGEX MATCH "AC_INIT\\(\\[libogg\\],\\[([0-9]*).([0-9]*).([0-9]*)" DUMMY ${CONFIGURE_AC_CONTENTS})
+set(PROJECT_VERSION_MAJOR ${CMAKE_MATCH_1})
+set(PROJECT_VERSION_MINOR ${CMAKE_MATCH_2})
+set(PROJECT_VERSION_PATCH ${CMAKE_MATCH_3})
+set(PROJECT_VERSION ${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}.${PROJECT_VERSION_PATCH})
+
+# Helper function to get version-info
+function(get_version_info result current_var_name age_var_name revision_var_name)
+    string(REGEX MATCH "${current_var_name}=([0-9]*)" DUMMY ${CONFIGURE_AC_CONTENTS})
+    set(VERSION_INFO_CURRENT ${CMAKE_MATCH_1})
+
+    string(REGEX MATCH "${age_var_name}=([0-9]*)" DUMMY ${CONFIGURE_AC_CONTENTS})
+    set(VERSION_INFO_AGE ${CMAKE_MATCH_1})
+
+    string(REGEX MATCH "${revision_var_name}=([0-9]*)" DUMMY ${CONFIGURE_AC_CONTENTS})
+    set(VERSION_INFO_REVISION ${CMAKE_MATCH_1})
+
+    math(EXPR VERSION_INFO_CURRENT_MINUS_AGE "${VERSION_INFO_CURRENT} - ${VERSION_INFO_AGE}")
+
+    set(${result} "${VERSION_INFO_CURRENT_MINUS_AGE}.${VERSION_INFO_AGE}.${VERSION_INFO_REVISION}" PARENT_SCOPE)
+endfunction()
+
+# Helper function to configure pkg-config files
+function(configure_pkg_config_file pkg_config_file_in)
+    set(prefix ${CMAKE_INSTALL_PREFIX})
+    set(exec_prefix ${CMAKE_INSTALL_FULL_BINDIR})
+    set(libdir ${CMAKE_INSTALL_FULL_LIBDIR})
+    set(includedir ${CMAKE_INSTALL_FULL_INCLUDEDIR})
+    set(VERSION ${PROJECT_VERSION})
+    string(REPLACE ".in" "" pkg_config_file ${pkg_config_file_in})
+    configure_file(${pkg_config_file_in} ${CMAKE_CURRENT_BINARY_DIR}/${pkg_config_file} @ONLY)
+endfunction()
+
+message(STATUS "Configuring ${PROJECT_NAME} ${PROJECT_VERSION}")
+
+# Configure config_type.h
+check_include_files(inttypes.h INCLUDE_INTTYPES_H)
+check_include_files(stdint.h INCLUDE_STDINT_H)
+check_include_files(sys/types.h INCLUDE_SYS_TYPES_H)
+
+set(SIZE16 int16_t)
+set(USIZE16 uint16_t)
+set(SIZE32 int32_t)
+set(USIZE32 uint32_t)
+set(SIZE64 int64_t)
+
+configure_file(include/ogg/config_types.h.in ${CMAKE_CURRENT_BINARY_DIR}/include/ogg/config_types.h @ONLY)
+
+set(OGG_HEADERS
+    ${CMAKE_CURRENT_BINARY_DIR}/include/ogg/config_types.h
+    include/ogg/ogg.h
+    include/ogg/os_types.h
+)
+
+set(OGG_SOURCES
+    src/bitwise.c
+    src/framing.c
+)
+
+if(MSVC)
+    list(APPEND OGG_SOURCES win32/ogg.def)
+endif()
+
+if(BUILD_FRAMEWORK)
+    set(BUILD_SHARED_LIBS TRUE)
+endif()
+
+include_directories(include ${CMAKE_CURRENT_BINARY_DIR}/include)
+add_library(ogg ${OGG_HEADERS} ${OGG_SOURCES})
+
+get_version_info(OGG_VERSION_INFO "LIB_CURRENT" "LIB_AGE" "LIB_REVISION")
+set_target_properties(
+    ogg PROPERTIES
+    SOVERSION ${OGG_VERSION_INFO}
+    PUBLIC_HEADER "${OGG_HEADERS}"
+)
+
+if(BUILD_FRAMEWORK)
+    set_target_properties(ogg PROPERTIES
+        FRAMEWORK TRUE
+        FRAMEWORK_VERSION ${PROJECT_VERSION}
+        MACOSX_FRAMEWORK_IDENTIFIER org.xiph.ogg
+        MACOSX_FRAMEWORK_SHORT_VERSION_STRING ${PROJECT_VERSION}
+        MACOSX_FRAMEWORK_BUNDLE_VERSION ${PROJECT_VERSION}
+        XCODE_ATTRIBUTE_INSTALL_PATH "@rpath"
+        OUTPUT_NAME Ogg
+    )
+endif()
+
+configure_pkg_config_file(ogg.pc.in)
+
+install(TARGETS ogg
+    RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR}
+    LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
+    ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR}
+    FRAMEWORK DESTINATION ${CMAKE_INSTALL_PREFIX}
+    PUBLIC_HEADER DESTINATION ${CMAKE_INSTALL_INCLUDEDIR}/ogg
+)
+install(FILES ${CMAKE_CURRENT_BINARY_DIR}/ogg.pc
+    DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig
+)

rhubarb/lib/ogg-1.3.3/COPYING

@@ -0,0 +1,28 @@
+Copyright (c) 2002, 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.

rhubarb/lib/ogg-1.3.3/Makefile.am

@@ -0,0 +1,32 @@
+## Process this file with automake to produce Makefile.in
+
+
+#AUTOMAKE_OPTIONS = foreign 1.6 dist-zip
+AUTOMAKE_OPTIONS = foreign 1.11 dist-zip dist-xz
+
+SUBDIRS = src include doc
+
+m4datadir = $(datadir)/aclocal
+m4data_DATA = ogg.m4
+
+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = ogg.pc
+
+EXTRA_DIST = README.md AUTHORS CHANGES COPYING \
+	libogg.spec libogg.spec.in \
+	ogg.m4 ogg.pc.in ogg-uninstalled.pc.in \
+	macosx win32
+
+dist-hook:
+	for item in $(EXTRA_DIST); do \
+	  if test -d $$item; then \
+	    echo -n "cleaning dir $$item for distribution..."; \
+	    rm -rf `find $(distdir)/$$item -name .svn`; \
+	    echo "OK"; \
+	  fi; \
+	done
+debug:
+	$(MAKE) all CFLAGS="@DEBUG@"
+
+profile:
+	$(MAKE) all CFLAGS="@PROFILE@"

rhubarb/lib/ogg-1.3.3/README.md

@@ -0,0 +1,131 @@
+# Ogg
+
+[![Travis Build Status](https://travis-ci.org/xiph/ogg.svg?branch=master)](https://travis-ci.org/xiph/ogg)
+[![Jenkins Build Status](https://mf4.xiph.org/jenkins/job/libogg/badge/icon)](https://mf4.xiph.org/jenkins/job/libogg/)
+[![AppVeyor Build Status](https://ci.appveyor.com/api/projects/status/github/xiph/ogg?branch=master&svg=true)](https://ci.appveyor.com/project/rillian/ogg)
+
+Ogg project codecs use the Ogg bitstream format to arrange the raw,
+compressed bitstream into a more robust, useful form. For example,
+the Ogg bitstream makes seeking, time stamping and error recovery
+possible, as well as mixing several sepearate, concurrent media
+streams into a single physical bitstream.
+
+## What's here ##
+This source distribution includes libogg and nothing else. Other modules
+(eg, the modules libvorbis, vorbis-tools for the Vorbis music codec,
+libtheora for the Theora video codec) contain the codec libraries for
+use with Ogg bitstreams.
+
+Directory:
+
+- `src` The source for libogg, a BSD-license inplementation of the public domain Ogg bitstream format
+
+- `include` Library API headers
+
+- `doc` Ogg specification and libogg API documents
+
+- `win32` Win32 projects and build automation
+
+- `macosx` Mac OS X project and build files
+
+## Contact ##
+
+The Ogg homepage is located at https://www.xiph.org/ogg/ .
+Up to date technical documents, contact information, source code and
+pre-built utilities may be found there.
+
+## Building ##
+
+#### Building from tarball distributions ####
+
+    ./configure
+    make
+
+and optionally (as root):
+
+    make install
+
+This will install the Ogg libraries (static and shared) into
+/usr/local/lib, includes into /usr/local/include and API
+documentation into /usr/local/share/doc.
+
+#### Building from repository source ####
+
+A standard svn build should consist of nothing more than:
+
+    ./autogen.sh
+    ./configure
+    make
+
+and as root if desired :
+
+    make install
+
+#### Building on Windows ####
+
+Use the project file in the win32 directory. It should compile out of the box.
+
+#### Cross-compiling from Linux to Windows ####
+
+It is also possible to cross compile from Linux to windows using the MinGW
+cross tools and even to run the test suite under Wine, the Linux/*nix
+windows emulator.
+
+On Debian and Ubuntu systems, these cross compiler tools can be installed
+by doing:
+
+    sudo apt-get mingw32 mingw32-binutils mingw32-runtime wine
+
+Once these tools are installed its possible to compile and test by
+executing the following commands, or something similar depending on
+your system:
+
+    ./configure --host=i586-mingw32msvc --target=i586-mingw32msvc --build=i586-linux
+    make
+    make check
+
+(Build instructions for Ogg codecs such as vorbis are similar and may
+be found in those source modules' README files)
+
+## Building with CMake ##
+
+Ogg supports building using [CMake](http://www.cmake.org/). CMake is a meta build system that generates native projects for each platform.
+To generate projects just run cmake replacing `YOUR-PROJECT-GENERATOR` with a proper generator from a list [here](http://www.cmake.org/cmake/help/v3.2/manual/cmake-generators.7.html):
+
+    cmake -G YOUR-PROJECT-GENERATOR .
+
+Note that by default cmake generates projects that will build static libraries.
+To generate projects that will build dynamic library use `BUILD_SHARED_LIBS` option like this:
+
+    cmake -G YOUR-PROJECT-GENERATOR -DBUILD_SHARED_LIBS=1 .
+
+After projects are generated use them as usual
+
+#### Building on Windows ####
+
+Use proper generator for your Visual Studio version like:
+
+    cmake -G "Visual Studio 12 2013" .
+
+#### Building on Mac OS X ####
+
+Use Xcode generator. To build framework run:
+
+    cmake -G Xcode -DBUILD_FRAMEWORK=1 .
+
+#### Building on Linux ####
+
+Use Makefile generator which is default one.
+
+    cmake .
+    make
+
+## License ##
+
+THIS FILE IS PART OF THE OggVorbis 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 OggVorbis SOURCE CODE IS COPYRIGHT (C) 1994-2015
+by the Xiph.Org Foundation https://www.xiph.org/

rhubarb/lib/ogg-1.3.3/appveyor.yml

@@ -0,0 +1,19 @@
+image: Visual Studio 2015
+configuration:
+- Debug
+- Release
+
+platform:
+- Win32
+- x64
+
+build:
+  project: win32\VS2015\libogg_static.sln
+  parallel: true
+  verbosity: minimal
+
+after_build:
+- cmd: 7z a ogg.zip win32\VS2015\%PLATFORM%\%CONFIGURATION%\libogg_static.lib include\ogg\*.h
+
+artifacts:
+- path: ogg.zip

rhubarb/lib/ogg-1.3.3/autogen.sh

@@ -0,0 +1,12 @@
+#!/bin/sh
+# Run this to set up the build system: configure, makefiles, etc.
+set -e
+
+package="libogg"
+
+srcdir=`dirname $0`
+test -n "$srcdir" && cd "$srcdir"
+
+echo "Updating build configuration files for $package, please wait...."
+
+autoreconf -if

rhubarb/lib/ogg-1.3.3/configure.ac

@@ -0,0 +1,185 @@
+dnl Process this file with autoconf to produce a configure script.
+
+AC_INIT([libogg],[1.3.3],[ogg-dev@xiph.org])
+
+AC_CONFIG_SRCDIR(src/framing.c)
+
+AM_INIT_AUTOMAKE
+AM_MAINTAINER_MODE([enable])
+
+dnl Library versioning
+
+LIB_CURRENT=8
+LIB_REVISION=3
+LIB_AGE=8
+AC_SUBST(LIB_CURRENT)
+AC_SUBST(LIB_REVISION)
+AC_SUBST(LIB_AGE)
+
+AC_PROG_CC
+AM_PROG_LIBTOOL
+AM_PROG_CC_C_O
+
+dnl Set some options based on environment
+
+cflags_save="$CFLAGS"
+if test -z "$GCC"; then
+        case $host in 
+        *-*-irix*)
+                DEBUG="-g -signed" 
+                CFLAGS="-O2 -w -signed"
+                PROFILE="-p -g3 -O2 -signed"
+		;;
+        sparc-sun-solaris*)
+                DEBUG="-v -g"
+                CFLAGS="-xO4 -fast -w -fsimple -native -xcg92"
+                PROFILE="-v -xpg -g -xO4 -fast -native -fsimple -xcg92 -Dsuncc"
+		;;
+        *)
+                DEBUG="-g"
+                CFLAGS="-O"
+                PROFILE="-g -p" 
+		;;
+        esac
+else
+        case $host in 
+        *-*-linux*)
+                DEBUG="-g -Wall -fsigned-char"
+                CFLAGS="-O20 -Wall -ffast-math -fsigned-char"
+                PROFILE="-Wall -W -pg -g -O20 -ffast-math -fsigned-char"
+		;;
+        sparc-sun-*)
+                DEBUG="-g -Wall -fsigned-char"
+                CFLAGS="-O20 -ffast-math -fsigned-char"
+                PROFILE="-pg -g -O20 -fsigned-char" 
+		;;
+	*-*-darwin*)
+		DEBUG="-fno-common -g -Wall -fsigned-char"
+		CFLAGS="-fno-common -O4 -Wall -fsigned-char -ffast-math"
+		PROFILE="-fno-common -O4 -Wall -pg -g -fsigned-char -ffast-math"
+		;;
+        *)
+                DEBUG="-g -Wall -fsigned-char"
+                CFLAGS="-O20 -fsigned-char"
+                PROFILE="-O20 -g -pg -fsigned-char" 
+		;;
+        esac
+fi
+CFLAGS="$CFLAGS $cflags_save"
+DEBUG="$DEBUG $cflags_save"
+PROFILE="$PROFILE $cflags_save"
+
+dnl Checks for programs.
+
+dnl Checks for libraries.
+
+dnl Checks for header files.
+AC_HEADER_STDC
+INCLUDE_INTTYPES_H=0
+INCLUDE_STDINT_H=0
+INCLUDE_SYS_TYPES_H=0
+AC_CHECK_HEADER(inttypes.h,INCLUDE_INTTYPES_H=1)
+AC_CHECK_HEADER(stdint.h,INCLUDE_STDINT_H=1)
+AC_CHECK_HEADER(sys/types.h,INCLUDE_SYS_TYPES_H=1)
+
+dnl Checks for typedefs, structures, and compiler characteristics.
+AC_C_CONST
+
+dnl Check for types
+
+AC_CHECK_SIZEOF(int16_t)
+AC_CHECK_SIZEOF(uint16_t)
+AC_CHECK_SIZEOF(u_int16_t)
+AC_CHECK_SIZEOF(int32_t)
+AC_CHECK_SIZEOF(uint32_t)
+AC_CHECK_SIZEOF(u_int32_t)
+AC_CHECK_SIZEOF(int64_t)
+AC_CHECK_SIZEOF(short)
+AC_CHECK_SIZEOF(int)
+AC_CHECK_SIZEOF(long)
+AC_CHECK_SIZEOF(long long)
+
+case 2 in
+     $ac_cv_sizeof_int16_t) SIZE16="int16_t";;
+     $ac_cv_sizeof_short) SIZE16="short";;
+     $ac_cv_sizeof_int) SIZE16="int";;
+esac
+
+case 2 in
+     $ac_cv_sizeof_uint16_t) USIZE16="uint16_t";;
+     $ac_cv_sizeof_short) USIZE16="unsigned short";;
+     $ac_cv_sizeof_int) USIZE16="unsigned int";;
+     $ac_cv_sizeof_u_int16_t) USIZE16="u_int16_t";;
+esac
+
+case 4 in
+     $ac_cv_sizeof_int32_t) SIZE32="int32_t";;
+     $ac_cv_sizeof_short) SIZE32="short";;
+     $ac_cv_sizeof_int) SIZE32="int";;
+     $ac_cv_sizeof_long) SIZE32="long";;
+esac
+
+case 4 in
+     $ac_cv_sizeof_uint32_t) USIZE32="uint32_t";;
+     $ac_cv_sizeof_short) USIZE32="unsigned short";;
+     $ac_cv_sizeof_int) USIZE32="unsigned int";;
+     $ac_cv_sizeof_long) USIZE32="unsigned long";;
+     $ac_cv_sizeof_u_int32_t) USIZE32="u_int32_t";;
+esac
+
+case 8 in
+     $ac_cv_sizeof_int64_t) SIZE64="int64_t";;
+     $ac_cv_sizeof_int) SIZE64="int";;
+     $ac_cv_sizeof_long) SIZE64="long";;
+     $ac_cv_sizeof_long_long) SIZE64="long long";;
+esac
+
+if test -z "$SIZE16"; then
+        AC_MSG_ERROR(No 16 bit type found on this platform!)
+fi
+if test -z "$USIZE16"; then
+        AC_MSG_ERROR(No unsigned 16 bit type found on this platform!)
+fi
+if test -z "$SIZE32"; then
+        AC_MSG_ERROR(No 32 bit type found on this platform!)
+fi
+if test -z "$USIZE32"; then
+        AC_MSG_ERROR(No unsigned 32 bit type found on this platform!)
+fi
+if test -z "$SIZE64"; then
+        AC_MSG_WARN(No 64 bit type found on this platform!)
+fi
+
+dnl Checks for library functions.
+AC_FUNC_MEMCMP
+
+dnl Make substitutions
+
+AC_SUBST(LIBTOOL_DEPS)
+AC_SUBST(INCLUDE_INTTYPES_H)
+AC_SUBST(INCLUDE_STDINT_H)
+AC_SUBST(INCLUDE_SYS_TYPES_H)
+AC_SUBST(SIZE16)
+AC_SUBST(USIZE16)
+AC_SUBST(SIZE32)
+AC_SUBST(USIZE32)
+AC_SUBST(SIZE64)
+AC_SUBST(OPT)
+AC_SUBST(LIBS)
+AC_SUBST(DEBUG)
+AC_SUBST(CFLAGS)
+AC_SUBST(PROFILE)
+
+
+AC_CONFIG_FILES([
+Makefile
+src/Makefile
+doc/Makefile doc/libogg/Makefile
+include/Makefile include/ogg/Makefile include/ogg/config_types.h
+libogg.spec
+ogg.pc
+ogg-uninstalled.pc
+])
+AC_CONFIG_HEADERS([config.h])
+
+AC_OUTPUT

rhubarb/lib/ogg-1.3.3/doc/Makefile.am

@@ -0,0 +1,9 @@
+## Process this with automake to create Makefile.in
+
+SUBDIRS = libogg
+
+dist_html_DATA = framing.html index.html oggstream.html ogg-multiplex.html \
+	fish_xiph_org.png multiplex1.png packets.png pages.png stream.png \
+	vorbisword2.png white-ogg.png white-xifish.png \
+	rfc3533.txt rfc5334.txt skeleton.html
+

rhubarb/lib/ogg-1.3.3/doc/framing.html

@@ -0,0 +1,429 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html>
+<head>
+
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/>
+<title>Ogg Documentation</title>
+
+<style type="text/css">
+body {
+  margin: 0 18px 0 18px;
+  padding-bottom: 30px;
+  font-family: Verdana, Arial, Helvetica, sans-serif;
+  color: #333333;
+  font-size: .8em;
+}
+
+a {
+  color: #3366cc;
+}
+
+img {
+  border: 0;
+}
+
+#xiphlogo {
+  margin: 30px 0 16px 0;
+}
+
+#content p {
+  line-height: 1.4;
+}
+
+h1, h1 a, h2, h2 a, h3, h3 a {
+  font-weight: bold;
+  color: #ff9900;
+  margin: 1.3em 0 8px 0;
+}
+
+h1 {
+  font-size: 1.3em;
+}
+
+h2 {
+  font-size: 1.2em;
+}
+
+h3 {
+  font-size: 1.1em;
+}
+
+li {
+  line-height: 1.4;
+}
+
+#copyright {
+  margin-top: 30px;
+  line-height: 1.5em;
+  text-align: center;
+  font-size: .8em;
+  color: #888888;
+  clear: both;
+}
+</style>
+
+</head>
+
+<body>
+
+<div id="xiphlogo">
+  <a href="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.org"/></a>
+</div>
+
+<h1>Ogg logical bitstream framing</h1>
+
+<h2>Ogg bitstreams</h2>
+
+<p>The Ogg transport bitstream is designed to provide framing, error
+protection and seeking structure for higher-level codec streams that
+consist of raw, unencapsulated data packets, such as the Vorbis audio
+codec or Theora video codec.</p>
+
+<h2>Application example: Vorbis</h2>
+
+<p>Vorbis encodes short-time blocks of PCM data into raw packets of
+bit-packed data. These raw packets may be used directly by transport
+mechanisms that provide their own framing and packet-separation
+mechanisms (such as UDP datagrams). For stream based storage (such as
+files) and transport (such as TCP streams or pipes), Vorbis uses the
+Ogg bitstream format to provide framing/sync, sync recapture
+after error, landmarks during seeking, and enough information to
+properly separate data back into packets at the original packet
+boundaries without relying on decoding to find packet boundaries.</p>
+
+<h2>Design constraints for Ogg bitstreams</h2>
+
+<ol>
+<li>True streaming; we must not need to seek to build a 100%
+  complete bitstream.</li>
+<li>Use no more than approximately 1-2% of bitstream bandwidth for
+  packet boundary marking, high-level framing, sync and seeking.</li>
+<li>Specification of absolute position within the original sample
+  stream.</li>
+<li>Simple mechanism to ease limited editing, such as a simplified
+  concatenation mechanism.</li>
+<li>Detection of corruption, recapture after error and direct, random
+  access to data at arbitrary positions in the bitstream.</li>
+</ol>
+
+<h2>Logical and Physical Bitstreams</h2>
+
+<p>A <em>logical</em> Ogg bitstream is a contiguous stream of
+sequential pages belonging only to the logical bitstream. A
+<em>physical</em> Ogg bitstream is constructed from one or more
+than one logical Ogg bitstream (the simplest physical bitstream
+is simply a single logical bitstream). We describe below the exact
+formatting of an Ogg logical bitstream. Combining logical
+bitstreams into more complex physical bitstreams is described in the
+<a href="oggstream.html">Ogg bitstream overview</a>. The exact
+mapping of raw Vorbis packets into a valid Ogg Vorbis physical
+bitstream is described in the Vorbis I Specification.</p>
+
+<h2>Bitstream structure</h2>
+
+<p>An Ogg stream is structured by dividing incoming packets into
+segments of up to 255 bytes and then wrapping a group of contiguous
+packet segments into a variable length page preceded by a page
+header. Both the header size and page size are variable; the page
+header contains sizing information and checksum data to determine
+header/page size and data integrity.</p>
+
+<p>The bitstream is captured (or recaptured) by looking for the beginning
+of a page, specifically the capture pattern. Once the capture pattern
+is found, the decoder verifies page sync and integrity by computing
+and comparing the checksum. At that point, the decoder can extract the
+packets themselves.</p>
+
+<h3>Packet segmentation</h3>
+
+<p>Packets are logically divided into multiple segments before encoding
+into a page. Note that the segmentation and fragmentation process is a
+logical one; it's used to compute page header values and the original
+page data need not be disturbed, even when a packet spans page
+boundaries.</p>
+
+<p>The raw packet is logically divided into [n] 255 byte segments and a
+last fractional segment of &lt; 255 bytes. A packet size may well
+consist only of the trailing fractional segment, and a fractional
+segment may be zero length. These values, called "lacing values" are
+then saved and placed into the header segment table.</p>
+
+<p>An example should make the basic concept clear:</p>
+
+<pre>
+<tt>
+raw packet:
+  ___________________________________________
+ |______________packet data__________________| 753 bytes
+
+lacing values for page header segment table: 255,255,243
+</tt>
+</pre>
+
+<p>We simply add the lacing values for the total size; the last lacing
+value for a packet is always the value that is less than 255. Note
+that this encoding both avoids imposing a maximum packet size as well
+as imposing minimum overhead on small packets (as opposed to, eg,
+simply using two bytes at the head of every packet and having a max
+packet size of 32k. Small packets (&lt;255, the typical case) are
+penalized with twice the segmentation overhead). Using the lacing
+values as suggested, small packets see the minimum possible
+byte-aligned overhead (1 byte) and large packets, over 512 bytes or
+so, see a fairly constant ~.5% overhead on encoding space.</p>
+
+<p>Note that a lacing value of 255 implies that a second lacing value
+follows in the packet, and a value of &lt; 255 marks the end of the
+packet after that many additional bytes. A packet of 255 bytes (or a
+multiple of 255 bytes) is terminated by a lacing value of 0:</p>
+
+<pre><tt>
+raw packet:
+  _______________________________
+ |________packet data____________|          255 bytes
+
+lacing values: 255, 0
+</tt></pre>
+
+<p>Note also that a 'nil' (zero length) packet is not an error; it
+consists of nothing more than a lacing value of zero in the header.</p>
+
+<h3>Packets spanning pages</h3>
+
+<p>Packets are not restricted to beginning and ending within a page,
+although individual segments are, by definition, required to do so.
+Packets are not restricted to a maximum size, although excessively
+large packets in the data stream are discouraged.</p>
+
+<p>After segmenting a packet, the encoder may decide not to place all the
+resulting segments into the current page; to do so, the encoder places
+the lacing values of the segments it wishes to belong to the current
+page into the current segment table, then finishes the page. The next
+page is begun with the first value in the segment table belonging to
+the next packet segment, thus continuing the packet (data in the
+packet body must also correspond properly to the lacing values in the
+spanned pages. The segment data in the first packet corresponding to
+the lacing values of the first page belong in that page; packet
+segments listed in the segment table of the following page must begin
+the page body of the subsequent page).</p>
+
+<p>The last mechanic to spanning a page boundary is to set the header
+flag in the new page to indicate that the first lacing value in the
+segment table continues rather than begins a packet; a header flag of
+0x01 is set to indicate a continued packet. Although mandatory, it
+is not actually algorithmically necessary; one could inspect the
+preceding segment table to determine if the packet is new or
+continued. Adding the information to the packet_header flag allows a
+simpler design (with no overhead) that needs only inspect the current
+page header after frame capture. This also allows faster error
+recovery in the event that the packet originates in a corrupt
+preceding page, implying that the previous page's segment table
+cannot be trusted.</p>
+
+<p>Note that a packet can span an arbitrary number of pages; the above
+spanning process is repeated for each spanned page boundary. Also a
+'zero termination' on a packet size that is an even multiple of 255
+must appear even if the lacing value appears in the next page as a
+zero-length continuation of the current packet. The header flag
+should be set to 0x01 to indicate that the packet spanned, even though
+the span is a nil case as far as data is concerned.</p>
+
+<p>The encoding looks odd, but is properly optimized for speed and the
+expected case of the majority of packets being between 50 and 200
+bytes (note that it is designed such that packets of wildly different
+sizes can be handled within the model; placing packet size
+restrictions on the encoder would have only slightly simplified design
+in page generation and increased overall encoder complexity).</p>
+
+<p>The main point behind tracking individual packets (and packet
+segments) is to allow more flexible encoding tricks that requiring
+explicit knowledge of packet size. An example is simple bandwidth
+limiting, implemented by simply truncating packets in the nominal case
+if the packet is arranged so that the least sensitive portion of the
+data comes last.</p>
+
+<a name="page_header"></a>
+<h3>Page header</h3>
+
+<p>The headering mechanism is designed to avoid copying and re-assembly
+of the packet data (ie, making the packet segmentation process a
+logical one); the header can be generated directly from incoming
+packet data. The encoder buffers packet data until it finishes a
+complete page at which point it writes the header followed by the
+buffered packet segments.</p>
+
+<h4>capture_pattern</h4>
+
+<p>A header begins with a capture pattern that simplifies identifying
+pages; once the decoder has found the capture pattern it can do a more
+intensive job of verifying that it has in fact found a page boundary
+(as opposed to an inadvertent coincidence in the byte stream).</p>
+
+<pre><tt>
+ byte value
+
+  0  0x4f 'O'
+  1  0x67 'g'
+  2  0x67 'g'
+  3  0x53 'S'  
+</tt></pre>
+
+<h4>stream_structure_version</h4>
+
+<p>The capture pattern is followed by the stream structure revision:</p>
+
+<pre><tt>
+ byte value
+
+  4  0x00
+</tt></pre>
+ 
+<h4>header_type_flag</h4>
+  
+<p>The header type flag identifies this page's context in the bitstream:</p>
+
+<pre><tt>
+ byte value
+
+  5  bitflags: 0x01: unset = fresh packet
+	               set = continued packet
+	       0x02: unset = not first page of logical bitstream
+                       set = first page of logical bitstream (bos)
+	       0x04: unset = not last page of logical bitstream
+                       set = last page of logical bitstream (eos)
+</tt></pre>
+
+<h4>absolute granule position</h4>
+
+<p>(This is packed in the same way the rest of Ogg data is packed; LSb
+of LSB first. Note that the 'position' data specifies a 'sample'
+number (eg, in a CD quality sample is four octets, 16 bits for left
+and 16 bits for right; in video it would likely be the frame number.
+It is up to the specific codec in use to define the semantic meaning
+of the granule position value). The position specified is the total
+samples encoded after including all packets finished on this page
+(packets begun on this page but continuing on to the next page do not
+count). The rationale here is that the position specified in the
+frame header of the last page tells how long the data coded by the
+bitstream is. A truncated stream will still return the proper number
+of samples that can be decoded fully.</p>
+
+<p>A special value of '-1' (in two's complement) indicates that no packets
+finish on this page.</p>
+
+<pre><tt>
+ byte value
+
+  6  0xXX LSB
+  7  0xXX
+  8  0xXX
+  9  0xXX
+ 10  0xXX
+ 11  0xXX
+ 12  0xXX
+ 13  0xXX MSB
+</tt></pre>
+
+<h4>stream serial number</h4>
+ 
+<p>Ogg allows for separate logical bitstreams to be mixed at page
+granularity in a physical bitstream. The most common case would be
+sequential arrangement, but it is possible to interleave pages for
+two separate bitstreams to be decoded concurrently. The serial
+number is the means by which pages physical pages are associated with
+a particular logical stream. Each logical stream must have a unique
+serial number within a physical stream:</p>
+
+<pre><tt>
+ byte value
+
+ 14  0xXX LSB
+ 15  0xXX
+ 16  0xXX
+ 17  0xXX MSB
+</tt></pre>
+
+<h4>page sequence no</h4>
+
+<p>Page counter; lets us know if a page is lost (useful where packets
+span page boundaries).</p>
+
+<pre><tt>
+ byte value
+
+ 18  0xXX LSB
+ 19  0xXX
+ 20  0xXX
+ 21  0xXX MSB
+</tt></pre>
+
+<h4>page checksum</h4>
+     
+<p>32 bit CRC value (direct algorithm, initial val and final XOR = 0,
+generator polynomial=0x04c11db7). The value is computed over the
+entire header (with the CRC field in the header set to zero) and then
+continued over the page. The CRC field is then filled with the
+computed value.</p>
+
+<p>(A thorough discussion of CRC algorithms can be found in <a
+href="http://www.ross.net/crc/download/crc_v3.txt">"A
+Painless Guide to CRC Error Detection Algorithms"</a> by Ross
+Williams <a href="mailto:ross@ross.net">ross@ross.net</a>.)</p>
+
+<pre><tt>
+ byte value
+
+ 22  0xXX LSB
+ 23  0xXX
+ 24  0xXX
+ 25  0xXX MSB
+</tt></pre>
+
+<h4>page_segments</h4>
+
+<p>The number of segment entries to appear in the segment table. The
+maximum number of 255 segments (255 bytes each) sets the maximum
+possible physical page size at 65307 bytes or just under 64kB (thus
+we know that a header corrupted so as destroy sizing/alignment
+information will not cause a runaway bitstream. We'll read in the
+page according to the corrupted size information that's guaranteed to
+be a reasonable size regardless, notice the checksum mismatch, drop
+sync and then look for recapture).</p>
+
+<pre><tt>
+ byte value
+
+ 26 0x00-0xff (0-255)
+</tt></pre>
+
+<h4>segment_table (containing packet lacing values)</h4>
+
+<p>The lacing values for each packet segment physically appearing in
+this page are listed in contiguous order.</p>
+
+<pre><tt>
+ byte value
+
+ 27 0x00-0xff (0-255)
+ [...]
+ n  0x00-0xff (0-255, n=page_segments+26)
+</tt></pre>
+
+<p>Total page size is calculated directly from the known header size and
+lacing values in the segment table. Packet data segments follow
+immediately after the header.</p>
+
+<p>Page headers typically impose a flat .25-.5% space overhead assuming
+nominal ~8k page sizes. The segmentation table needed for exact
+packet recovery in the streaming layer adds approximately .5-1%
+nominal assuming expected encoder behavior in the 44.1kHz, 128kbps
+stereo encodings.</p>
+
+<div id="copyright">
+  The Xiph Fish Logo is a
+  trademark (&trade;) of Xiph.Org.<br/>
+
+  These pages &copy; 1994 - 2005 Xiph.Org. All rights reserved.
+</div>
+
+</body>
+</html>

rhubarb/lib/ogg-1.3.3/doc/index.html

@@ -0,0 +1,105 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html>
+<head>
+
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/>
+<title>Ogg Documentation</title>
+
+<style type="text/css">
+body {
+  margin: 0 18px 0 18px;
+  padding-bottom: 30px;
+  font-family: Verdana, Arial, Helvetica, sans-serif;
+  color: #333333;
+  font-size: .8em;
+}
+
+a {
+  color: #3366cc;
+}
+
+img {
+  border: 0;
+}
+
+#xiphlogo {
+  margin: 30px 0 16px 0;
+}
+
+#content p {
+  line-height: 1.4;
+}
+
+h1, h1 a, h2, h2 a, h3, h3 a {
+  font-weight: bold;
+  color: #ff9900;
+  margin: 1.3em 0 8px 0;
+}
+
+h1 {
+  font-size: 1.3em;
+}
+
+h2 {
+  font-size: 1.2em;
+}
+
+h3 {
+  font-size: 1.1em;
+}
+
+li {
+  line-height: 1.4;
+}
+
+#copyright {
+  margin-top: 30px;
+  line-height: 1.5em;
+  text-align: center;
+  font-size: .8em;
+  color: #888888;
+  clear: both;
+}
+</style>
+
+</head>
+
+<body>
+
+<div id="xiphlogo">
+  <a href="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.org"/></a>
+</div>
+
+<h1>Ogg Documentation</h1>
+
+<h2>Ogg programming documentation</h2>
+
+<ul>
+<li><a href="libogg/index.html">Programming with ogg</a></li>
+</ul>
+
+<h2>Ogg bitstream documentation</h2>
+
+<ul>
+<li><a href="oggstream.html">Ogg bitstream overview</a></li>
+<li><a href="framing.html">Ogg bitstream framing</a></li>
+<li><a href="ogg-multiplex.html">Ogg multi-stream multiplexing</a></li>
+<li><a href="skeleton.html">The Ogg Skeleton Metadata Bitstream</a></li>
+</ul>
+
+<h2>RFC documentation</h2>
+
+<ul>
+<li><a href="rfc3533.txt">rfc3533: The Ogg Encapsulation Format Version 0</a></li>
+<li><a href="rfc5334.txt">rfc5334: Ogg Media Types</a></li>
+</ul>
+
+<div id="copyright">
+  The Xiph Fish Logo is a
+  trademark (&trade;) of Xiph.Org.<br/>
+
+  These pages &copy; 1994 - 2010 Xiph.Org. All rights reserved.
+</div>
+
+</body>
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/Makefile.am

@@ -0,0 +1,39 @@
+## Process this file with automake to produce Makefile.in
+
+apidocdir = $(htmldir)/libogg
+
+dist_apidoc_DATA = bitpacking.html datastructures.html decoding.html encoding.html\
+	general.html index.html ogg_iovec_t.html ogg_packet.html ogg_packet_clear.html\
+	ogg_page.html ogg_page_bos.html ogg_page_checksum_set.html\
+	ogg_page_continued.html ogg_page_eos.html ogg_page_granulepos.html\
+	ogg_page_packets.html ogg_page_pageno.html ogg_page_serialno.html\
+	ogg_page_version.html ogg_stream_check.html ogg_stream_clear.html ogg_stream_destroy.html\
+	ogg_stream_eos.html ogg_stream_flush.html ogg_stream_flush_fill.html ogg_stream_init.html\
+	ogg_stream_iovecin.html ogg_stream_packetin.html ogg_stream_packetout.html\
+	ogg_stream_packetpeek.html ogg_stream_pagein.html\
+	ogg_stream_pageout.html ogg_stream_pageout_fill.html ogg_stream_reset.html\
+	ogg_stream_reset_serialno.html ogg_stream_state.html\
+	ogg_sync_buffer.html ogg_sync_check.html ogg_sync_clear.html ogg_sync_destroy.html\
+	ogg_sync_init.html ogg_sync_pageout.html ogg_sync_pageseek.html\
+	ogg_sync_reset.html ogg_sync_state.html ogg_sync_wrote.html\
+	oggpack_adv.html oggpack_adv1.html oggpack_bits.html\
+	oggpack_buffer.html oggpack_bytes.html oggpack_get_buffer.html\
+	oggpack_look.html oggpack_look1.html oggpack_read.html\
+	oggpack_read1.html oggpack_readinit.html oggpack_reset.html\
+	oggpack_write.html oggpack_writealign.html oggpack_writecheck.html oggpack_writeclear.html\
+	oggpack_writecopy.html oggpack_writeinit.html oggpack_writetrunc.html\
+	overview.html reference.html style.css
+
+update-doc-version:
+	@YEAR=$$(date +%Y); DAY=$$(date +%Y%m%d);					\
+	for f in $(srcdir)/*.html; do							\
+		sed -e "s/2000-[0-9]\{4\} Xiph.Org/2000-$$YEAR Xiph.Org/g"		\
+		    -e "s/libogg release [0-9. -]\+/libogg release $(VERSION) - $$DAY/g"\
+			< $$f > $$f.tmp;						\
+		if diff -q $$f $$f.tmp > /dev/null; then				\
+			rm $$f.tmp;							\
+		else									\
+			mv $$f.tmp $$f;							\
+		fi;									\
+	done;
+

rhubarb/lib/ogg-1.3.3/doc/libogg/bitpacking.html

@@ -0,0 +1,103 @@
+<html>
+
+<head>
+<title>libogg - Bitpacking Functions</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>Bitpacking Functions</h1>
+<p>Libogg contains a basic bitpacking library that is useful for manipulating data within a buffer.
+<p>
+All the <b>libogg</b> specific functions are declared in "ogg/ogg.h".
+<p>
+
+<table border=1 color=black width=50% cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td><b>function</b></td>
+	<td><b>purpose</b></td>
+</tr>
+<tr valign=top>
+<td><a href="oggpack_writeinit.html">oggpack_writeinit</a></td>
+	<td>Initializes a buffer for writing using this bitpacking library.</td>
+</tr>
+<tr valign=top>
+<td><a href="oggpack_writecheck.html">oggpack_writecheck</a></td>
+	<td>Asynchronously checks error status of bitpacker write buffer.</td>
+</tr>
+<tr valign=top>
+<td><a href="oggpack_reset.html">oggpack_reset</a></td>
+	<td>Clears and resets the buffer to the initial position.</td>
+</tr>
+<tr valign=top>
+<td><a href="oggpack_writeclear.html">oggpack_writeclear</a></td>
+	<td>Frees the memory used by the buffer.</td>
+</tr>
+<tr valign=top>
+<td><a href="oggpack_readinit.html">oggpack_readinit</a></td>
+	<td>Initializes a buffer for reading using this bitpacking library.</td>
+</tr>
+<tr valign=top>
+<td><a href="oggpack_write.html">oggpack_write</a></td>
+	<td>Writes bytes to the specified location within the buffer.</td>
+</tr>
+<tr valign=top>
+<td><a href="oggpack_look.html">oggpack_look</a></td>
+	<td>Look at a specified number of bits, <=32, without advancing the location pointer.</td>
+</tr>
+<tr valign=top>
+<td><a href="oggpack_look1.html">oggpack_look1</a></td>
+	<td>Looks at one bit without advancing the location pointer.</td>
+</tr>
+<tr valign=top>
+<td><a href="oggpack_adv.html">oggpack_adv</a></td>
+	<td>Advances the location pointer by a specified number of bits.</td>
+</tr>
+<tr valign=top>
+<td><a href="oggpack_adv1.html">oggpack_adv1</a></td>
+	<td>Advances the location pointer by one bit.</td>
+</tr>
+<tr valign=top>
+<td><a href="oggpack_read.html">oggpack_read</a></td>
+	<td>Reads a specified number of bits from the buffer.</td>
+</tr>
+<tr valign=top>
+<td><a href="oggpack_read1.html">oggpack_read1</a></td>
+	<td>Reads one bit from the buffer.</td>
+</tr>
+<tr valign=top>
+<td><a href="oggpack_bytes.html">oggpack_bytes</a></td>
+	<td>Returns the total number of bytes contained within the buffer.</td>
+</tr>
+<tr valign=top>
+<td><a href="oggpack_bits.html">oggpack_bits</a></td>
+	<td>Returns the total number of bits contained within the buffer.</td>
+</tr>
+<tr valign=top>
+<td><a href="oggpack_get_buffer.html">oggpack_get_buffer</a></td>
+	<td>Returns a pointer to the buffer encapsulated within the <a href="oggpack_buffer.html">oggpack_buffer</a> struct.</td>
+</tr>
+</table>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/datastructures.html

@@ -0,0 +1,59 @@
+<html>
+
+<head>
+<title>libogg - Base Data Structures</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>Base Data Structures</h1>
+<p>Libogg uses several data structures to hold data and state information.
+<p>
+All the <b>libogg</b> specific data structures are declared in "ogg/ogg.h".
+<p>
+
+<table border=1 color=black width=50% cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td><b>datatype</b></td>
+	<td><b>purpose</b></td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_page.html">ogg_page</a></td>
+	<td>This structure encapsulates data into one ogg bitstream page.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_stream_state.html">ogg_stream_state</a></td>
+	<td>This structure contains current encode/decode data for a logical bitstream.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_packet.html">ogg_packet</a></td>
+	<td>This structure encapsulates the data and metadata for a single Ogg packet.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_sync_state.html">ogg_sync_state</a></td>
+	<td>Contains bitstream synchronization information.</td>
+</tr>
+</table>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/decoding.html

@@ -0,0 +1,104 @@
+<html>
+
+<head>
+<title>libogg - Decoding</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>Decoding</h1>
+<p>Libogg contains a set of functions used in the decoding process.
+<p>
+All the <b>libogg</b> specific functions are declared in "ogg/ogg.h".
+<p>
+<p>Decoding is based around the ogg synchronization layer.  The <a href="ogg_sync_state.html">ogg_sync_state</a> struct coordinates between incoming data and the decoder.  We read data into the synchronization layer, submit the data to the stream, and output raw packets to the decoder.
+<p>Decoding through the Ogg layer follows a specific logical sequence.  A read loop follows these logical steps:
+<ul>
+<li>Expose a buffer using <a href="ogg_sync_buffer.html">ogg_sync_buffer()</a>.
+<li>Read data into the buffer, using fread() or a similar function.
+<li>Call <a href="ogg_sync_wrote.html">ogg_sync_wrote()</a> to tell the synchronization layer how many bytes you wrote into the buffer.
+<li>Write out the data using <a href="ogg_sync_pageout.html">ogg_sync_pageout</a>.
+<li>Submit the completed page to the streaming layer with <a href="ogg_stream_pagein.html">ogg_stream_pagein</a>.
+<li>Output a packet of data to the codec-specific decoding layer using <a href="ogg_stream_packetout.html">ogg_stream_packetout</a>.
+</ul>
+<p>In practice, streams are more complex, and Ogg also must handle headers, incomplete or dropped pages, and other errors in input.
+<br><br>
+
+<table border=1 color=black width=50% cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td><b>function</b></td>
+	<td><b>purpose</b></td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_sync_init.html">ogg_sync_init</a></td>
+	<td>Initializes an Ogg bitstream.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_sync_clear.html">ogg_sync_clear</a></td>
+	<td>Clears the status information from the synchronization struct.<td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_sync_reset.html">ogg_sync_reset</a></td>
+	<td>Resets the synchronization status to initial values.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_sync_destroy.html">ogg_sync_destroy</a></td>
+	<td>Frees the synchronization struct.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_sync_check.html">ogg_sync_check</a></td>
+	<td>Check for asynchronous errors.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_sync_buffer.html">ogg_sync_buffer</a></td>
+	<td>Exposes a buffer from the synchronization layer in order to read data.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_sync_wrote.html">ogg_sync_wrote</a></td>
+	<td>Tells the synchronization layer how many bytes were written into the buffer.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_sync_pageseek.html">ogg_sync_pageseek</a></td>
+	<td>Finds the borders of pages and resynchronizes the stream.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_sync_pageout.html">ogg_sync_pageout</a></td>
+	<td>Outputs a page from the synchronization layer.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_stream_pagein.html">ogg_stream_pagein</a></td>
+	<td>Submits a complete page to the stream layer.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_stream_packetout.html">ogg_stream_packetout</a></td>
+	<td>Outputs a packet to the codec-specific decoding engine.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_stream_packetpeek.html">ogg_stream_packetpeek</a></td>
+	<td>Provides access to the next packet in the bitstream without
+advancing decoding.</td>
+</tr>
+</table>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/encoding.html

@@ -0,0 +1,76 @@
+<html>
+
+<head>
+<title>libogg - Encoding</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>Encoding</h1>
+<p>Libogg contains a set of functions used in the encoding process.
+<p>
+All the <b>libogg</b> specific functions are declared in "ogg/ogg.h".
+<p>
+<p>When encoding, the encoding engine will output raw packets which must be placed into an Ogg bitstream.
+<p>Raw packets are inserted into the stream, and an <a href="ogg_page.html">ogg_page</a> is output when enough packets have been written to create a full page.  The pages output are pointers to buffered packet segments, and can then be written out and saved as an ogg stream.
+<p>There are a couple of basic steps:
+<ul>
+<li>Use the encoding engine to produce a raw packet of data.
+<li>Call <a href="ogg_stream_packetin.html">ogg_stream_packetin</a> to submit a raw packet to the stream.
+<li>Use <a href="ogg_stream_pageout.html">ogg_stream_pageout</a> to output a page, if enough data has been submitted.  Otherwise, continue submitting data.
+</ul>
+<br><br>
+
+<table border=1 color=black width=50% cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td><b>function</b></td>
+	<td><b>purpose</b></td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_stream_packetin.html">ogg_stream_packetin</a></td>
+	<td>Submits a raw packet to the streaming layer, so that it can be formed into a page.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_stream_iovecin.html">ogg_stream_iovecin</a></td>
+	<td>iovec version of ogg_stream_packetin() above.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_stream_pageout.html">ogg_stream_pageout</a></td>
+	<td>Outputs a completed page if the stream contains enough packets to form a full page.<td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_stream_pageout_fill.html">ogg_stream_pageout_fill</a></td>
+	<td>Similar to ogg_stream_pageout(), but specifies a page spill threshold in bytes.
+</tr>
+<tr valign=top>
+<td><a href="ogg_stream_flush.html">ogg_stream_flush</a></td>
+	<td>Forces any remaining packets in the stream to be returned as a page of any size.<td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_stream_flush_fill.html">ogg_stream_flush_fill</a></td>
+	<td>Similar to ogg_stream_flush(), but specifies a page spill threshold in bytes.<td>
+</tr>
+</table>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/general.html

@@ -0,0 +1,109 @@
+<html>
+
+<head>
+<title>libogg - General Functions</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>General Functions</h1>
+<p>Libogg contains several functions which are generally useful when using Ogg streaming, whether encoding or decoding.
+<p>
+All the <b>libogg</b> specific functions are declared in "ogg/ogg.h".
+<p>
+<p>These functions can be used to manipulate some of the basic elements of Ogg - streams and pages.  Streams and pages are important during both the encode and decode process.
+<br>
+
+<table border=1 color=black width=50% cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td><b>function</b></td>
+	<td><b>purpose</b></td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_stream_init.html">ogg_stream_init</a></td>
+	<td>Initializes an Ogg bitstream.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_stream_clear.html">ogg_stream_clear</a></td>
+	<td>Clears the storage within the Ogg stream, but does not free the stream itself.<td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_stream_reset.html">ogg_stream_reset</a></td>
+	<td>Resets the stream status to its initial position.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_stream_destroy.html">ogg_stream_destroy</a></td>
+	<td>Frees the entire Ogg stream.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_stream_check.html">ogg_stream_check</a></td>
+	<td>Check for asyncronous errors.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_stream_eos.html">ogg_stream_eos</a></td>
+	<td>Indicates whether we are at the end of the stream.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_page_version.html">ogg_page_version</a></td>
+	<td>Returns the version of ogg_page that this stream/page uses</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_page_continued.html">ogg_page_continued</a></td>
+	<td>Indicates if the current page contains a continued packet from the last page.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_page_packets.html">ogg_page_packets</a></td>
+        <td>Indicates the number of packets contained in a page.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_page_bos.html">ogg_page_bos</a></td>
+	<td>Indicates if the current page is the beginning of the stream.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_page_eos.html">ogg_page_eos</a></td>
+	<td>Indicates if the current page is the end of the stream.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_page_granulepos.html">ogg_page_granulepos</a></td>
+	<td>Returns the precise playback location of this page.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_page_serialno.html">ogg_page_serialno</a></td>
+	<td>Returns the unique serial number of the logical bitstream associated with this page.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_page_pageno.html">ogg_page_pageno</a></td>
+	<td>Returns the sequential page number for this page.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_packet_clear.html">ogg_packet_clear</a></td>
+        <td>Clears the ogg_packet structure.</td>
+</tr>
+<tr valign=top>
+<td><a href="ogg_page_checksum_set.html">ogg_page_checksum_set</a></td>
+        <td>Checksums an ogg_page.</td>
+</tr>
+</table>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/index.html

@@ -0,0 +1,39 @@
+<html>
+
+<head>
+<title>libogg - Documentation</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>Libogg Documentation</h1>
+
+<p>
+Libogg contains necessary functionality to create, decode, and work with Ogg bitstreams.
+<p>This document explains how to use the libogg API in detail.
+<p>
+<a href="overview.html">libogg api overview</a><br>
+<a href="reference.html">libogg api reference</a><br>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_iovec_t.html

@@ -0,0 +1,62 @@
+<html>
+
+<head>
+<title>libogg - datatype - ogg_iovec_t</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_iovec_t</h1>
+
+<p><i>declared in "ogg/ogg.h"</i></p>
+
+<p>
+The ogg_iovec_t struct encapsulates a length-encoded buffer.  An array
+of ogg_iovec_t is used to pass a list of buffers to functions that
+accept data in ogg_iovec_t* form.
+<p>
+
+<table border=0 width=100% color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+typedef struct {
+  void *iov_base;
+  size_t iov_len;
+} ogg_iovec_t;
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Relevant Struct Members</h3>
+<dl>
+<dt><i>iov_base</i></dt>
+<dd>Pointer to the buffer data.</dd>
+<dt><i>iov_len</i></dt>
+<dd>Length of buffer data in bytes.</dd>
+</dl>
+
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_packet.html

@@ -0,0 +1,75 @@
+<html>
+
+<head>
+<title>libogg - datatype - ogg_packet</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_packet</h1>
+
+<p><i>declared in "ogg/ogg.h"</i></p>
+
+<p>
+The ogg_packet struct encapsulates the data for a single raw packet of data
+and is used to transfer data between the ogg framing layer and the handling codec.
+<p>
+
+<table border=0 width=100% color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+typedef struct {
+  unsigned char *packet;
+  long  bytes;
+  long  b_o_s;
+  long  e_o_s;
+
+  ogg_int64_t  granulepos;
+  ogg_int64_t  packetno; 
+
+} ogg_packet;
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Relevant Struct Members</h3>
+<dl>
+<dt><i>packet</i></dt>
+<dd>Pointer to the packet's data. This is treated as an opaque type by the ogg layer.</dd>
+<dt><i>bytes</i></dt>
+<dd>Indicates the size of the packet data in bytes.  Packets can be of arbitrary size.</dd>
+<dt><i>b_o_s</i></dt>
+<dd>Flag indicating whether this packet begins a logical bitstream.  <tt>1</tt> indicates this is the first packet, <tt>0</tt> indicates any other position in the stream.</dd>
+<dt><i>e_o_s</i></dt>
+<dd>Flag indicating whether this packet ends a bitstream.  <tt>1</tt> indicates the last packet, <tt>0</tt> indicates any other position in the stream.</dd>
+<dt><i>granulepos</i></dt>
+<dd>A number indicating the position of this packet in the decoded data. This is the last sample, frame or other unit of information ('granule') that can be completely decoded from this packet.</dd>
+<dt><i>packetno</i></dt>
+<dd>Sequential number of this packet in the ogg bitstream.<dd>
+</dl>
+
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_packet_clear.html

@@ -0,0 +1,64 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_packet_clear</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_packet_clear</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function clears the memory used by the <a href="ogg_packet.html">ogg_packet</a> struct,
+but does not free the structure itself.
+It unconditionally frees the <i>packet</i> data buffer,
+then it zeros all structure members.
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+void ogg_packet_clear(ogg_packet *op);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>op</i></dt>
+<dd>Pointer to the ogg_packet struct to be cleared.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+None.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_page.html

@@ -0,0 +1,75 @@
+<html>
+
+<head>
+<title>libogg - datatype - ogg_page</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_page</h1>
+
+<p><i>declared in "ogg/ogg.h"</i></p>
+
+<p>
+The ogg_page struct encapsulates the data for an Ogg page.
+<p>
+Ogg pages are the fundamental unit of framing and interleave in an ogg bitstream.
+They are made up of packet segments of 255 bytes each. There can be as many as
+255 packet segments per page, for a maximum page size of a little under 64 kB.
+This is not a practical limitation as the segments can be joined across
+page boundaries allowing packets of arbitrary size. In practice many
+applications will not completely fill all pages because they flush the
+accumulated packets periodically order to bound latency more tightly. 
+<p>
+<p>For a complete description of ogg pages and headers, please refer to the <a href="../framing.html">framing document</a>.
+
+<table border=0 width=100% color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+typedef struct {
+  unsigned char *header;
+  long           header_len;
+  unsigned char *body;
+  long           body_len;
+} ogg_page;
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Relevant Struct Members</h3>
+<dl>
+<dt><i>header</i></dt>
+<dd>Pointer to the page header for this page.  The exact contents of this header are defined in the framing spec document.</dd>
+<dt><i>header_len</i></dt>
+<dd>Length of the page header in bytes.</a>
+<dt><i>body</i></dt>
+<dd>Pointer to the data for this page.</dd>
+<dt><i>body_len</i></dt>
+<dd>Length of the body data in bytes.</dd>
+</dl>
+
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_page_bos.html

@@ -0,0 +1,65 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_page_bos</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_page_bos</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>Indicates whether this page is at the beginning of the logical bitstream.
+<p>
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_page_bos(ogg_page *og);
+
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>og</i></dt>
+<dd>Pointer to the current ogg_page struct.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+greater than 0 if this page is the beginning of a bitstream.</li>
+<li>
+0 if this page is from any other location in the stream.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_page_checksum_set.html

@@ -0,0 +1,62 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_page_checksum_set</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_page_checksum_set</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>Checksums an ogg_page.
+<p>
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_page_checksum_set(ogg_page *og);
+
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>og</i></dt>
+<dd>Pointer to an ogg_page struct.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+None.
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_page_continued.html

@@ -0,0 +1,64 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_page_version</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_page_continued</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>Indicates whether this page contains packet data which has been continued from the previous page.
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_page_continued(ogg_page *og);
+
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>og</i></dt>
+<dd>Pointer to the current ogg_page struct.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+1 if this page contains packet data continued from the last page.</li>
+<li>
+0 if this page does not contain continued data.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_page_eos.html

@@ -0,0 +1,65 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_page_eos</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_page_eos</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>Indicates whether this page is at the end of the logical bitstream.
+<p>
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_page_eos(ogg_page *og);
+
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>og</i></dt>
+<dd>Pointer to the current ogg_page struct.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+greater than zero if this page contains the end of a bitstream.</li>
+<li>
+0 if this page is from any other location in the stream.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_page_granulepos.html

@@ -0,0 +1,65 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_page_granulepos</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_page_granulepos</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>Returns the exact granular position of the packet data contained at the end of this page.
+<p>This is useful for tracking location when seeking or decoding.
+<p>For example, in audio codecs this position is the pcm sample number and in video this is the frame number.
+<p>
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+ogg_in64_t ogg_page_granulepos(ogg_page *og);
+
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>og</i></dt>
+<dd>Pointer to the current ogg_page struct.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+<i>n</i> is the specific last granular position of the decoded data contained in the page.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_page_packets.html

@@ -0,0 +1,75 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_page_packets</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_page_packets</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>Returns the number of packets that are completed on this page.  If the
+leading packet is begun on a previous page, but ends on this page, it's 
+counted.
+<p>
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_page_packets(ogg_page *og);
+
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>og</i></dt>
+<dd>Pointer to the current ogg_page struct.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+If a page consists of a packet begun on a previous page, and a new packet
+begun (but not completed) on this page, the return will be:<br>
+<br>
+ogg_page_packets(page) will return 1,<br>
+ogg_page_continued(paged) will return non-zero.<br>
+<br><br>
+If a page happens to be a single packet that was begun on a previous page, and
+spans to the next page (in the case of a three or more page packet), the
+return will be:<br>
+<br>
+ogg_page_packets(page) will return 0,<br>
+ogg_page_continued(page) will return non-zero.<br>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_page_pageno.html

@@ -0,0 +1,63 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_page_pageno</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_page_pageno</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>Returns the sequential page number.
+<p>This is useful for ordering pages or determining when pages have been lost.
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+long ogg_page_pageno(ogg_page *og);
+
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>og</i></dt>
+<dd>Pointer to the current ogg_page struct.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+<i>n</i> is the page number for this page.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_page_serialno.html

@@ -0,0 +1,63 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_page_serialno</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_page_serialno</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>Returns the unique serial number for the logical bitstream of this page.  Each page contains the serial number for the logical bitstream that it belongs to.
+<p>
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_page_serialno(ogg_page *og);
+
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>og</i></dt>
+<dd>Pointer to the current ogg_page struct.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+<i>n</i> is the serial number for this page.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_page_version.html

@@ -0,0 +1,63 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_page_version</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_page_version</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function returns the version of ogg_page used in this page.
+<p>In current versions of libogg, all ogg_page structs have the same version, so 0 should always be returned.
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_page_version(ogg_page *og);
+
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>og</i></dt>
+<dd>Pointer to the current ogg_page struct.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+<i>n</i> is the version number.  In the current version of Ogg, the version number is always 0.  Nonzero return values indicate an error in page encoding.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_check.html

@@ -0,0 +1,71 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_stream_check</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_check</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function is used to check the error or readiness condition of an <a href="ogg_stream_state.html">ogg_stream_state</a> structure.  
+<p>It is safe practice to ignore unrecoverable errors (such as an internal error caused by a malloc() failure) returned by ogg stream synchronization calls. Should an
+internal error occur, the <a href="ogg_stream_state.html">ogg_stream_state</a> structure will be cleared (equivalent to a
+call to
+<a href="ogg_stream_clear.html">ogg_stream_clear</a>) and subsequent calls
+using this <a href="ogg_stream_state.html">ogg_stream_state</a> will be
+noops. Error detection is then handled via a single call to
+ogg_stream_check at the end of the operational block. </p>
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_stream_check(<a href="ogg_stream_state.html">ogg_stream_state</a> *os);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>os</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_stream_state.html">ogg_stream_state</a> struct.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+0 is returned if the <a href="ogg_stream_state.html">ogg_stream_state</a> structure is initialized and ready.</li>
+<li>
+nonzero is returned if the structure was never initialized, or if an unrecoverable internal error occurred in a previous call using the passed in <a href="ogg_stream_state.html">ogg_stream_state</a> struct.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_clear.html

@@ -0,0 +1,61 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_stream_clear</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_clear</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function clears and frees the internal memory used by the <a href="ogg_sync_state.html">ogg_stream_state</a> struct, but does not free the structure itself. It is safe to call ogg_stream_clear on the same structure more than once.
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_stream_clear(ogg_stream_state *os);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>os</i></dt>
+<dd>Pointer to the ogg_stream_state struct to be cleared.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+0 is always returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_destroy.html

@@ -0,0 +1,71 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_stream_destroy</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_destroy</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function frees the internal memory used by
+the <a href="ogg_stream_state.html">ogg_stream_state</a> struct as
+well as the structure itself.
+
+<p>This should be called when you are done working with an ogg stream.
+It can also be called to make sure that the struct does not exist.</p>
+
+<p>It calls free() on its argument, so if the ogg_stream_state 
+is not malloc()'d or will otherwise be freed by your own code, use 
+<a href="ogg_stream_clear.html">ogg_stream_clear</a> instead.</p>
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_stream_destroy(ogg_stream_state *os);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>os</i></dt>
+<dd>Pointer to the ogg_stream_state struct to be destroyed.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+0 is always returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_eos.html

@@ -0,0 +1,62 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_stream_eos</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_eos</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function indicates whether we have reached the end of the stream or not.
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_stream_eos(ogg_stream_state *os);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>os</i></dt>
+<dd>Pointer to the current ogg_stream_state struct.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>1 if we are at the end of the stream or an internal error occurred.</li>
+<li>
+0 if we have not yet reached the end of the stream.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_flush.html

@@ -0,0 +1,67 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_stream_flush</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_flush</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function checks for remaining packets inside the stream and forces remaining packets into a page, regardless of the size of the page.
+<p>This should only be used when you want to flush an undersized page from the middle of the stream.  Otherwise, <a href="ogg_stream_pageout.html">ogg_stream_pageout</a> or <a href="ogg_stream_pageout_fill.html">ogg_stream_pageout_fill</a> should always be used.
+<p>This function can also be used to verify that all packets have been flushed.  If the return value is 0, all packets have been placed into a page. Like <a href="ogg_stream_pageout.html">ogg_stream_pageout</a>, it should generally be called in a loop until available packet data has been flushes, since even a single packet may span multiple pages.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_stream_flush(<a href="ogg_stream_state.html">ogg_stream_state</a> *os, <a href="ogg_page.html">ogg_page</a> *og);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>os</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_stream_state.html">ogg_stream_state</a> struct, which represents the current logical bitstream.</dd>
+<dt><i>og</i></dt>
+<dd>Pointer to a page of data.  The remaining packets in the stream will be placed into this page, if any remain.
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>0 means that all packet data has already been flushed into pages, and there are no packets to put into the page.  0 is also returned in the case of an <a href="ogg_stream_state.html">ogg_stream_state</a> that has been cleared explicitly or implicitly due to an internal error.</li>
+<li>
+Nonzero means that remaining packets have successfully been flushed into the page.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_flush_fill.html

@@ -0,0 +1,74 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_stream_flush_fill</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_flush_fill</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function flushes available packets into pages, similar to
+<a href="ogg_stream_flush.html">ogg_stream_flush()</a>, but
+allows applications to explicitly request a specific page spill
+size.</p>
+
+<p>This function checks for remaining packets inside the stream and forces remaining packets into pages of approximately the requested size.
+This should be used when you want to flush all remaining data from a stream. <a href="ogg_stream_flush.html">ogg_stream_flush</a> may be used instead if a particular page size isn't important. 
+<p>This function can be used to verify that all packets have been flushed.  If the return value is 0, all packets have been placed into a page. Generally speaking, it should be called in a loop until all packets are flushed, since even a single packet may span multiple pages.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_stream_flush_fill(<a href="ogg_stream_state.html">ogg_stream_state</a> *os, <a href="ogg_page.html">ogg_page</a> *og, int fillbytes);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>os</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_stream_state.html">ogg_stream_state</a> struct, which represents the current logical bitstream.</dd>
+<dt><i>og</i></dt>
+<dd>Pointer to a page of data.  The remaining packets in the stream will be placed into this page, if any remain.
+<dt><i>fillbytes</i></dt>
+<dd>Packet data watermark in bytes.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>0 means that all packet data has already been flushed into pages, and there are no packets to put into the page.  0 is also returned in the case of an <a href="ogg_stream_state.html">ogg_stream_state</a> that has been cleared explicitly or implicitly due to an internal error.</li>
+<li>
+Nonzero means that remaining packets have successfully been flushed into the page.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_init.html

@@ -0,0 +1,66 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_stream_init</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_init</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function is used to initialize an <a href="ogg_sync_state.html">ogg_stream_state</a> struct and allocates appropriate memory in preparation for encoding or decoding.
+<p>It also assigns the stream a given serial number.
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_stream_init(<a href="ogg_stream_state.html">ogg_stream_state</a> *os,int serialno);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>os</i></dt>
+<dd>Pointer to the ogg_stream_state struct that we will be initializing.</dd>
+<dt><i>serialno</i></dt>
+<dd>Serial number that we will attach to this stream.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+0 if successful</li>
+<li>
+-1 if unsuccessful.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_iovecin.html

@@ -0,0 +1,80 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_stream_iovecin</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_iovecin</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function submits packet data (in the form of
+an array of <a href="ogg_iovec_t.html">ogg_iovec_t</a>, rather than using
+an <a href="ogg_packet.html">ogg_packet</a> structure) to the
+bitstream for page encapsulation. After this is called, more packets
+can be submitted, or pages can be written out.</p>
+
+<p>In a typical encoding situation, this should be used after filling a 
+packet with data.
+The data in the packet is copied into the internal storage managed by 
+the <a href="ogg_stream_state.html">ogg_stream_state</a>, so the caller
+is free to alter the contents of <i>os</i> after this call has returned.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_stream_iovecin(ogg_stream_state *os, ogg_iovec_t *iov, int count, long e_o_s, ogg_int64_t granulepos);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>os</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_stream_state.html">ogg_stream_state</a> struct.</dd>
+<dt><i>iov</i></dt>
+<dd>Length-encoded buffers held in an array of <a href="ogg_iovec_t.html">ogg_iovec_t</a>.
+<dt><i>count</i></dt>
+<dd>Length of the iov array.
+<dt><i>e_o_s</i></dt>
+<dd>End of stream flag, analagous to the e_o_s field in an <a href="ogg_packet.html">ogg_packet</a>.
+<dt><i>granulepos</i></dt>
+<dd>Granule position value, analagous to the granpos field in an <a href="ogg_packet.html">ogg_packet</a>.
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+0 returned on success.  -1 returned in the event of internal error.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_packetin.html

@@ -0,0 +1,72 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_stream_packetin</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_packetin</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function submits a packet to the bitstream for page 
+encapsulation. After this is called, more packets can be submitted,
+or pages can be written out.</p>
+
+<p>In a typical encoding situation, this should be used after filling a 
+packet with data.
+The data in the packet is copied into the internal storage managed by 
+the <a href="ogg_stream_state.html">ogg_stream_state</a>, so the caller
+is free to alter the contents of <i>op</i> after this call has returned.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_stream_packetin(ogg_stream_state *os,ogg_packet *op);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>os</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_stream_state.html">ogg_stream_state</a> struct.</dd>
+<dt><i>op</i></dt>
+<dd>Pointer to the packet we are putting into the bitstream.
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+0 returned on success.  -1 returned in the event of internal error.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_packetout.html

@@ -0,0 +1,85 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_stream_packetout</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_packetout</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function assembles a data packet for output to the codec 
+decoding engine. The data has already been submitted to the
+<a href="ogg_stream_state.html">ogg_stream_state</a> and broken
+into segments. Each successive call returns the next complete packet 
+built from those segments.</p>
+
+<p>In a typical decoding situation, this should be used after calling 
+<a href="ogg_stream_pagein.html">ogg_stream_pagein()</a> to submit a 
+page of data to the bitstream. If the function returns 0, more data is 
+needed and another page should be submitted. A non-zero return value 
+indicates successful return of a packet.</p>
+
+<p>The <i>op</i> is filled in with pointers to memory managed by
+the stream state and is only valid until the next call. The client
+must copy the packet data if a longer lifetime is required.</p>
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_stream_packetout(ogg_stream_state *os,ogg_packet *op);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>os</i></dt>
+<dd>Pointer to a previously declared <a
+href="ogg_stream_state.html">ogg_stream_state</a> struct.  Before this function is called, an <a href="ogg_page.html">ogg_page</a> should be submitted to the stream using <a href="ogg_stream_pagein.html">ogg_stream_pagein()</a>.</dd>
+<dt><i>op</i></dt>
+<dd>Pointer to the packet to be filled in with pointers to the new data. 
+This will typically be submitted to a codec for decode after this 
+function is called. The pointers are only valid until the next call
+on this stream state.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<ul>
+<li>-1 if we are out of sync and there is a gap in the data. This is usually a recoverable error and subsequent calls to ogg_stream_packetout are likely to succeed. <i>op</i> has not been updated.</li>
+<li>0 if there is insufficient data available to complete a packet, or on unrecoverable internal error occurred. <i>op</i> has not been updated.
+<li>1 if a packet was assembled normally. <i>op</i> contains the next packet from the stream.</li>
+</ul>
+</blockquote>
+
+<br><br>
+
+<hr noshade>
+
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2010 xiph.org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_packetpeek.html

@@ -0,0 +1,85 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_stream_packetpeek</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_packetpeek</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function attempts to assemble a raw data packet and returns
+it without advancing decoding.</p>
+
+<p>In a typical situation, this would be called
+speculatively after <a
+href="ogg_stream_pagein.html">ogg_stream_pagein()</a> to check
+the packet contents before handing it off to a codec for 
+decompression. To advance page decoding and remove
+the packet from the sync structure, call 
+<a href="ogg_stream_packetout.html">ogg_stream_packetout()</a>.</p>
+
+<br><br>
+
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_stream_packetpeek(ogg_stream_state *os,ogg_packet *op);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>os</i></dt>
+<dd>Pointer to a previously declared 
+<a href="ogg_stream_state.html">ogg_stream_state</a> struct.  Before this
+function is called, an <a href="ogg_page.html">ogg_page</a> should be
+submitted to the stream using 
+<a href="ogg_stream_pagein.html">ogg_stream_pagein()</a>.</dd>
+<dt><i>op</i></dt>
+<dd>Pointer to the next packet available in the bitstream, if
+any. A NULL value may be passed in the case of a simple "is there a 
+packet?" check.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<ul>
+<li>-1 if there's no packet available due to lost sync or a hole in the data.</li>
+<li>0 if there is insufficient data available to complete a packet, or on unrecoverable internal error occurred.</li>
+<li>1 if a packet is available.</li>
+</ul>
+</blockquote>
+
+
+<br><br>
+
+<hr noshade>
+
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_pagein.html

@@ -0,0 +1,67 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_stream_pagein</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_pagein</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function adds a complete page to the bitstream.  
+ <p>In a typical decoding situation, this function would be called after using <a href="ogg_sync_pageout.html">ogg_sync_pageout</a> to create a valid <a href="ogg_page.html">ogg_page</a> struct.
+<p>Internally, this function breaks the page into packet segments in preparation for outputting a valid packet to the codec decoding layer.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_stream_pagein(<a href="ogg_stream_state.html">ogg_stream_state</a> *os, <a href="ogg_page.html">ogg_page</a> *og);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>os</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_stream_state.html">ogg_stream_state</a> struct, which represents the current logical bitstream.</dd>
+<dt><i>og</i></dt>
+<dd>Pointer to a page of data.  The data inside this page is being submitted to the streaming layer in order to be allocated into packets.
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>-1 indicates failure.  This means that the serial number of the page did not match the serial number of the bitstream, the page version was incorrect, or an internal error occurred.</li>
+<li>
+0 means that the page was successfully submitted to the bitstream.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_pageout.html

@@ -0,0 +1,84 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_stream_pageout</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_pageout</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function forms packets into pages.</p>
+
+<p>In a typical encoding situation, this would be called after using <a 
+href="ogg_stream_packetin.html">ogg_stream_packetin()</a> to submit 
+data packets to the bitstream. Internally, this function assembles 
+the accumulated packet bodies into an Ogg page suitable for writing 
+to a stream. The function is typically called in a loop until there
+are no more pages ready for output.</p>
+
+<p>This function will only return a page when a "reasonable" amount of 
+packet data is available. Normally this is appropriate since it 
+limits the overhead of the Ogg page headers in the bitstream, and so
+calling ogg_stream_pageout() after ogg_stream_packetin() should be the 
+common case. Call <a href="ogg_stream_flush.html">ogg_stream_flush()</a> 
+if immediate page generation is desired. This may be occasionally 
+necessary, for example, to limit the temporal latency of a variable 
+bitrate stream.</p>
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_stream_pageout(<a href="ogg_stream_state.html">ogg_stream_state</a> *os, <a href="ogg_page.html">ogg_page</a> *og);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>os</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_stream.html">ogg_stream</a> struct, which represents the current logical bitstream.</dd>
+<dt><i>og</i></dt>
+<dd>Pointer to an <a href="ogg_page.html">ogg_page</a> structure to fill
+in. Data pointed to is owned by libogg. The structure is valid until the 
+next call to ogg_stream_pageout(), ogg_stream_packetin(), or 
+ogg_stream_flush().</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>Zero means that insufficient data has accumulated to fill a page, or an internal error occurred. In 
+this case <i>og</i> is not modified.</li>
+<li>Non-zero means that a page has been completed and returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2010 xiph.org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_pageout_fill.html

@@ -0,0 +1,89 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_stream_pageout_fill</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_pageout_fill</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function forms packets into pages, similar
+to <a href="ogg_stream_pageout.html">ogg_stream_pageout()</a>, but
+allows applications to explicitly request a specific page spill
+size.</p>
+
+<p>In a typical encoding situation, this would be called after using <a 
+href="ogg_stream_packetin.html">ogg_stream_packetin()</a> to submit 
+data packets to the bitstream. Internally, this function assembles 
+the accumulated packet bodies into an Ogg page suitable for writing 
+to a stream. The function is typically called in a loop until there
+are no more pages ready for output.</p>
+
+<p>This function will return a page when at least four packets have
+been accumulated and accumulated packet data meets or exceeds the
+specified number of bytes, <b>and/or</b> when the accumulated packet
+data meets/exceeds the maximum page size regardless of accumulated
+packet count.
+Call <a href="ogg_stream_flush.html">ogg_stream_flush()</a> or
+<a href="ogg_stream_flush_fill.html">ogg_stream_flush_fill()</a> if
+immediate page generation is desired regardless of accumulated data.</p>
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_stream_pageout_fill(<a href="ogg_stream_state.html">ogg_stream_state</a> *os, <a href="ogg_page.html">ogg_page</a> *og, int fillbytes);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>os</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_stream.html">ogg_stream</a> struct, which represents the current logical bitstream.</dd>
+<dt><i>og</i></dt>
+<dd>Pointer to an <a href="ogg_page.html">ogg_page</a> structure to fill
+in. Data pointed to is owned by libogg. The structure is valid until the 
+next call to ogg_stream_pageout(), ogg_stream_packetin(), or 
+ogg_stream_flush().</dd>
+<dt><i>fillbytes</i></dt>
+<dd>Packet data watermark in bytes.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>Zero means that insufficient data has accumulated to fill a page, or an internal error occurred. In 
+this case <i>og</i> is not modified.</li>
+<li>Non-zero means that a page has been completed and returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2010 xiph.org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_reset.html

@@ -0,0 +1,61 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_stream_reset</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_reset</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function sets values in the <a href="ogg_stream_state.html">ogg_stream_state</a> struct back to initial values.
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_stream_reset(ogg_stream_state *os);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>os</i></dt>
+<dd>Pointer to the ogg_stream_state struct to be cleared.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+0 indicates success. nonzero is returned on internal error.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_reset_serialno.html

@@ -0,0 +1,67 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_stream_reset_serialno</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_reset</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function reinitializes the values in the 
+<a href="ogg_stream_state.html">ogg_stream_state</a>,
+just like <a href="ogg_stream_reset.html">ogg_stream_reset()</a>.
+Additionally, it sets the stream serial number to the given value.</p>
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_stream_reset_serialno(ogg_stream_state *os, int serialno);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>os</i></dt>
+<dd>Pointer to the ogg_stream_state struct to be cleared.</dd>
+<dt><i>serialno</i></dt>
+<dd>New stream serial number to use</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+0 indicates success. nonzero is returned on internal error.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org Foundation</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_stream_state.html

@@ -0,0 +1,121 @@
+<html>
+
+<head>
+<title>libogg - datatype - ogg_stream_state</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_stream_state</h1>
+
+<p><i>declared in "ogg/ogg.h"</i></p>
+
+<p>
+The ogg_stream_state struct tracks the current encode/decode state of the current logical bitstream.
+<p>
+
+<table border=0 width=100% color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+typedef struct {
+  unsigned char   *body_data;    /* bytes from packet bodies */
+  long    body_storage;          /* storage elements allocated */
+  long    body_fill;             /* elements stored; fill mark */
+  long    body_returned;         /* elements of fill returned */
+
+
+  int     *lacing_vals;    /* The values that will go to the segment table */
+  ogg_int64_t *granule_vals;      /* granulepos values for headers. Not compact
+                             this way, but it is simple coupled to the
+                             lacing fifo */
+  long    lacing_storage;
+  long    lacing_fill;
+  long    lacing_packet;
+  long    lacing_returned;
+
+  unsigned char    header[282];      /* working space for header encode */
+  int              header_fill;
+
+  int     e_o_s;          /* set when we have buffered the last packet in the
+                             logical bitstream */
+  int     b_o_s;          /* set after we've written the initial page
+                             of a logical bitstream */
+  long     serialno;
+  int      pageno;
+  ogg_int64_t  packetno;      /* sequence number for decode; the framing
+                             knows where there's a hole in the data,
+                             but we need coupling so that the codec
+                             (which is in a seperate abstraction
+                             layer) also knows about the gap */
+  ogg_int64_t   granulepos;
+
+} ogg_stream_state;
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Relevant Struct Members</h3>
+<dl>
+<dt><i>body_data</i></dt>
+<dd>Pointer to data from packet bodies.</dd>
+<dt><i>body_storage</i></dt>
+<dd>Storage allocated for bodies in bytes (filled or unfilled).</dd>
+<dt><i>body_fill</i></dt>
+<dd>Amount of storage filled with stored packet bodies.</dd>
+<dt><i>body_returned</i></dt>
+<dd>Number of elements returned from storage.</dd>
+<dt><i>lacing_vals</i></dt>
+<dd>String of lacing values for the packet segments within the current page.  Each value is a byte, indicating packet segment length.</dd>
+<dt><i>granule_vals</i></dt>
+<dd>Pointer to the lacing values for the packet segments within the current page.</dd>
+<dt><i>lacing_storage</i></dt>
+<dd>Total amount of storage (in bytes) allocated for storing lacing values.</dd>
+<dt><i>lacing_fill</i></dt>
+<dd>Fill marker for the current vs. total allocated storage of lacing values for the page.</dd>
+<dt><i>lacing_packet</i></dt>
+<dd>Lacing value for current packet segment.</dd>
+<dt><i>lacing_returned</i></dt>
+<dd>Number of lacing values returned from lacing_storage.</dd>
+<dt><i>header</i></dt>
+<dd>Temporary storage for page header during encode process, while the header is being created.</dd>
+<dt><i>header_fill</i></dt>
+<dd>Fill marker for header storage allocation.  Used during the header creation process.</dd>
+<dt><i>e_o_s</i></dt>
+<dd>Marker set when the last packet of the logical bitstream has been buffered.</dd>
+<dt><i>b_o_s</i></dt>
+<dd>Marker set after we have written the first page in the logical bitstream.</dd>
+<dt><i>serialno</i></dt>
+<dd>Serial number of this logical bitstream.</dd>
+<dt><i>pageno</i></dt>
+<dd>Number of the current page within the stream.</dd>
+<dt><i>packetno</i></dt>
+<dd>Number of the current packet.</dd>
+<dt><i>granulepos</i></dt>
+<dd>Exact position of decoding/encoding process.</dd>
+</dl>
+
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_sync_buffer.html

@@ -0,0 +1,67 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_sync_buffer</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_sync_buffer</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function is used to provide a properly-sized buffer for writing.
+<p>Buffer space which has already been returned is cleared, and the buffer is extended as necessary by the size plus some additional bytes.  Within the current implementation, an extra 4096 bytes are allocated, but applications should not rely on this additional buffer space.
+<p>The buffer exposed by this function is empty internal storage from the <a href="ogg_sync_state.html">ogg_sync_state</a> struct, beginning at the fill mark within the struct.
+<p>A pointer to this buffer is returned to be used by the calling application.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+char *ogg_sync_buffer(ogg_sync_state *oy, long size);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>oy</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct.</dd>
+<dt><i>size</i></dt>
+<dd>Size of the desired buffer.  The actual size of the buffer returned will be this size plus some extra bytes (currently 4096).
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+Returns a pointer to the newly allocated buffer or NULL on error</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_sync_check.html

@@ -0,0 +1,71 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_sync_check</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_sync_check</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function is used to check the error or readiness condition of an <a href="ogg_sync_state.html">ogg_sync_state</a> structure.  
+<p>It is safe practice to ignore unrecoverable errors (such as an internal error caused by a malloc() failure) returned by ogg stream synchronization calls. Should an
+internal error occur, the <a href="ogg_sync_state.html">ogg_sync_state</a> structure will be cleared (equivalent to a
+call to
+<a href="ogg_sync_clear.html">ogg_sync_clear</a>) and subsequent calls
+using this <a href="ogg_sync_state.html">ogg_sync_state</a> will be
+noops. Error detection is then handled via a single call to
+ogg_sync_check at the end of the operational block. </p>
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_sync_check(<a href="ogg_sync_state.html">ogg_sync_state</a> *oy);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>oy</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+0 is returned if the <a href="ogg_sync_state.html">ogg_sync_state</a> structure is initialized and ready.</li>
+<li>
+nonzero is returned if the structure was never initialized, or if an unrecoverable internal error occurred in a previous call using the passed in <a href="ogg_sync_state.html">ogg_sync_state</a> struct.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_sync_clear.html

@@ -0,0 +1,62 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_sync_clear</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_sync_clear</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function is used to free the internal storage of an <a href="ogg_sync_state.html">ogg_sync_state</a> struct and resets the struct to the initial state.  To free the entire struct, <a href="ogg_sync_destroy.html">ogg_sync_destroy</a> should be used instead.  In situations where the struct needs to be reset but the internal storage does not need to be freed, <a href="ogg_sync_reset.html">ogg_sync_reset</a> should be used.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_sync_clear(<a href="ogg_sync_state.html">ogg_sync_state</a> *oy);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>oy</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+0 is always returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_sync_destroy.html

@@ -0,0 +1,68 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_sync_destroy</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_sync_destroy</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function is used to destroy an <a href="ogg_sync_state.html">ogg_sync_state</a> struct and free all memory used.</p>
+
+<p>Note this calls free() on its argument so you should only use this 
+function if you've allocated the ogg_sync_state on the heap. If it is 
+allocated on the stack, or it will otherwise be freed by your 
+own code, use <a href="ogg_sync_clear.html">ogg_sync_clear</a> instead
+to release just the internal memory.</p>
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_sync_destroy(<a href="ogg_sync_state.html">ogg_sync_state</a> *oy);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>oy</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+0 is always returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_sync_init.html

@@ -0,0 +1,63 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_sync_init</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_sync_init</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function is used to initialize an <a href="ogg_sync_state.html">ogg_sync_state</a> struct to a known initial value in preparation for manipulation of an Ogg bitstream.
+<p>The ogg_sync struct is important when decoding, as it synchronizes retrieval and return of data.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_sync_init(<a href="ogg_sync_state.html">ogg_sync_state</a> *oy);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>oy</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct.  After this function call, this struct has been initialized.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+0 is always returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_sync_pageout.html

@@ -0,0 +1,77 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_sync_pageout</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_sync_pageout</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function takes the data stored in the buffer of the <a href="ogg_sync_state.html">ogg_sync_state</a> struct and inserts them into an <a href="ogg_page.html">ogg_page</a>.
+
+<p>In an actual decoding loop, this function should be called first to ensure that the buffer is cleared.  The example code below illustrates a clean reading loop which will fill and output pages.
+<p><b>Caution:</b>This function should be called before reading into the buffer to ensure that data does not remain in the ogg_sync_state struct.  Failing to do so may result in a memory leak.  See the example code below for details.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_sync_pageout(<a href="ogg_sync_state.html">ogg_sync_state</a> *oy, <a href="ogg_page.html">ogg_page</a> *og);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>oy</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct.  Normally, the internal storage of this struct should be filled with newly read data and verified using <a href="ogg_sync_wrote.html">ogg_sync_wrote</a>.</dd>
+<dt><i>og</i></dt>
+<dd>Pointer to page struct filled by this function.
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>-1 returned if stream has not yet captured sync (bytes were skipped).</li>
+<li>0 returned if more data needed or an internal error occurred.</li>
+<li>1 indicated a page was synced and returned.</li>
+</blockquote>
+<p>
+
+<h3>Example Usage</h3>
+<pre>
+if (ogg_sync_pageout(&oy, &og) != 1) {
+	buffer = ogg_sync_buffer(&oy, 8192);
+	bytes = fread(buffer, 1, 8192, stdin);
+	ogg_sync_wrote(&oy, bytes);
+}
+</pre>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_sync_pageseek.html

@@ -0,0 +1,68 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_sync_pageseek</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_sync_pageseek</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function synchronizes the ogg_sync_state struct to the next ogg_page.  
+ <p>This is useful when seeking within a bitstream.  ogg_sync_pageseek will synchronize to the next page in the bitstream and return information about how many bytes we advanced or skipped in order to do so.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_sync_pageseek(<a href="ogg_sync_state.html">ogg_sync_state</a> *oy, <a href="ogg_page.html">ogg_page</a> *og);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>oy</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct.</dd>
+<dt><i>og</i></dt>
+<dd>Pointer to a page (or an incomplete page) of data.  This is the page we are attempting to sync.
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>-n means that we skipped n bytes within the bitstream.</li>
+<li>
+0 means that the page isn't ready and we need more data, or than an internal error occurred.  No bytes have been skipped.</li>
+<li>
+n means that the page was synced at the current location, with a page length of n bytes.
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_sync_reset.html

@@ -0,0 +1,63 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_sync_reset</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_sync_reset</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function is used to reset the internal counters of the <a href="ogg_sync_state.html">ogg_sync_state</a> struct to initial values.
+<p>It is a good idea to call this before seeking within a bitstream.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_sync_reset(<a href="ogg_sync_state.html">ogg_sync_state</a> *oy);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>oy</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+0 is always returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_sync_state.html

@@ -0,0 +1,77 @@
+<html>
+
+<head>
+<title>libogg - datatype - ogg_sync_state</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_sync_state</h1>
+
+<p><i>declared in "ogg/ogg.h"</i></p>
+
+<p>
+The ogg_sync_state struct tracks the synchronization of the current page.
+<p>It is used during decoding to track the status of data as it is read in, synchronized, verified, and parsed into pages belonging to the various logical bistreams in the current physical bitstream link. 
+<p>
+
+<table border=0 width=100% color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+typedef struct {
+  unsigned char *data;
+  int storage;
+  int fill;
+  int returned;
+
+  int unsynced;
+  int headerbytes;
+  int bodybytes;
+} ogg_sync_state;
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Relevant Struct Members</h3>
+<dl>
+<dt><i>data</i></dt>
+<dd>Pointer to buffered stream data.</dd>
+<dt><i>storage</i></dt>
+<dd>Current allocated size of the stream buffer held in <tt>*data</tt>.</dd>
+<dt><i>fill</i></dt>
+<dd>The number of valid bytes currently held in <tt>*data</tt>; functions as the buffer head pointer.</dd>
+<dt><i>returned</i></dt>
+<dd>The number of bytes at the head of <tt>*data</tt> that have already been returned as pages; functions as the buffer tail pointer.</dd>
+<dt><i>unsynced</i></dt>
+<dd>Synchronization state flag; nonzero if sync has not yet been attained or has been lost.</dd>
+<dt><i>headerbytes</i></dt>
+<dd>If synced, the number of bytes used by the synced page's header.</dd>
+<dt><i>bodybytes</i></dt>
+<dd>If synced, the number of bytes used by the synced page's body.</dd>
+</dl>
+
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/ogg_sync_wrote.html

@@ -0,0 +1,73 @@
+<html>
+
+<head>
+<title>libogg - function - ogg_sync_wrote</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>ogg_sync_wrote</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function is used to tell the <a href="ogg_sync_state.html">ogg_sync_state</a> struct how many bytes we wrote into the buffer. 
+
+<p>
+The general proceedure is to request a pointer into an internal 
+<a href="ogg_sync_state.html">ogg_sync_state</a> buffer by calling 
+<a href="ogg_sync_buffer.html">ogg_sync_buffer()</a>. The buffer
+is then filled up to the requested size with new input, and 
+ogg_sync_wrote() is called to advance the fill pointer by however
+much data was actually available.</p>
+
+<br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int ogg_sync_wrote(<a href="ogg_sync_state.html">ogg_sync_state</a> *oy, long bytes);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>oy</i></dt>
+<dd>Pointer to a previously declared <a href="ogg_sync_state.html">ogg_sync_state</a> struct.</dd>
+<dt><i>bytes</i></dt>
+<dd>Number of bytes of new data written.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>-1 if the number of bytes written overflows the internal storage of the <a href="ogg_sync_state.html">ogg_sync_state</a> struct or an internal error occurred.
+<li>
+0 in all other cases.</li>
+</blockquote>
+
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_adv.html

@@ -0,0 +1,64 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_adv</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_adv</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function advances the location pointer by the specified number of bits without reading any data.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+void  oggpack_adv(oggpack_buffer *b,int bits);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd>Pointer to the current oggpack_buffer.</dd>
+<dt><i>bits</i></dt>
+<dd>Number of bits to advance.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+No values are returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org Foundation</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_adv1.html

@@ -0,0 +1,62 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_adv1</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_adv1</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function advances the location pointer by one bit without reading any data.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+void  oggpack_adv1(oggpack_buffer *b);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd>Pointer to the current oggpack_buffer.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>No values are returned.
+</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_bits.html

@@ -0,0 +1,62 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_bits</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_bits</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function returns the total number of bits currently in the <a href="oggpack_buffer.html">oggpack_buffer</a>'s internal buffer.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+long oggpack_bits(<a href="oggpack_buffer.html">oggpack_buffer</a> *b);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd><a href="oggpack_buffer.html">oggpack_buffer</a> struct to be .</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+<i>n</i> is the total number of bits within the current buffer.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_buffer.html

@@ -0,0 +1,66 @@
+<html>
+
+<head>
+<title>libogg - datatype - oggpack_buffer</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_buffer</h1>
+
+<p><i>declared in "ogg/ogg.h"</i></p>
+
+<p>
+The oggpack_buffer struct is used with libogg's bitpacking functions.  You should never need to directly access anything in this structure.
+<p>
+
+<table border=0 width=100% color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+typedef struct {
+  long endbyte;
+  int  endbit;
+
+  unsigned char *buffer;
+  unsigned char *ptr;
+  long storage;
+} oggpack_buffer;
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Relevant Struct Members</h3>
+<dl>
+<dt><i>buffer</i></dt>
+<dd>Pointer to data being manipulated.</dd>
+<dt><i>ptr</i></dt>
+<dd>Location pointer to mark which data has been read.</dd>
+<dt><i>storage</i></dt>
+<dd>Size of buffer.</i></dt>
+</dl>
+
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_bytes.html

@@ -0,0 +1,67 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_bytes</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_bytes</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function returns the total number of bytes behind the current 
+access point in the <a href="oggpack_buffer.html">oggpack_buffer</a>. 
+For write-initialized buffers, this is the number of complete bytes 
+written so far. For read-initialized buffers, it is the number of 
+complete bytes that have been read so far.
+<p>The return value is the number of <b>complete</b> bytes in the buffer.
+There may be extra (<8) bits.
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+long oggpack_bytes(<a href="oggpack_buffer.html">oggpack_buffer</a> *b);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd><a href="oggpack_buffer.html">oggpack_buffer</a> struct to be checked.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+<i>n</i> is the total number of bytes within the current buffer.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2010 xiph.org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_get_buffer.html

@@ -0,0 +1,62 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_get_buffer</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_get_buffer</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function returns a pointer to the data buffer within the given <a href="oggpack_buffer.html">oggpack_buffer</a> struct.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+unsigned char *oggpack_get_buffer(<a href="oggpack_buffer.html">oggpack_buffer</a> *b);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd>Pointer to the current <a href="oggpack_buffer.html">oggpack_buffer</a>.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+No values are returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_look.html

@@ -0,0 +1,66 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_look</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_look</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function looks at a specified number of bits inside the buffer without advancing the location pointer.
+<p>The specified number of bits are read, starting from the location pointer.
+<p>This function can be used to read 32 or fewer bits.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+long  oggpack_look(<a href="oggpack_buffer.html">oggpack_buffer</a> *b,int bits);
+</b></pre>
+</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd>Pointer to <a href="oggpack_buffer.html">oggpack_buffer</a> to be read.</dd>
+<dt><i>bits</i></dt>
+<dd>Number of bits to look at.  For this function, must be 32 or fewer.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+<i>n</i> represents the requested bits.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_look1.html

@@ -0,0 +1,63 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_look1</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_look1</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function looks at the next bit without advancing the location pointer.
+<p>The next bit is read starting from the location pointer.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+long  oggpack_look1(oggpack_buffer *b);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd>Pointer to an <a href="oggpack_buffer.html">oggpack_buffer</a> struct containing our buffer.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+<i>n</i> represents the value of the next bit after the location pointer.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_read.html

@@ -0,0 +1,65 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_read</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_read</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function reads the requested number of bits from the buffer and advances the location pointer.
+<p>Before reading, the buffer should be initialized using <a href="oggpack_readinit.html">oggpack_readinit</a>.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+long oggpack_read(oggpack_buffer *b,int bits);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd>Pointer to an <a href="oggpack_buffer.html">oggpack_buffer</a> struct containing buffered data to be read.</dd>
+<dt><i>bits</i></dt>
+<dd>Number of bits to read.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+<i>n</i> represents the requested bits.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_read1.html

@@ -0,0 +1,63 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_read1</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_read1</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function reads one bit from the <a href="oggpack_buffer.html">oggpack_buffer</a> data buffer and advances the location pointer.
+<p>Before reading, the buffer should be initialized using <a href="oggpack_readinit.html">oggpack_readinit</a>.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+long  oggpack_read1(oggpack_buffer *b);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd>Pointer to an <a href="oggpack_buffer.html">oggpack_buffer</a> struct containing buffered data to be read.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+<i>n</i> is the bit read by this function.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_readinit.html

@@ -0,0 +1,64 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_readinit</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_readinit</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function takes an ordinary buffer and prepares an <a href="oggpack_buffer.html">oggpack_buffer</a> for reading using the Ogg <a href="bitpacking.html">bitpacking</a> functions.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+void oggpack_readinit(oggpack_buffer *b,unsigned char *buf,int bytes);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd>Pointer to <a href=oggpack_buffer.html">oggpack_buffer</a> to be initialized with some extra markers to ease bit navigation and manipulation.</dd>
+<dt><i>buf</i></dt>
+<dd>Original data buffer, to be inserted into the <a href="oggpack_buffer.html">oggpack_buffer</a> so that it can be read using bitpacking functions.
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+No values are returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_reset.html

@@ -0,0 +1,62 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_reset</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_reset</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function resets the contents of an <a href="oggpack_buffer">oggpack_buffer</a> to their original state but does not free the memory used.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+void  oggpack_reset(oggpack_buffer *b);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd><a href="oggpack_buffer.html">oggpack_buffer</a> to be reset.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+No values are returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_write.html

@@ -0,0 +1,68 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_write</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_write</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function writes bits into an <a href="oggpack_buffer.html">oggpack_buffer</a>.
+<p>The oggpack_buffer must already be initialized for writing using <a href="oggpack_writeinit.html">oggpack_writeinit</a>.
+<p>Only 32 bits can be written at a time.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+void  oggpack_write(oggpack_buffer *b,unsigned long value,int bits);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd>Buffer to be used for writing.</dd>
+<dt><i>value</i></dt>
+<dd>The data to be written into the buffer.  This must be 32 bits or fewer.</dd>
+<dt><i>bits</i></dt>
+<dd>The number of bits being written into the buffer.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+No values are returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_writealign.html

@@ -0,0 +1,65 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_writealign</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_writealign</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function pads the <a href="oggpack_buffer.html">oggpack_buffer</a> with zeros out to the
+next byte boundary.</p>
+<p>The oggpack_buffer must already be initialized for writing using <a href="oggpack_writeinit.html">oggpack_writeinit</a>.
+<p>Only 32 bits can be written at a time.</p>
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+void  oggpack_writetrunc(oggpack_buffer *b);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd>Buffer to be used for writing.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+No values are returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org Foundation</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_writecheck.html

@@ -0,0 +1,81 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_writecheck</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_writecheck</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function checks the readiness status of
+an <a href="oggpack_buffer.html">oggpack_buffer</a> previously
+initialized for writing using the
+Ogg <a href="bitpacking.html">bitpacking</a> functions.  A write
+buffer that encounters an error (such as a failed malloc) will clear
+its internal state and release any in-use memory, flagging itself as
+'not ready'.  Subsequent attempts to write using the buffer will
+silently fail. This error state may be detected at any later time by
+using oggpack_writecheck().  It is safe but not necessary to
+call <a href="oggpack_writeclear.html">oggpack_writeclear()</a> on a buffer that
+has flagged an error and released its resources. 
+
+<p><em>Important note to developers: Although libogg checks the
+results of memory allocations, these checks are only useful on a
+narrow range of embedded platforms. Allocation checks perform no
+useful service on a general purpose desktop OS where pages are
+routinely overallocated and all allocations succeed whether memory is
+available or not.  The only way to detect an out of memory condition
+on the vast majority of OSes is to watch for and capture segmentation
+faults.  This function is useful only to embedded developers.</em>
+ 
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+int  oggpack_writecheck(<a href="oggpack_buffer.html">oggpack_buffer</a> *b);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd>An <a href="oggpack_buffer.html">oggpack_buffer</a> previously initialized for writing.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li><i>zero</i>: buffer is ready for writing</li>
+<li><i>nonzero</i>: buffer is not ready or encountered an error</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_writeclear.html

@@ -0,0 +1,62 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_reset</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_writeclear</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function clears the buffer after writing and frees the memory used by the oggpack_buffer.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+void oggpack_writeclear(oggpack_buffer *b);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd>Our oggpack_buffer.  This is an ordinary data buffer with some extra markers to ease bit navigation and manipulation.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+No values are returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_writecopy.html

@@ -0,0 +1,69 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_writecopy</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_writecopy</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function copies a sequence of bits from a source buffer into an
+<a href="oggpack_buffer.html">oggpack_buffer</a>.</p>
+<p>The oggpack_buffer must already be initialized for writing using <a href="oggpack_writeinit.html">oggpack_writeinit</a>.</p>
+<p>Only 32 bits can be written at a time.</p>
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+void  oggpack_writecopy(oggpack_buffer *b, void *source, long bits);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd>Buffer to be used for writing.</dd>
+<dt><i>source</i></dt>
+<dd>A pointer to the data to be written into the buffer.</dd>
+<dt><i>bits</i></dt>
+<dd>The number of bits to be copied into the buffer.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+No values are returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org Foundation</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_writeinit.html

@@ -0,0 +1,62 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_writeinit</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_writeinit</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function initializes an <a href="oggpack_buffer.html">oggpack_buffer</a> for writing using the Ogg <a href="bitpacking.html">bitpacking</a> functions.
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+void  oggpack_writeinit(<a href="oggpack_buffer.html">oggpack_buffer</a> *b);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd>Buffer to be used for writing.  This is an ordinary data buffer with some extra markers to ease bit navigation and manipulation.</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+No values are returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/oggpack_writetrunc.html

@@ -0,0 +1,65 @@
+<html>
+
+<head>
+<title>libogg - function - oggpack_writetrunc</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>oggpack_writetrunc</h1>
+
+<p><i>declared in "ogg/ogg.h";</i></p>
+
+<p>This function truncates an already written-to <a href="oggpack_buffer.html">oggpack_buffer</a>.</p>
+<p>The oggpack_buffer must already be initialized for writing using <a href="oggpack_writeinit.html">oggpack_writeinit</a>.</p>
+
+<br><br>
+<table border=0 color=black cellspacing=0 cellpadding=7>
+<tr bgcolor=#cccccc>
+	<td>
+<pre><b>
+void  oggpack_writetrunc(oggpack_buffer *b, long bits);
+</b></pre>
+	</td>
+</tr>
+</table>
+
+<h3>Parameters</h3>
+<dl>
+<dt><i>b</i></dt>
+<dd>Buffer to be truncated.</dd>
+<dt><i>bits</i></dt>
+<dd>Number of bits to keep in the buffer (size after truncation)</dd>
+</dl>
+
+
+<h3>Return Values</h3>
+<blockquote>
+<li>
+No values are returned.</li>
+</blockquote>
+<p>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org Foundation</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/overview.html

@@ -0,0 +1,44 @@
+<html>
+
+<head>
+<title>libogg - API Overview</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>Libogg API Overview</h1>
+
+<p>
+The libogg API consists of the following functional categories:
+<p>
+<ul>
+<li><p><a href="datastructures.html">Base data structures</a>
+<li><p><a href="bitpacking.html">Bitpacking</a>
+<li><p><a href="general.html">General</a>
+<li><p><a href="encoding.html">Encoding-Related</a>
+<li><p><a href="decoding.html">Decoding-Related</a>
+
+</ul>
+
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/reference.html

@@ -0,0 +1,98 @@
+<html>
+
+<head>
+<title>Libogg API Reference</title>
+<link rel=stylesheet href="style.css" type="text/css">
+</head>
+
+<body bgcolor=white text=black link="#5555ff" alink="#5555ff" vlink="#5555ff">
+<table border=0 width=100%>
+<tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+<h1>Libogg API Reference</h1>
+
+<p>
+<b>Data Structures</b><br>
+<a href="oggpack_buffer.html">oggpack_buffer</a><br>
+<a href="ogg_page.html">ogg_page</a><br>
+<a href="ogg_stream_state.html">ogg_stream_state</a><br>
+<a href="ogg_packet.html">ogg_packet</a><br>
+<a href="ogg_sync_state.html">ogg_sync_state</a><br>
+<br>
+<b>Bitpacking</b><br>
+<a href="oggpack_writeinit.html">oggpack_writeinit()</a><br>
+<a href="oggpack_writecheck.html">oggpack_writecheck()</a><br>
+<a href="oggpack_reset.html">oggpack_reset()</a><br>
+<a href="oggpack_writetrunc.html">oggpack_writetrunc()</a><br>
+<a href="oggpack_writealign.html">oggpack_writealign()</a><br>
+<a href="oggpack_writecopy.html">oggpack_writecopy()</a><br>
+<a href="oggpack_writeclear.html">oggpack_writeclear()</a><br>
+<a href="oggpack_readinit.html">oggpack_readinit()</a><br>
+<a href="oggpack_write.html">oggpack_write()</a><br>
+<a href="oggpack_look.html">oggpack_look()</a><br>
+<a href="oggpack_look1.html">oggpack_look1()</a><br>
+<a href="oggpack_adv.html">oggpack_adv()</a><br>
+<a href="oggpack_adv1.html">oggpack_adv1()</a><br>
+<a href="oggpack_read.html">oggpack_read()</a><br>
+<a href="oggpack_read1.html">oggpack_read1()</a><br>
+<a href="oggpack_bytes.html">oggpack_bytes()</a><br>
+<a href="oggpack_bits.html">oggpack_bits()</a><br>
+<a href="oggpack_get_buffer.html">oggpack_get_buffer()</a><br>
+<br>
+<b>Decoding-Related</b><br>
+<a href="ogg_sync_init.html">ogg_sync_init()</a><br>
+<a href="ogg_sync_check.html">ogg_sync_check()</a><br>
+<a href="ogg_sync_clear.html">ogg_sync_clear()</a><br>
+<a href="ogg_sync_destroy.html">ogg_sync_destroy()</a><br>
+<a href="ogg_sync_reset.html">ogg_sync_reset()</a><br>
+<a href="ogg_sync_buffer.html">ogg_sync_buffer()</a><br>
+<a href="ogg_sync_wrote.html">ogg_sync_wrote()</a><br>
+<a href="ogg_sync_pageseek.html">ogg_sync_pageseek()</a><br>
+<a href="ogg_sync_pageout.html">ogg_sync_pageout()</a><br>
+<a href="ogg_stream_pagein.html">ogg_stream_pagein()</a><br>
+<a href="ogg_stream_packetout.html">ogg_stream_packetout()</a><br>
+<a href="ogg_stream_packetpeek.html">ogg_stream_packetpeek()</a><br>
+<br>
+<b>Encoding-Related</b><br>
+<a href="ogg_stream_packetin.html">ogg_stream_packetin()</a><br>
+<a href="ogg_stream_pageout.html">ogg_stream_pageout()</a><br>
+<a href="ogg_stream_pageout_fill.html">ogg_stream_pageout_fill()</a><br>
+<a href="ogg_stream_flush.html">ogg_stream_flush()</a><br>
+<a href="ogg_stream_flush_fill.html">ogg_stream_flush_fill()</a><br>
+<br>
+<b>General</b><br>
+<a href="ogg_stream_init.html">ogg_stream_init()</a><br>
+<a href="ogg_stream_check.html">ogg_stream_check()</a><br>
+<a href="ogg_stream_clear.html">ogg_stream_clear()</a><br>
+<a href="ogg_stream_reset.html">ogg_stream_reset()</a><br>
+<a href="ogg_stream_reset_serialno.html">ogg_stream_reset_serialno()</a><br>
+<a href="ogg_stream_destroy.html">ogg_stream_destroy()</a><br>
+<a href="ogg_page_version.html">ogg_page_version()</a><br>
+<a href="ogg_page_continued.html">ogg_page_continued()</a><br>
+<a href="ogg_page_packets.html">ogg_page_packets()</a></br>
+<a href="ogg_page_bos.html">ogg_page_bos()</a><br>
+<a href="ogg_page_eos.html">ogg_page_eos()</a><br>
+<a href="ogg_page_granulepos.html">ogg_page_granulepos()</a><br>
+<a href="ogg_page_serialno.html">ogg_page_serialno()</a><br>
+<a href="ogg_page_pageno.html">ogg_page_pageno()</a><br>
+<a href="ogg_packet_clear.html">ogg_packet_clear()</a><br>
+<a href="ogg_page_checksum_set.html">ogg_page_checksum_set()</a><br>
+<br><br>
+<hr noshade>
+<table border=0 width=100%>
+<tr valign=top>
+<td><p class=tiny>copyright &copy; 2000-2014 Xiph.Org Foundation</p></td>
+<td align=right><p class=tiny><a href="http://www.xiph.org/ogg/">Ogg Container Format</a></p></td>
+</tr><tr>
+<td><p class=tiny>libogg documentation</p></td>
+<td align=right><p class=tiny>libogg release 1.3.2 - 20140527</p></td>
+</tr>
+</table>
+
+</body>
+
+</html>

rhubarb/lib/ogg-1.3.3/doc/libogg/style.css

@@ -0,0 +1,7 @@
+BODY { font-family: Helvetica, sans-serif }
+TD { font-family: Helvetica, sans-serif }
+P { font-family: Helvetica, sans-serif }
+H1 { font-family: Helvetica, sans-serif }
+H2 { font-family: Helvetica, sans-serif }
+H4 { font-family: Helvetica, sans-serif }
+P.tiny { font-size: 8pt }

rhubarb/lib/ogg-1.3.3/doc/multiplex1.svg

@@ -0,0 +1,632 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="744.09448819"
+   height="1052.3622047"
+   id="svg2"
+   sodipodi:version="0.32"
+   inkscape:version="0.46"
+   sodipodi:docname="multiplex1.svg"
+   inkscape:output_extension="org.inkscape.output.svg.inkscape"
+   inkscape:export-filename="/home/xiphmont/MotherfishSVN/ogg/doc/multiplex1.png"
+   inkscape:export-xdpi="78.239998"
+   inkscape:export-ydpi="78.239998">
+  <defs
+     id="defs4">
+    <inkscape:perspective
+       sodipodi:type="inkscape:persp3d"
+       inkscape:vp_x="0 : 526.18109 : 1"
+       inkscape:vp_y="0 : 1000 : 0"
+       inkscape:vp_z="744.09448 : 526.18109 : 1"
+       inkscape:persp3d-origin="372.04724 : 350.78739 : 1"
+       id="perspective10" />
+  </defs>
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     gridtolerance="10000"
+     guidetolerance="10"
+     objecttolerance="10"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="0.98994949"
+     inkscape:cx="414.22127"
+     inkscape:cy="675.05057"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer1"
+     showgrid="true"
+     inkscape:window-width="1436"
+     inkscape:window-height="986"
+     inkscape:window-x="1776"
+     inkscape:window-y="26"
+     showguides="true"
+     inkscape:guide-bbox="true">
+    <inkscape:grid
+       type="xygrid"
+       id="grid2383" />
+  </sodipodi:namedview>
+  <metadata
+     id="metadata7">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1">
+    <text
+       xml:space="preserve"
+       style="font-size:12;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="147.14285"
+       y="265.93362"
+       id="text3566"><tspan
+         sodipodi:role="line"
+         id="tspan3568"
+         x="147.14285"
+         y="265.93362" /></text>
+    <text
+       xml:space="preserve"
+       style="font-size:12;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="144.28571"
+       y="265.21933"
+       id="text3570"><tspan
+         sodipodi:role="line"
+         id="tspan3572"
+         x="144.28571"
+         y="265.21933" /></text>
+    <text
+       xml:space="preserve"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="135.71429"
+       y="264.50504"
+       id="text3574"><tspan
+         sodipodi:role="line"
+         id="tspan3576"
+         x="135.71429"
+         y="264.50504" /></text>
+    <rect
+       style="fill:#bbddbb;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="rect3155"
+       width="90"
+       height="80"
+       x="80"
+       y="127.36218"
+       ry="0" />
+    <rect
+       ry="0"
+       y="127.36218"
+       x="580"
+       height="80"
+       width="90"
+       id="rect3188"
+       style="fill:#bbddbb;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+    <rect
+       style="fill:#bbddbb;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="rect3196"
+       width="90"
+       height="80"
+       x="480"
+       y="127.36218"
+       ry="0" />
+    <rect
+       ry="0"
+       y="127.36218"
+       x="380"
+       height="80"
+       width="90"
+       id="rect3204"
+       style="fill:#bbddbb;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+    <rect
+       style="fill:#bbddbb;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="rect3212"
+       width="90"
+       height="80"
+       x="280"
+       y="127.36218"
+       ry="0" />
+    <rect
+       ry="0"
+       y="127.36218"
+       x="180"
+       height="80"
+       width="90"
+       id="rect3220"
+       style="fill:#bbddbb;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+    <rect
+       style="fill:#5fd35f;fill-opacity:1;stroke:none;stroke-width:2.70000005;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="rect3258"
+       width="620"
+       height="40"
+       x="65"
+       y="157.36218"
+       ry="4.3460864e-06" />
+    <path
+       style="fill:#5fd35f;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
+       d="M 70,157.36218 L 70,147.36218 L 30,177.36218 L 70,207.36218 L 70,157.36218 z"
+       id="path3266"
+       sodipodi:nodetypes="ccccc" />
+    <path
+       style="font-size:24px;fill:#5fd35f;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
+       d="M 680,157.36218 L 680,147.36218 L 720,177.36218 L 680,207.36218 L 680,157.36218 z"
+       id="path3268" />
+    <rect
+       style="fill:#bbddbb;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="rect3260"
+       width="620"
+       height="20"
+       x="65"
+       y="102.36218"
+       ry="0"
+       inkscape:export-xdpi="78.239998"
+       inkscape:export-ydpi="78.239998" />
+    <path
+       style="fill:#bbddbb;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
+       d="M 70,102.36218 L 70,92.362183 L 40,112.36218 L 70,132.36218 L 70,102.36218 z"
+       id="path3262" />
+    <path
+       style="fill:#bbddbb;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
+       d="M 680,102.36218 L 680,92.362183 L 710,112.36218 L 680,132.36218 L 680,102.36218 z"
+       id="path3264" />
+    <text
+       xml:space="preserve"
+       style="font-size:24px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+       x="280"
+       y="122.36218"
+       id="text3270"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan3562"
+         x="280"
+         y="122.36218">elementary physical bitstream A</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:24px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="445"
+       y="192.36218"
+       id="text3274"><tspan
+         sodipodi:role="line"
+         id="tspan3276"
+         x="445"
+         y="192.36218">logical bitstream A</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="87.979683"
+       y="146.8571"
+       id="text3161"><tspan
+         sodipodi:role="line"
+         id="tspan3163"
+         x="87.979683"
+         y="146.8571">OggS</tspan></text>
+    <text
+       id="text3190"
+       y="146.8571"
+       x="587.97968"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       xml:space="preserve"><tspan
+         y="146.8571"
+         x="587.97968"
+         id="tspan3192"
+         sodipodi:role="line">OggS</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="487.97971"
+       y="146.8571"
+       id="text3198"><tspan
+         sodipodi:role="line"
+         id="tspan3200"
+         x="487.97971"
+         y="146.8571">OggS</tspan></text>
+    <text
+       id="text3206"
+       y="146.8571"
+       x="387.97971"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       xml:space="preserve"><tspan
+         y="146.8571"
+         x="387.97971"
+         id="tspan3208"
+         sodipodi:role="line">OggS</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="287.97971"
+       y="146.8571"
+       id="text3214"><tspan
+         sodipodi:role="line"
+         id="tspan3216"
+         x="287.97971"
+         y="146.8571">OggS</tspan></text>
+    <text
+       id="text3222"
+       y="146.8571"
+       x="187.97968"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       xml:space="preserve"><tspan
+         y="146.8571"
+         x="187.97968"
+         id="tspan3224"
+         sodipodi:role="line">OggS</tspan></text>
+    <path
+       sodipodi:nodetypes="ccccc"
+       id="path3372"
+       d="M 70,292.36218 L 70,282.36218 L 30,312.36218 L 70,342.36218 L 70,292.36218 z"
+       style="fill:#5fa3d3;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" />
+    <rect
+       ry="9.3506489"
+       y="262.36218"
+       x="80"
+       height="80"
+       width="90"
+       id="rect3318"
+       style="fill:#b5cfdf;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+    <rect
+       style="fill:#b5cfdf;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="rect3326"
+       width="90"
+       height="80"
+       x="580"
+       y="262.36218"
+       ry="9.3506489" />
+    <rect
+       ry="9.3506489"
+       y="262.36218"
+       x="480"
+       height="80"
+       width="90"
+       id="rect3334"
+       style="fill:#b5cfdf;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+    <rect
+       style="fill:#b5cfdf;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="rect3342"
+       width="90"
+       height="80"
+       x="380"
+       y="262.36218"
+       ry="9.3506489" />
+    <rect
+       ry="9.3506489"
+       y="262.36218"
+       x="280"
+       height="80"
+       width="90"
+       id="rect3350"
+       style="fill:#b5cfdf;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+    <rect
+       style="fill:#b5cfdf;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="rect3358"
+       width="90"
+       height="80"
+       x="180"
+       y="262.36218"
+       ry="9.3506489" />
+    <rect
+       ry="0.25253814"
+       y="292.36218"
+       x="65"
+       height="40"
+       width="620"
+       id="rect3364"
+       style="fill:#5fa3d3;fill-opacity:1;stroke:none;stroke-width:2.70000005;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+    <path
+       id="path3374"
+       d="M 680,292.36218 L 680,282.36218 L 720,312.36218 L 680,342.36218 L 680,292.36218 z"
+       style="font-size:24px;fill:#5fa3d3;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" />
+    <rect
+       ry="0"
+       y="237.36218"
+       x="65"
+       height="20"
+       width="620"
+       id="rect3366"
+       style="fill:#b5cfdf;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+    <path
+       id="path3368"
+       d="M 70,237.36218 L 70,227.36218 L 40,247.36218 L 70,267.36218 L 70,237.36218 z"
+       style="fill:#b5cfdf;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" />
+    <path
+       id="path3370"
+       d="M 680,237.36218 L 680,227.36218 L 710,247.36218 L 680,267.36218 L 680,237.36218 z"
+       style="fill:#b5cfdf;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate" />
+    <text
+       id="text3376"
+       y="257.36218"
+       x="280"
+       style="font-size:24px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+       xml:space="preserve"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan3564"
+         x="280"
+         y="257.36218">elementary physical bitstream B</tspan></text>
+    <text
+       id="text3380"
+       y="327.36218"
+       x="445"
+       style="font-size:24px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+       xml:space="preserve"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan3524"
+         x="445"
+         y="327.36218">logical bitstream B</tspan></text>
+    <text
+       id="text3320"
+       y="282.32013"
+       x="87.943802"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       xml:space="preserve"><tspan
+         y="282.32013"
+         x="87.943802"
+         id="tspan3322"
+         sodipodi:role="line">OggS</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="587.94385"
+       y="282.32013"
+       id="text3328"><tspan
+         sodipodi:role="line"
+         id="tspan3330"
+         x="587.94385"
+         y="282.32013">OggS</tspan></text>
+    <text
+       id="text3336"
+       y="282.32013"
+       x="487.94382"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       xml:space="preserve"><tspan
+         y="282.32013"
+         x="487.94382"
+         id="tspan3338"
+         sodipodi:role="line">OggS</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="387.94382"
+       y="282.32013"
+       id="text3344"><tspan
+         sodipodi:role="line"
+         id="tspan3346"
+         x="387.94382"
+         y="282.32013">OggS</tspan></text>
+    <text
+       id="text3352"
+       y="282.32013"
+       x="287.94382"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       xml:space="preserve"><tspan
+         y="282.32013"
+         x="287.94382"
+         id="tspan3354"
+         sodipodi:role="line">OggS</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="187.9438"
+       y="282.32013"
+       id="text3360"><tspan
+         sodipodi:role="line"
+         id="tspan3362"
+         x="187.9438"
+         y="282.32013">OggS</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:12px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="444.9722"
+       y="496.02066"
+       id="text3638"><tspan
+         sodipodi:role="line"
+         id="tspan3640"></tspan></text>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline"
+       d="M 365,352.36218 L 365,402.36218 L 335,392.36218 L 375,432.36218 L 415,392.36218 L 385,402.36218 L 385,352.36218 L 365,352.36218 z"
+       id="path3299" />
+    <rect
+       style="fill:#bbddbb;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="rect3388"
+       width="90"
+       height="80"
+       x="80.166489"
+       y="467.36224"
+       ry="0" />
+    <rect
+       ry="9.3506489"
+       y="467.36224"
+       x="580.1665"
+       height="80"
+       width="90"
+       id="rect3396"
+       style="fill:#b5cfdf;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+    <rect
+       style="fill:#bbddbb;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="rect3404"
+       width="89.833496"
+       height="80"
+       x="480.1665"
+       y="467.36224"
+       ry="0"
+       inkscape:export-xdpi="78.239998"
+       inkscape:export-ydpi="78.239998" />
+    <rect
+       ry="9.3506489"
+       y="467.36224"
+       x="380.1665"
+       height="80"
+       width="90"
+       id="rect3412"
+       style="fill:#b5cfdf;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+    <rect
+       style="fill:#bbddbb;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="rect3420"
+       width="90"
+       height="80"
+       x="280.1665"
+       y="467.36224"
+       ry="0" />
+    <rect
+       ry="9.3506489"
+       y="467.36224"
+       x="180.16649"
+       height="80"
+       width="90"
+       id="rect3428"
+       style="fill:#b5cfdf;fill-opacity:1;stroke:none;stroke-width:2.70000004999999987;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
+    <rect
+       style="fill:#5fd35f;fill-opacity:1;stroke:none;stroke-width:2.70000005;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="rect3434"
+       width="615.1665"
+       height="40.000061"
+       x="65"
+       y="497.36218"
+       ry="4.3460864e-06" />
+    <path
+       style="fill:#5fd35f;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
+       d="M 70.16649,497.36224 L 70.16649,487.36224 L 30.16649,517.36224 L 70.16649,547.36224 L 70.16649,497.36224 z"
+       id="path3442"
+       sodipodi:nodetypes="ccccc" />
+    <path
+       style="font-size:24px;fill:#5fd35f;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
+       d="M 680.16649,497.36224 L 680.16649,487.36224 L 720.16649,517.36224 L 680.16649,547.36224 L 680.16649,497.36224 z"
+       id="path3444" />
+    <rect
+       style="fill:#cccccc;fill-opacity:1;stroke:none;stroke-width:2.70000005;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       id="rect3436"
+       width="620"
+       height="20"
+       x="65"
+       y="442.36218"
+       ry="0" />
+    <path
+       style="fill:#cccccc;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
+       d="M 70.16649,442.36224 L 70.16649,432.36224 L 40.16649,452.36224 L 70.16649,472.36224 L 70.16649,442.36224 z"
+       id="path3438" />
+    <path
+       style="fill:#cccccc;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
+       d="M 680.16649,442.36224 L 680.16649,432.36224 L 710.16649,452.36224 L 680.16649,472.36224 L 680.16649,442.36224 z"
+       id="path3440" />
+    <text
+       xml:space="preserve"
+       style="font-size:24px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans;-inkscape-font-specification:Bitstream Vera Sans"
+       x="300.1665"
+       y="462.36224"
+       id="text3446"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan3526"
+         x="300.1665"
+         y="462.36224">multiplexed physical bitstream</tspan></text>
+    <path
+       style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#ffffff;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
+       d="M 175.16649,492.36224 L 175.16649,547.36224"
+       id="path3662" />
+    <path
+       style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#ffffff;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
+       d="M 275.16649,542.36224 L 275.16649,492.36224"
+       id="path3668" />
+    <path
+       style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#ffffff;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
+       d="M 375.16649,492.36224 L 375.16649,542.36224"
+       id="path3670" />
+    <path
+       style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#ffffff;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
+       d="M 475.16649,492.36224 L 475.16649,542.36224"
+       id="path3672" />
+    <path
+       style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
+       d="M 575.16649,492.36224 L 575.16649,542.36224"
+       id="path3674" />
+    <path
+       style="fill:#5fa3d3;fill-opacity:1;stroke:none;stroke-width:3;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="M 176.84389,517.32564 L 176.84389,497.37512 L 225.20495,497.37512 L 273.566,497.37512 L 273.566,517.32564 L 273.566,537.27615 L 225.20495,537.27615 L 176.84389,537.27615 L 176.84389,517.32564 z"
+       id="path3676" />
+    <path
+       style="fill:#5fa3d3;fill-opacity:1;stroke:none;stroke-width:3;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="M 376.79115,517.32564 L 376.79115,497.37512 L 425.1522,497.37512 L 473.51325,497.37512 L 473.51325,517.32564 L 473.51325,537.27615 L 425.1522,537.27615 L 376.79115,537.27615 L 376.79115,517.32564 z"
+       id="path3678" />
+    <path
+       style="fill:none;fill-opacity:1;fill-rule:evenodd;stroke:#ffffff;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
+       d="M 575.16649,492.36224 L 575.16649,542.36224"
+       id="path3680" />
+    <path
+       style="fill:#5fa3d3;fill-opacity:1;stroke:none;stroke-width:3;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="M 680.18684,542.21496 L 680.18684,537.27615 L 628.5428,537.27615 L 576.89875,537.27615 L 576.89875,517.32564 L 576.89875,497.37512 L 628.5428,497.37512 L 680.18684,497.37512 L 680.18684,492.45006 L 680.18684,487.525 L 700,502.36218 C 710.89722,510.52263 719.81813,517.27102 719.82422,517.3586 C 719.83225,517.47395 684.31753,544.18376 680.64581,546.82378 C 680.20662,547.13956 680.18684,546.94102 680.18684,542.21496 z"
+       id="path3682" />
+    <text
+       xml:space="preserve"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="88.110291"
+       y="487.82529"
+       id="text3390"><tspan
+         sodipodi:role="line"
+         id="tspan3392"
+         x="88.110291"
+         y="487.82529">OggS</tspan></text>
+    <text
+       id="text3398"
+       y="487.82529"
+       x="588.11029"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       xml:space="preserve"><tspan
+         y="487.82529"
+         x="588.11029"
+         id="tspan3400"
+         sodipodi:role="line">OggS</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="488.11032"
+       y="487.82529"
+       id="text3406"><tspan
+         sodipodi:role="line"
+         id="tspan3408"
+         x="488.11032"
+         y="487.82529">OggS</tspan></text>
+    <text
+       id="text3414"
+       y="487.82529"
+       x="388.11032"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       xml:space="preserve"><tspan
+         y="487.82529"
+         x="388.11032"
+         id="tspan3416"
+         sodipodi:role="line">OggS</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="288.11032"
+       y="487.82529"
+       id="text3422"><tspan
+         sodipodi:role="line"
+         id="tspan3424"
+         x="288.11032"
+         y="487.82529">OggS</tspan></text>
+    <text
+       id="text4306"
+       y="487.86862"
+       x="183.07068"
+       style="font-size:10px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       xml:space="preserve"><tspan
+         y="487.86862"
+         x="183.07068"
+         id="tspan4308"
+         sodipodi:role="line">OggS</tspan></text>
+  </g>
+</svg>

rhubarb/lib/ogg-1.3.3/doc/ogg-multiplex.html

@@ -0,0 +1,446 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html>
+<head>
+
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/>
+<title>Ogg Documentation</title>
+
+<style type="text/css">
+body {
+  margin: 0 18px 0 18px;
+  padding-bottom: 30px;
+  font-family: Verdana, Arial, Helvetica, sans-serif;
+  color: #333333;
+  font-size: .8em;
+}
+
+a {
+  color: #3366cc;
+}
+
+img {
+  border: 0;
+}
+
+#xiphlogo {
+  margin: 30px 0 16px 0;
+}
+
+#content p {
+  line-height: 1.4;
+}
+
+h1, h1 a, h2, h2 a, h3, h3 a, h4, h4 a {
+  font-weight: bold;
+  color: #ff9900;
+  margin: 1.3em 0 8px 0;
+}
+
+h1 {
+  font-size: 1.3em;
+}
+
+h2 {
+  font-size: 1.2em;
+}
+
+h3 {
+  font-size: 1.1em;
+}
+
+li {
+  line-height: 1.4;
+}
+
+#copyright {
+  margin-top: 30px;
+  line-height: 1.5em;
+  text-align: center;
+  font-size: .8em;
+  color: #888888;
+  clear: both;
+}
+</style>
+
+</head>
+
+<body>
+
+<div id="xiphlogo">
+  <a href="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.org"/></a>
+</div>
+
+<h1>Page Multiplexing and Ordering in a Physical Ogg Stream</h1>
+
+<p>The low-level mechanisms of an Ogg stream (as described in the Ogg
+Bitstream Overview) provide means for mixing multiple logical streams
+and media types into a single linear-chronological stream. This
+document specifies the high-level arrangement and use of page
+structure to multiplex multiple streams of mixed media type within a
+physical Ogg stream.</p>
+
+<h2>Design Elements</h2>
+
+<p>The design and arrangement of the Ogg container format is governed by
+several high-level design decisions that form the reasoning behind
+specific low-level design decisions.</p>
+
+<h3>Linear media</h3> 
+
+<p>The Ogg bitstream is intended to encapsulate chronological,
+time-linear mixed media into a single delivery stream or file. The
+design is such that an application can always encode and/or decode a
+full-featured bitstream in one pass with no seeking and minimal
+buffering. Seeking to provide optimized encoding (such as two-pass
+encoding) or interactive decoding (such as scrubbing or instant
+replay) is not disallowed or discouraged, however no bitstream feature
+must require nonlinear operation on the bitstream.</p>
+
+<h3>Multiplexing</h3>
+
+<p>Ogg bitstreams multiplex multiple logical streams into a single
+physical stream at the page level. Each page contains an abstract
+time stamp (the Granule Position) that represents an absolute time
+landmark within the stream. After the pages representing stream
+headers (all logical stream headers occur at the beginning of a
+physical bitstream section before any logical stream data), logical
+stream data pages are arranged in a physical bitstream in strict 
+non-decreasing order by chronological absolute time as 
+specified by the granule position.</p>
+
+<p>The only exception to arranging pages in strictly ascending time order
+by granule position is those pages that do not set the granule
+position value. This is a special case when exceptionally large
+packets span multiple pages; the specifics of handling this special
+case are described later under 'Continuous and Discontinuous
+Streams'.</p>
+
+<h3>Seeking</h3> 
+
+<p>Ogg is designed to use an interpolated bisection search to
+implement exact positional seeking.  Interpolated bisection search is
+a spec-mandated mechanism.</p>
+
+<p><i>An index may improve objective performance, but it seldom
+improves subjective performance outside of a few high-latency use
+cases and adds no additional functionality as bisection search
+delivers the same functionality for both one- and two-pass stream
+types.  For these reasons, use of indexes is discouraged, except in
+cases where an index provides demonstrable and noticable performance
+improvement.</i></p>
+
+<p>Seek operations are by absolute time; a direct bisection search must
+find the exact time position requested. Information in the Ogg
+bitstream is arranged such that all information to be presented for
+playback from the desired seek point will occur at or after the
+desired seek point. Seek operations are neither 'fuzzy' nor
+heuristic.</p>
+
+<p><i>Although key frame handling in video appears to be an exception to
+"all needed playback information lies ahead of a given seek",
+key frames can still be handled directly within this indexless
+framework. Seeking to a key frame in video (as well as seeking in other
+media types with analogous restraints) is handled as two seeks; first
+a seek to the desired time which extracts state information that
+decodes to the time of the last key frame, followed by a second seek
+directly to the key frame. The location of the previous key frame is
+embedded as state information in the granulepos; this mechanism is
+described in more detail later.</i></p>
+
+<h3>Continuous and Discontinuous Streams</h3>
+
+<p>Logical streams within a physical Ogg stream belong to one of two
+categories, "Continuous" streams and "Discontinuous" streams.
+Although these are discussed in more detail later, the distinction is
+important to a high-level understanding of how to buffer an Ogg
+stream.</p>
+
+<p>A stream that provides a gapless, time-continuous media type with a
+fine-grained timebase is considered to be 'Continuous'. A continuous
+stream should never be starved of data. Clear examples of continuous
+data types include broadcast audio and video.</p>
+
+<p>A stream that delivers data in a potentially irregular pattern or with
+widely spaced timing gaps is considered to be 'Discontinuous'. A
+discontinuous stream may be best thought of as data representing
+scattered events; although they happen in order, they are typically
+unconnected data often located far apart. One possible example of a
+discontinuous stream types would be captioning. Although it's
+possible to design captions as a continuous stream type, it's most
+natural to think of captions as widely spaced pieces of text with
+little happening between.</p>
+
+<p>The fundamental design distinction between continuous and
+discontinuous streams concerns buffering.</p>
+
+<h3>Buffering</h3>
+
+<p>Because a continuous stream is, by definition, gapless, Ogg buffering
+is based on the simple premise of never allowing any active continuous
+stream to starve for data during decode; buffering proceeds ahead
+until all continuous streams in a physical stream have data ready to
+decode on demand.</p>
+
+<p>Discontinuous stream data may occur on a fairly regular basis, but the
+timing of, for example, a specific caption is impossible to predict
+with certainty in most captioning systems. Thus the buffering system
+should take discontinuous data 'as it comes' rather than working ahead
+(for a potentially unbounded period) to look for future discontinuous
+data. As such, discontinuous streams are ignored when managing
+buffering; their pages simply 'fall out' of the stream when continuous
+streams are handled properly.</p>
+
+<p>Buffering requirements need not be explicitly declared or managed for
+the encoded stream; the decoder simply reads as much data as is
+necessary to keep all continuous stream types gapless (also ensuring
+discontinuous data arrives in time) and no more, resulting in optimum
+implicit buffer usage for a given stream. Because all pages of all
+data types are stamped with absolute timing information within the
+stream, inter-stream synchronization timing is always explicitly
+maintained without the need for explicitly declared buffer-ahead
+hinting.</p>
+
+<p>Further details, mechanisms and reasons for the differing arrangement
+and behavior of continuous and discontinuous streams is discussed
+later.</p>
+
+<h3>Whole-stream navigation</h3>
+
+<p>Ogg is designed so that the simplest navigation operations treat the
+physical Ogg stream as a whole summary of its streams, rather than
+navigating each interleaved stream as a separate entity.</p>
+
+<p>First Example: seeking to a desired time position in a multiplexed (or
+unmultiplexed) Ogg stream can be accomplished through a bisection
+search on time position of all pages in the stream (as encoded in the
+granule position). More powerful searches (such as a key frame-aware
+seek within video) are also possible with additional search
+complexity, but similar computational complexity.</p>
+
+<p>Second Example: A bitstream section may consist of three multiplexed
+streams of differing lengths. The result of multiplexing these
+streams should be thought of as a single mixed stream with a length
+equal to the longest of the three component streams. Although it is
+also possible to think of the multiplexed results as three concurrent
+streams of different lengths and it is possible to recover the three
+original streams, it will also become obvious that once multiplexed,
+it isn't possible to find the internal lengths of the component
+streams without a linear search of the whole bitstream section.
+However, it is possible to find the length of the whole bitstream
+section easily (in near-constant time per section) just as it is for a
+single-media unmultiplexed stream.</p>
+
+<h2>Granule Position</h2>
+
+<h3>Description</h3>
+
+<p>The Granule Position is a signed 64 bit field appearing in the header
+of every Ogg page. Although the granule position represents absolute
+time within a logical stream, its value does not necessarily directly
+encode a simple timestamp. It may represent frames elapsed (as in
+Vorbis), a simple timestamp, or a more complex bit-division encoding
+(such as in Theora). The exact encoding of the granule position is up
+to a specific codec.</p>
+
+<p>The granule position is governed by the following rules:</p>
+
+<ul>
+
+<li>Granule Position must always increase forward or remain equal from
+page to page, be unset, or be zero for a header page. The absolute
+time to which any correct sequence of granule position maps must
+similarly always increase forward or remain equal. <i>(A codec may
+make use of data, such as a control sequence, that only affects codec
+working state without producing data and thus advancing granule
+position and time. Although the packet sequence number increases in
+this case, the granule position, and thus the time position, do
+not.)</i></li>
+
+<li>Granule position may only be unset if there no packet defining a
+time boundary on the page (that is, if no packet in a continuous
+stream ends on the page, or no packet in a discontinuous stream begins
+on the page. This will be discussed in more detail under Continuous
+and Discontinuous streams).</li>
+
+<li>A codec must be able to translate a given granule position value
+to a unique, deterministic absolute time value through direct
+calculation. A codec is not required to be able to translate an
+absolute time value into a unique granule position value.</li>
+
+<li>Codecs shall choose a granule position definition that allows that
+codec means to seek as directly as possible to an immediately
+decodable point, such as the bit-divided granule position encoding of
+Theora allows the codec to seek efficiently to key frame without using
+an index. That is, additional information other than absolute time
+may be encoded into a granule position value so long as the granule
+position obeys the above points.</li>
+
+</ul>
+
+<h4>Example: timestamp</h4>
+
+<p>In general, a codec/stream type should choose the simplest granule
+position encoding that addresses its requirements. The examples here
+are by no means exhaustive of the possibilities within Ogg.</p>
+
+<p>A simple granule position could encode a timestamp directly. For
+example, a granule position that encoded milliseconds from beginning
+of stream would allow a logical stream length of over 100,000,000,000
+days before beginning a new logical stream (to avoid the granule
+position wrapping).</p>
+
+<h4>Example: framestamp</h4>
+
+<p>A simple millisecond timestamp granule encoding might suit many stream
+types, but a millisecond resolution is inappropriate to, eg, most
+audio encodings where exact single-sample resolution is generally a
+requirement. A millisecond is both too large a granule and often does
+not represent an integer number of samples.</p>
+
+<p>In the event that audio frames are always encoded as the same number of
+samples, the granule position could simply be a linear count of frames
+since beginning of stream. This has the advantages of being exact and
+efficient. Position in time would simply be <tt>[granule_position] *
+[samples_per_frame] / [samples_per_second]</tt>.</p>
+
+<h4>Example: samplestamp (Vorbis)</h4>
+
+<p>Frame counting is insufficient in codecs such as Vorbis where an audio
+frame [packet] encodes a variable number of samples. In Vorbis's
+case, the granule position is a count of the number of raw samples
+from the beginning of stream; the absolute time of
+a granule position is <tt>[granule_position] /
+[samples_per_second]</tt>.</p>
+ 
+<h4>Example: bit-divided framestamp (Theora)</h4>
+
+<p>Some video codecs may be able to use the simple framestamp scheme for
+granule position. However, most modern video codecs introduce at
+least the following complications:</p>
+
+<ul>
+
+<li>video frames are relatively far apart compared to audio samples;
+for this reason, the point at which a video frame changes to the next
+frame is usually a strictly defined offset within the frame 'period'.
+That is, video at 50fps could just as easily define frame transitions
+&lt;.015, .035, .055...&gt; as at &lt;.00, .02, .04...&gt;.</li>
+
+<li>frame rates often include drop-frames, leap-frames or other
+rational-but-non-integer timings.</li>
+
+<li>Decode must begin at a 'key frame' or 'I frame'. Keyframes usually
+occur relatively seldom.</li>
+
+</ul>
+
+<p>The first two points can be handled straightforwardly via the fact
+that the codec has complete control mapping granule position to
+absolute time; non-integer frame rates and offsets can be set in the
+codec's initial header, and the rest is just arithmetic.</p>
+
+<p>The third point appears trickier at first glance, but it too can be
+handled through the granule position mapping mechanism. Here we
+arrange the granule position in such a way that granule positions of
+key frames are easy to find. Divide the granule position into two
+fields; the most-significant bits are an absolute frame counter, but
+it's only updated at each key frame. The least significant bits encode
+the number of frames since the last key frame. In this way, each
+granule position both encodes the absolute time of the current frame
+as well as the absolute time of the last key frame.</p>
+
+<p>Seeking to a most recent preceding key frame is then accomplished by
+first seeking to the original desired point, inspecting the granulepos
+of the resulting video page, extracting from that granulepos the
+absolute time of the desired key frame, and then seeking directly to
+that key frame's page. Of course, it's still possible for an
+application to ignore key frames and use a simpler seeking algorithm
+(decode would be unable to present decoded video until the next
+key frame). Surprisingly many player applications do choose the
+simpler approach.</p>
+
+<h3>granule position, packets and pages</h3>
+
+<p>Although each packet of data in a logical stream theoretically has a
+specific granule position, only one granule position is encoded
+per page. It is possible to encode a logical stream such that each
+page contains only a single packet (so that granule positions are
+preserved for each packet), however a one-to-one packet/page mapping
+is not intended to be the general case.</p>
+
+<p>Because Ogg functions at the page, not packet, level, this
+once-per-page time information provides Ogg with the finest-grained
+time information is can use. Ogg passes this granule positioning data
+to the codec (along with the packets extracted from a page); it is the
+responsibility of codecs to track timing information at granularities
+finer than a single page.</p>
+
+<h3>start-time and end-time positioning</h3>
+
+<p>A granule position represents the <em>instantaneous time location
+between two pages</em>. However, continuous streams and discontinuous
+streams differ on whether the granulepos represents the end-time of
+the data on a page or the start-time. Continuous streams are
+'end-time' encoded; the granulepos represents the point in time
+immediately after the last data decoded from a page. Discontinuous
+streams are 'start-time' encoded; the granulepos represents the point
+in time of the first data decoded from the page.</p>
+
+<p>An Ogg stream type is declared continuous or discontinuous by its
+codec. A given codec may support both continuous and discontinuous
+operation so long as any given logical stream is continuous or
+discontinuous for its entirety and the codec is able to ascertain (and
+inform the Ogg layer) as to which after decoding the initial stream
+header. The majority of codecs will always be continuous (such as
+Vorbis) or discontinuous (such as Writ).</p>
+
+<p>Start- and end-time encoding do not affect multiplexing sort-order;
+pages are still sorted by the absolute time a given granulepos maps to
+regardless of whether that granulepos represents start- or
+end-time.</p>
+
+<h2>Multiplex/Demultiplex Division of Labor</h2>
+
+<p>The Ogg multiplex/demultiplex layer provides mechanisms for encoding
+raw packets into Ogg pages, decoding Ogg pages back into the original
+codec packets, determining the logical structure of an Ogg stream, and
+navigating through and synchronizing with an Ogg stream at a desired
+stream location. Strict multiplex/demultiplex operations are entirely
+in the Ogg domain and require no intervention from codecs.</p>
+
+<p>Implementation of more complex operations does require codec
+knowledge, however. Unlike other framing systems, Ogg maintains
+strict separation between framing and the framed bitstream data; Ogg
+does not replicate codec-specific information in the page/framing
+data, nor does Ogg blur the line between framing and stream
+data/metadata. Because Ogg is fully data-agnostic toward the data it
+frames, operations which require specifics of bitstream data (such as
+'seek to key frame') also require interaction with the codec layer
+(because, in this example, the Ogg layer is not aware of the concept
+of key frames). This is different from systems that blur the
+separation between framing and stream data in order to simplify the
+separation of code. The Ogg system purposely keeps the distinction in
+data simple so that later codec innovations are not constrained by
+framing design.</p>
+
+<p>For this reason, however, complex seeking operations require
+interaction with the codecs in order to decode the granule position of
+a given stream type back to absolute time or in order to find
+'decodable points' such as key frames in video.</p>
+
+<h2>Unsorted Discussion Points</h2>
+
+<p>flushes around key frames? RFC suggestion: repaginating or building a
+stream this way is nice but not required</p>
+
+<h2>Appendix A: multiplexing examples</h2>
+
+<div id="copyright">
+  The Xiph Fish Logo is a
+  trademark (&trade;) of Xiph.Org.<br/>
+
+  These pages &copy; 1994 - 2005 Xiph.Org. All rights reserved.
+</div>
+
+</body>
+</html>

rhubarb/lib/ogg-1.3.3/doc/oggstream.html

@@ -0,0 +1,594 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html>
+<head>
+
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/>
+<title>Ogg Documentation</title>
+
+<style type="text/css">
+body {
+  margin: 0 18px 0 18px;
+  padding-bottom: 30px;
+  font-family: Verdana, Arial, Helvetica, sans-serif;
+  color: #333333;
+  font-size: .8em;
+}
+
+a {
+  color: #3366cc;
+}
+
+img {
+  border: 0;
+}
+
+#xiphlogo {
+  margin: 30px 0 16px 0;
+}
+
+#content p {
+  line-height: 1.4;
+}
+
+h1, h1 a, h2, h2 a, h3, h3 a {
+  font-weight: bold;
+  color: #ff9900;
+  margin: 1.3em 0 8px 0;
+}
+
+h1 {
+  font-size: 1.3em;
+}
+
+h2 {
+  font-size: 1.2em;
+}
+
+h3 {
+  font-size: 1.1em;
+}
+
+li {
+  line-height: 1.4;
+}
+
+#copyright {
+  margin-top: 30px;
+  line-height: 1.5em;
+  text-align: center;
+  font-size: .8em;
+  color: #888888;
+  clear: both;
+}
+
+.caption {
+  color: #000000;
+  background-color: #aabbff;
+  margin: 1em;
+  margin-left: 2em;
+  margin-right: 2em;
+  padding: 1em;
+  padding-bottom: 0em;
+  overflow: hidden;
+}
+
+.caption p {
+  clear: none;
+}
+
+.caption img {
+  display: block;
+  margin: 0px;
+  margin-left: auto;
+  margin-right: auto;
+  margin-bottom: 1.5em;
+  background-color: #ffffff;
+  padding: 10px;
+}
+   
+#thepage {
+  margin-left: auto;
+  margin-right: auto;
+  width: 840px;
+}
+
+</style>
+
+</head>
+
+<body>
+<div id="thepage">
+
+<div id="xiphlogo">
+  <a href="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.org"/></a>
+</div>
+
+<h1>Ogg bitstream overview</h1>
+
+<p>This document serves as starting point for understanding the design
+and implementation of the Ogg container format.  If you're new to Ogg
+or merely want a high-level technical overview, start reading here.
+Other documents linked from the <a href="index.html">index page</a>
+give distilled technical descriptions and references of the container
+mechanisms.  This document is intended to aid understanding.
+
+<h2>Container format design points</h2>
+
+<p>Ogg is intended to be a simplest-possible container, concerned only
+with framing, ordering, and interleave. It can be used as a stream delivery
+mechanism, for media file storage, or as a building block toward
+implementing a more complex, non-linear container (for example, see
+the <a href="skeleton.html">Skeleton</a> or <a
+href="http://en.wikipedia.org/wiki/Annodex">Annodex/CMML</a>).
+
+<p>The Ogg container is not intended to be a monolithic
+'kitchen-sink'.  It exists only to frame and deliver in-order stream
+data and as such is vastly simpler than most other containers.
+Elementary and multiplexed streams are both constructed entirely from a
+single building block (an Ogg page) comprised of eight fields
+totalling twenty-eight bytes (the page header) a list of packet lengths
+(up to 255 bytes) and payload data (up to 65025 bytes).  The structure
+of every page is the same.  There are no optional fields or alternate
+encodings.
+
+<p>Stream and media metadata is contained in Ogg and not built into
+the Ogg container itself.  Metadata is thus compartmentalized and
+layered rather than part of a monolithic design, an especially good
+idea as no two groups seem able to agree on what a complete or
+complete-enough metadata set should be. In this way, the container and
+container implementation are isolated from unnecessary metadata design
+flux.
+
+<h3>Streaming</h3> 
+
+<p>The Ogg container is primarily a streaming format,
+encapsulating chronological, time-linear mixed media into a single
+delivery stream or file. The design is such that an application can
+always encode and/or decode all features of a bitstream in one pass
+with no seeking and minimal buffering.  Seeking to provide optimized
+encoding (such as two-pass encoding) or interactive decoding (such as
+scrubbing or instant replay) is not disallowed or discouraged, however
+no container feature requires nonlinear access of the bitstream.
+
+<h3>Variable Bit Rate, Variable Payload Size</h3>
+
+<p>Ogg is designed to contain any size data payload with bounded,
+predictable efficiency.  Ogg packets have no maximum size and a
+zero-byte minimum size.  There is no restriction on size changes from
+packet to packet. Variable size packets do not require the use of any
+optional or additional container features.  There is no optimal
+suggested packet size, though special consideration was paid to make
+sure 50-200 byte packets were no less efficient than larger packet
+sizes.  The original design criteria was a 2% overhead at 50 byte
+packets, dropping to a maximum working overhead of 1% with larger
+packets, and a typical working overhead of .5-.7% for most practical
+uses. 
+
+<h3>Simple pagination</h3>
+
+<p>Ogg is a byte-aligned container with no context-dependent, optional
+or variable-length fields.  Ogg requires no repacking of codec data.
+The page structure is written out in-line as packet data is submitted
+to the streaming abstraction.  In addition, it is possible to
+implement both Ogg mux and demux as MT-hot zero-copy abstractions (as
+is done in the Tremor sourcebase).
+
+<h3>Capture</h3>
+
+<p>Ogg is designed for efficient and immediate stream capture with
+high confidence.  Although packets have no size limit in Ogg, pages
+are a maximum of just under 64kB meaning that any Ogg stream can be
+captured with confidence after seeing 128kB of data or less [worst
+case; typical figure is 6kB] from any random starting point in the
+stream.
+
+<h3>Seeking</h3>
+
+<p>Ogg implements simple coarse- and fine-grained seeking by design.
+
+<p>Coarse seeking may be performed by simply 'moving the tone arm' to a
+new position and 'dropping the needle'.  Rapid capture with
+accompanying timecode from any location in an Ogg file is guaranteed
+by the stream design.  From the acquisition of the first timecode,
+all data needed to play back from that time code forward is ahead of
+the stream cursor.
+
+<p>Ogg implements full sample-granularity seeking using an
+interpolated bisection search built on the capture and timecode
+mechanisms used by coarse seeking.  As above, once a search finds
+the desired timecode, all data needed to play back from that time code
+forward is ahead of the stream cursor.
+
+<p>Both coarse and fine seeking use the page structure and sequencing
+inherent to the Ogg format.  All Ogg streams are fully seekable from
+creation; seekability is unaffected by truncation or missing data, and
+is tolerant of gross corruption.  Seek operations are neither 'fuzzy' nor
+heuristic.
+
+<p>Seeking without use of an index is a major point of the Ogg
+design. There two primary reasons why Ogg transport forgoes an index:
+			  
+<ol>
+
+<li>An index is only marginally useful in Ogg for the complexity
+added; it adds no new functionality and seldom improves performance
+noticeably.  Empirical testing shows that indexless interpolation
+search does not require many more seeks in practice than using an
+index would.
+
+<li>'Optional' indexes encourage lazy implementations that can seek
+only when indexes are present, or that implement indexless seeking
+only by building an internal index after reading the entire file
+beginning to end.  This has been the fate of other containers that
+specify optional indexing.
+
+</ol>
+
+<p>In addition, it must be possible to create an Ogg stream in a
+single pass. Although an optional index can simply be tacked on the
+end of the created stream, some software groups object to
+end-positioned indexes and claim to be unwilling to support indexes
+not located at the stream beginning.
+
+<p><i>All this said, it's become clear that an optional index is a
+demanded feature.  For this reason, the <a
+href="http://wiki.xiph.org/Ogg_Index">OggSkeleton now defines a
+proposed index.</a></i>
+
+<h3>Simple multiplexing</h3>
+
+<p>Ogg multiplexes streams by interleaving pages from multiple elementary streams into a
+multiplexed stream in time order.  The multiplexed pages are not
+altered.  Muxing an Ogg AV stream out of separate audio,
+video and data streams is akin to shuffling several decks of cards
+together into a single deck; the cards themselves remain unchanged.
+Demultiplexing is similarly simple (as the cards are marked).
+
+<p>The goal of this design is to make the mux/demux operation as
+trivial as possible to allow live streaming systems to build and
+rebuild streams on the fly with minimal CPU usage and no additional
+storage or latency requirements.
+
+<h3>Continuous and Discontinuous Media</h3>
+
+<p>Ogg streams belong to one of two categories, "Continuous" streams and
+"Discontinuous" streams.
+
+<p>A stream that provides a gapless, time-continuous media type with a
+fine-grained timebase is considered to be 'Continuous'. A continuous
+stream should never be starved of data. Examples of continuous data
+types include broadcast audio and video.
+
+<p>A stream that delivers data in a potentially irregular pattern or
+with widely spaced timing gaps is considered to be 'Discontinuous'. A
+discontinuous stream may be best thought of as data representing
+scattered events; although they happen in order, they are typically
+unconnected data often located far apart. One example of a
+discontinuous stream types would be captioning such as <a
+href="http://wiki.xiph.org/OggKate">Ogg Kate</a>. Although it's
+possible to design captions as a continuous stream type, it's most
+natural to think of captions as widely spaced pieces of text with
+little happening between.
+
+<p>The fundamental reason for distinction between continuous and
+discontinuous streams concerns buffering.
+
+<h3>Buffering</h3>
+
+<p>A continuous stream is, by definition, gapless. Ogg buffering is based
+on the simple premise of never allowing an active continuous stream
+to starve for data during decode; buffering works ahead until all
+continuous streams in a physical stream have data ready and no further.
+
+<p>Discontinuous stream data is not assumed to be predictable. The
+buffering design takes discontinuous data 'as it comes' rather than
+working ahead to look for future discontinuous data for a potentially
+unbounded period. Thus, the buffering process makes no attempt to fill
+discontinuous stream buffers; their pages simply 'fall out' of the
+stream when continuous streams are handled properly.
+
+<p>Buffering requirements in this design need not be explicitly
+declared or managed in the encoded stream. The decoder simply reads as
+much data as is necessary to keep all continuous stream types gapless
+and no more, with discontinuous data processed as it arrives in the
+continuous data. Buffering is implicitly optimal for the given
+stream. Because all pages of all data types are stamped with absolute
+timing information within the stream, inter-stream synchronization
+timing is always maintained without the need for explicitly declared
+buffer-ahead hinting.
+
+<h3>Codec metadata</h3>
+
+<p>Ogg does not replicate codec-specific metadata into the mux layer
+in an attempt to make the mux and codec layer implementations 'fully
+separable'.  Things like specific timebase, keyframing strategy, frame
+duration, etc, do not appear in the Ogg container.  The mux layer is,
+instead, expected to query a codec through a centralized interface,
+left to the implementation, for this data when it is needed.
+
+<p>Though modern design wisdom usually prefers to predict all possible
+needs of current and future codecs then embed these dependencies and
+the required metadata into the container itself, this strategy
+increases container specification complexity, fragility, and rigidity.
+The mux and codec code becomes more independent, but the
+specifications become logically less independent. A codec can't do
+what a container hasn't already provided for.  Novel codecs are harder
+to support, and you can do fewer useful things with the ones you've
+already got (eg, try to make a good splitter without using any codecs.
+Such a splitter is limited to splitting at keyframes only, or building
+yet another new mechanism into the container layer to mark what frames
+to skip displaying).
+
+<p>Ogg's design goes the opposite direction, where the specification
+is to be as simple, easy to understand, and 'proofed' against novel
+codecs as possible.  When an Ogg mux layer requires codec-specific
+information, it queries the codec (or a codec stub).  This trades a
+more complex implementation for a simpler, more flexible
+specification.
+
+<h3>Stream structure metadata</h3>
+
+<p>The Ogg container itself does not define a metadata system for
+declaring the structure and interrelations between multiple media
+types in a muxed stream.  That is, the Ogg container itself does not
+specify data like 'which steam is the subtitle stream?' or 'which
+video stream is the primary angle?'.  This metadata still exists, but
+is stored by the Ogg container rather than being built into the Ogg
+container itself.  Xiph specifies the 'Skeleton' metadata format for Ogg
+streams, but this decoupling of container and stream structure
+metadata means it is possible to use Ogg with any metadata
+specification without altering the container itself, or without stream
+structure metadata at all.
+
+<h3>Frame accurate absolute position</h3>
+
+<p>Every Ogg page is stamped with a 64 bit 'granule position' that
+serves as an absolute timestamp for mux and seeking.  A few nifty
+little tricks are usually also embedded in the granpos state, but
+we'll leave those aside for the moment (strictly speaking, they're
+part of each codec's mapping, not Ogg).
+
+<p>As previously mentioned above, granule positions are mapped into
+absolute timestamps by the codec, rather than being a hard timestamp.
+This allows maximally efficient use of the available 64 bits to
+address every sample/frame position without approximation while
+supporting new and previously unknown timebase encodings without
+needing to extend or update the mux layer.  When a codec needs a novel
+timebase, it simply brings the code for that mapping along with it.
+This is not a theoretical curiosity; new, wholly novel timebases were
+deployed with the adoption of both Theora and Dirac.  "Rolling INTRA"
+(keyframeless video) also benefits from novel use of the granule
+position.
+
+<h2>Ogg stream arrangement</h2>
+
+<h3>Packets, pages, and bitstreams</h3>
+
+<p>Ogg codecs place raw compressed data into <em>packets</em>.
+Packets are octet payloads containing the data needed for a single
+decompressed unit, eg, one video frame. Packets have no maximum size
+and may be zero length. They do not generally have any framing
+information; strung together, the unframed packets form a <em>logical
+bitstream</em> of codec data with no internal landmarks.
+
+<div class="caption">
+  <img src="packets.png"> 
+
+  <p> Packets of raw codec data are not typically internally framed.
+  When they are strung together into a stream without any container to
+  provide framing, they lose their individual boundaries. Seek and
+  capture are not possible within an unframed stream, and for many
+  codecs with variable length payloads and/or early-packet termination
+  (such as Vorbis), it may become impossible to recover the original
+  frame boundaries even if the stream is scanned linearly from
+  beginning to end.
+
+</div>
+
+<p>Logical bitstream packets are grouped and framed into Ogg pages
+along with a unique stream <em>serial number</em> to produce a
+<em>physical bitstream</em>.  An <em>elementary stream</em> is a
+physical bitstream containing only a single logical bitstream. Each
+page is a self contained entity, although a packet may be split and
+encoded across one or more pages. The page decode mechanism is
+designed to recognize, verify and handle single pages at a time from
+the overall bitstream.
+
+<div class="caption">
+  <img src="pages.png"> 
+
+  <p> The primary purpose of a container is to provide framing for raw
+  packets, marking the packet boundaries so the exact packets can be
+  retrieved for decode later.  The container also provides secondary
+  functions such as capture, timestamping, sequencing, stream
+  identification and so on.  Not all of these functions are represented in the diagram.
+
+  <p>In the Ogg container, pages do not necessarily contain
+  integer numbers of packets. Packets may span across page boundaries
+  or even multiple pages.  This is necessary as pages have a maximum
+  possible size in order to provide capture guarantees, but packet
+  size is unbounded.
+</div>
+
+
+<p><a href="framing.html">Ogg Bitstream Framing</a> specifies
+the page format of an Ogg bitstream, the packet coding process
+and elementary bitstreams in detail.
+
+<h3>Multiplexed bitstreams</h3>
+
+<p>Multiple logical/elementary bitstreams can be combined into a single
+<em>multiplexed bitstream</em> by interleaving whole pages from each
+contributing elementary stream in time order. The result is a single
+physical stream that multiplexes and frames multiple logical streams.
+Each logical stream is identified by the unique stream serial number
+stamped in its pages.  A physical stream may include a 'meta-header'
+(such as the <a href="skeleton.html">Ogg Skeleton</a>) comprising its
+own Ogg page at the beginning of the physical stream. A decoder
+recovers the original logical/elementary bitstreams out of the
+physical bitstream by taking the pages in order from the physical
+bitstream and redirecting them into the appropriate logical decoding
+entity.
+
+<div class="caption">
+  <img src="multiplex1.png"> 
+
+<p>Multiple media types are mutliplexed into a single Ogg stream by
+interleaving the pages from each elementary physical stream.  
+
+</div>
+
+<p><a href="ogg-multiplex.html">Ogg Bitstream Multiplexing</a> specifies
+proper multiplexing of an Ogg bitstream in detail.
+
+<h3>Chaining</h3>
+
+<p>Multiple Ogg physical bitstreams may be concatenated into a single new
+stream; this is <em>chaining</em>. The bitstreams do not overlap; the
+final page of a given logical bitstream is immediately followed by the
+initial page of the next.</p>
+
+<p>Each logical bitstream in a chain must have a unique serial number
+within the scope of the full physical bitstream, not only within a
+particular <em>link</em> or <em>segment</em> of the chain.</p>
+
+<h3>Continuous and discontinuous streams</h3>
+
+<p>Within Ogg, each stream must be declared (by the codec) to be
+continuous- or discontinuous-time.  Most codecs treat all streams they
+use as either inherently continuous- or discontinuous-time, although
+this is not a requirement. A codec may, as part of its mapping, choose
+according to data in the initial header.
+
+<p>Continuous-time pages are stamped by end-time, discontinuous pages
+are stamped by begin-time.  Pages in a multiplexed stream are
+interleaved in order of the time stamp regardless of stream type.
+Both continuous and discontinuous logical streams are used to seek
+within a physical stream, however only continuous streams are used to
+determine buffering depth; because discontinuous streams are stamped
+by start time, they will always 'fall out' at the proper time when
+buffering the continuous streams.  See 'Examples' for an illustration
+of the buffering mechanism.
+
+<h2>Multiplexing Requirements</h2>
+
+<p>Multiplexing requirements within Ogg are straightforward. When
+constructing a single-link (unchained) physical bitstream consisting
+of multiple elementary streams:
+
+<ol>
+
+<li><p> The initial header for each stream appears in sequence, each
+header on a single page.  All initial headers must appear with no
+intervening data (no auxiliary header pages or packets, no data pages
+or packets).  Order of the initial headers is unspecified. The
+'beginning of stream' flag is set on each initial header.
+
+<li><p> All auxiliary headers for all streams must follow.  Order
+is unspecified.  The final auxiliary header of each stream must flush
+its page.
+
+<li><p>Data pages for each stream follow, interleaved in time order. 
+
+<li><p>The final page of each stream sets the 'end of stream' flag.
+Unlike initial pages, terminal pages for the logical bitstreams need
+not occur contiguously; indeed it may not be possible for them to do so.
+</oL>
+
+<p><p>Each grouped bitstream must have a unique serial number within the
+scope of the physical bitstream.</p>
+
+<h3>chaining and multiplexing</h3>
+
+<p>Multiplexed and/or unmultiplexed bitstreams may be chained
+consecutively. Such a physical bitstream obeys all the rules of both
+chained and multiplexed streams.  Each link, when unchained, must
+stand on its own as a valid physical bitstream.  Chained streams do
+not mix or interleave; a new segment may not begin until all streams
+in the preceding segment have terminated. </p>
+
+<h2>Codec Mapping Requirements</h2>
+
+<p>Each codec is allowed some freedom in deciding how its logical
+bitstream is encapsulated into an Ogg bitstream (even if it is a
+trivial mapping, eg, 'plop the packets in and go'). This is the
+codec's <em>mapping</em>. Ogg imposes a few mapping requirements
+on any codec.
+
+<ol>
+
+<li><p>The <a href="framing.html">framing specification</a> defines
+'beginning of stream' and 'end of stream' page markers via a header
+flag (it is possible for a stream to consist of a single page). A
+correct stream always consists of an integer number of pages, an easy
+requirement given the variable size nature of pages.</p>
+
+<li><p>The first page of an elementary Ogg bitstream consists of a single,
+small 'initial header' packet that must include sufficient information
+to identify the exact CODEC type. From this initial header, the codec
+must also be able to determine its timebase and whether or not it is a
+continuous- or discontinuous-time stream.  The initial header must fit
+on a single page. If a codec makes use of auxiliary headers (for
+example, Vorbis uses two auxiliary headers), these headers must follow
+the initial header immediately.  The last header finishes its page;
+data begins on a fresh page.
+
+<p><p>As an example, Ogg Vorbis places the name and revision of the
+Vorbis CODEC, the audio rate and the audio quality into this initial
+header.  Vorbis comments and detailed codec setup appears in the larger
+auxiliary headers.</p>
+
+<li><p>Granule positions must be translatable to an exact absolute
+time value.  As described above, the mux layer is permitted to query a
+codec or codec stub plugin to perform this mapping. It is not
+necessary for an absolute time to be mappable into a single unique
+granule position value.
+
+<li><p>Codecs are not required to use a fixed duration-per-packet (for
+example, Vorbis does not).  the mux layer is permitted to query a
+codec or codec stub plugin for the time duration of a packet.
+
+<li><p>Although an absolute time need not be translatable to a unique
+granule position, a codec must be able to determine the unique granule
+position of the current packet using the granule position of a
+preceeding packet.
+
+<li><p>Packets and pages must be arranged in ascending
+granule-position and time order.
+
+</ol>
+
+<h2>Examples</h2>
+
+<em>[More to come shortly; this section is currently being revised and expanded]</em>
+
+<p>Below, we present an example of a multiplexed and chained bitstream:</p>
+
+<p><img src="stream.png" alt="stream"/></p>
+
+<p>In this example, we see pages from five total logical bitstreams
+multiplexed into a physical bitstream. Note the following
+characteristics:</p>
+
+<ol>
+<li>Multiplexed bitstreams in a given link begin together; all of the
+initial pages must appear before any data pages. When concurrently
+multiplexed groups are chained, the new group does not begin until all
+the bitstreams in the previous group have terminated.</li>
+
+<li>The ordering of pages of concurrently multiplexed bitstreams is
+goverened by timestamp (not shown here); there is no regular
+interleaving order.  Pages within a logical bitstream appear in
+sequence order.</li>
+</ol>
+
+<div id="copyright">
+  The Xiph Fish Logo is a
+  trademark (&trade;) of Xiph.Org.<br/>
+
+  These pages &copy; 1994 - 2010 Xiph.Org. All rights reserved.
+</div>
+
+</div>
+</body>
+</html>

rhubarb/lib/ogg-1.3.3/doc/packets.svg

@@ -0,0 +1,876 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="744.09448819"
+   height="1052.3622047"
+   id="svg2"
+   sodipodi:version="0.32"
+   inkscape:version="0.46"
+   sodipodi:docname="packets.svg"
+   inkscape:output_extension="org.inkscape.output.svg.inkscape"
+   inkscape:export-filename="/home/xiphmont/MotherfishSVN/ogg/doc/packets.png"
+   inkscape:export-xdpi="72"
+   inkscape:export-ydpi="72">
+  <defs
+     id="defs4">
+    <inkscape:perspective
+       sodipodi:type="inkscape:persp3d"
+       inkscape:vp_x="0 : 526.18109 : 1"
+       inkscape:vp_y="0 : 1000 : 0"
+       inkscape:vp_z="744.09448 : 526.18109 : 1"
+       inkscape:persp3d-origin="372.04724 : 350.78739 : 1"
+       id="perspective10" />
+  </defs>
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     gridtolerance="10000"
+     guidetolerance="10"
+     objecttolerance="10"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="0.98994949"
+     inkscape:cx="396.07243"
+     inkscape:cy="782.406"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer1"
+     showgrid="true"
+     inkscape:window-width="1367"
+     inkscape:window-height="979"
+     inkscape:window-x="1955"
+     inkscape:window-y="25">
+    <inkscape:grid
+       type="xygrid"
+       id="grid2383" />
+  </sodipodi:namedview>
+  <metadata
+     id="metadata7">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:groupmode="layer"
+     id="layer2"
+     inkscape:label="under"
+     style="display:inline">
+    <rect
+       style="opacity:1;fill:#5fd35f;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
+       id="rect3483"
+       width="695"
+       height="90"
+       x="20"
+       y="222.36218" />
+  </g>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     style="display:inline">
+    <g
+       id="g3301">
+      <rect
+         y="32.362183"
+         x="20"
+         height="90"
+         width="30"
+         id="rect2385"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="55"
+         height="90"
+         width="30"
+         id="rect2387"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="90"
+         height="90"
+         width="40"
+         id="rect2389"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="135"
+         height="90"
+         width="20"
+         id="rect2391"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="160"
+         height="90"
+         width="40"
+         id="rect2393"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="205"
+         height="90"
+         width="30"
+         id="rect2395"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="240"
+         height="90"
+         width="25"
+         id="rect2397"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="270"
+         height="90"
+         width="40"
+         id="rect2399"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="315"
+         height="90"
+         width="35"
+         id="rect2401"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="355"
+         height="90"
+         width="25"
+         id="rect2403"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="385"
+         height="90"
+         width="30"
+         id="rect2407"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="420"
+         height="90"
+         width="30"
+         id="rect2409"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="455"
+         height="90"
+         width="35"
+         id="rect2411"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="495"
+         height="90"
+         width="35"
+         id="rect2413"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="535"
+         height="90"
+         width="30"
+         id="rect2415"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="570"
+         height="90"
+         width="25"
+         id="rect2417"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="600"
+         height="90"
+         width="40"
+         id="rect2419"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="645"
+         height="90"
+         width="30"
+         id="rect2421"
+         style="fill:#5fd35f" />
+      <rect
+         y="32.362183"
+         x="680"
+         height="90"
+         width="35"
+         id="rect2423"
+         style="fill:#5fd35f" />
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text2445"
+         y="40"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="40"
+           x="-107.36218"
+           id="tspan2447"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="75"
+         id="text2449"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan2451"
+           x="-107.36218"
+           y="75">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text2453"
+         y="115"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="115"
+           x="-107.36218"
+           id="tspan2455"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="150"
+         id="text2457"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan2459"
+           x="-107.36218"
+           y="150">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text2461"
+         y="185"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="185"
+           x="-107.36218"
+           id="tspan2463"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="225"
+         id="text2465"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan2467"
+           x="-107.36218"
+           y="225">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text2469"
+         y="258.03046"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="258.03046"
+           x="-107.36218"
+           id="tspan2471"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="295"
+         id="text2473"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan2475"
+           x="-107.36218"
+           y="295">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text2477"
+         y="338.48477"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="338.48477"
+           x="-107.36218"
+           id="tspan2479"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="373.48477"
+         id="text2481"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan2483"
+           x="-107.36218"
+           y="373.48477">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text2485"
+         y="405"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="405"
+           x="-107.36218"
+           id="tspan2487"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="440"
+         id="text2489"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan2491"
+           x="-107.36218"
+           y="440">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text2493"
+         y="478.03046"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="478.03046"
+           x="-107.36218"
+           id="tspan2495"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="518.03046"
+         id="text2497"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan2499"
+           x="-107.36218"
+           y="518.03046">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text2501"
+         y="555"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="555"
+           x="-107.36218"
+           id="tspan2503"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="588.48474"
+         id="text2505"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan2507"
+           x="-107.36218"
+           y="588.48474">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text2509"
+         y="625"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="625"
+           x="-107.36218"
+           id="tspan2511"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="665"
+         id="text2513"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan2515"
+           x="-107.36218"
+           y="665">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text2517"
+         y="702.47461"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="702.47461"
+           x="-107.36218"
+           id="tspan2519"
+           sodipodi:role="line">packet</tspan></text>
+    </g>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="M 360,132.36218 L 360,182.36218 L 330,172.36218 L 370,212.36218 L 410,172.36218 L 380,182.36218 L 380,132.36218 L 360,132.36218 z"
+       id="path3299" />
+    <g
+       id="g3360"
+       transform="translate(0,190)">
+      <rect
+         style="fill:#5fd35f;stroke:none"
+         id="rect3362"
+         width="30"
+         height="90"
+         x="20"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3364"
+         width="30"
+         height="90"
+         x="55"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3366"
+         width="40"
+         height="90"
+         x="90"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3368"
+         width="20"
+         height="90"
+         x="135"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3370"
+         width="40"
+         height="90"
+         x="160"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3372"
+         width="30"
+         height="90"
+         x="205"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3374"
+         width="25"
+         height="90"
+         x="240"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3376"
+         width="40"
+         height="90"
+         x="270"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3378"
+         width="35"
+         height="90"
+         x="315"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3380"
+         width="25"
+         height="90"
+         x="355"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3382"
+         width="30"
+         height="90"
+         x="385"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3384"
+         width="30"
+         height="90"
+         x="420"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3386"
+         width="35"
+         height="90"
+         x="455"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3388"
+         width="35"
+         height="90"
+         x="495"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3390"
+         width="30"
+         height="90"
+         x="535"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3392"
+         width="25"
+         height="90"
+         x="570"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3394"
+         width="40"
+         height="90"
+         x="600"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3396"
+         width="30"
+         height="90"
+         x="645"
+         y="32.362183" />
+      <rect
+         style="fill:#5fd35f"
+         id="rect3398"
+         width="35"
+         height="90"
+         x="680"
+         y="32.362183" />
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="40"
+         id="text3400"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan3402"
+           x="-107.36218"
+           y="40">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text3404"
+         y="75"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="75"
+           x="-107.36218"
+           id="tspan3406"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="115"
+         id="text3408"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan3410"
+           x="-107.36218"
+           y="115">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text3412"
+         y="150"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="150"
+           x="-107.36218"
+           id="tspan3414"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="185"
+         id="text3416"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan3418"
+           x="-107.36218"
+           y="185">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text3420"
+         y="225"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="225"
+           x="-107.36218"
+           id="tspan3422"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="258.03046"
+         id="text3424"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan3426"
+           x="-107.36218"
+           y="258.03046">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text3428"
+         y="295"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="295"
+           x="-107.36218"
+           id="tspan3430"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="338.48477"
+         id="text3432"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan3434"
+           x="-107.36218"
+           y="338.48477">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text3436"
+         y="373.48477"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="373.48477"
+           x="-107.36218"
+           id="tspan3438"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="405"
+         id="text3440"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan3442"
+           x="-107.36218"
+           y="405">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text3444"
+         y="440"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="440"
+           x="-107.36218"
+           id="tspan3446"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="478.03046"
+         id="text3448"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan3450"
+           x="-107.36218"
+           y="478.03046">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text3452"
+         y="518.03046"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="518.03046"
+           x="-107.36218"
+           id="tspan3454"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="555"
+         id="text3456"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan3458"
+           x="-107.36218"
+           y="555">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text3460"
+         y="588.48474"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="588.48474"
+           x="-107.36218"
+           id="tspan3462"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="625"
+         id="text3464"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan3466"
+           x="-107.36218"
+           y="625">packet</tspan></text>
+      <text
+         inkscape:transform-center-y="21.605011"
+         inkscape:transform-center-x="-6.0662994"
+         transform="matrix(0,-1,1,0,0,0)"
+         id="text3468"
+         y="665"
+         x="-107.36218"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           y="665"
+           x="-107.36218"
+           id="tspan3470"
+           sodipodi:role="line">packet</tspan></text>
+      <text
+         xml:space="preserve"
+         style="font-size:18px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+         x="-107.36218"
+         y="702.47461"
+         id="text3472"
+         transform="matrix(0,-1,1,0,0,0)"
+         inkscape:transform-center-x="-6.0662994"
+         inkscape:transform-center-y="21.605011"><tspan
+           sodipodi:role="line"
+           id="tspan3474"
+           x="-107.36218"
+           y="702.47461">packet</tspan></text>
+    </g>
+    <text
+       xml:space="preserve"
+       style="font-size:24px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="540"
+       y="152.36218"
+       id="text13982"><tspan
+         sodipodi:role="line"
+         id="tspan13984"
+         x="540"
+         y="152.36218">packet stream</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:24px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;font-family:Bitstream Vera Sans"
+       x="390"
+       y="342.36218"
+       id="text13986"><tspan
+         sodipodi:role="line"
+         id="tspan13988"
+         x="390"
+         y="342.36218">unframed logical bitstream</tspan></text>
+  </g>
+</svg>

rhubarb/lib/ogg-1.3.3/doc/rfc3533.txt

@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                        S. Pfeiffer
+Request for Comments: 3533                                         CSIRO
+Category: Informational                                         May 2003
+
+
+                 The Ogg Encapsulation Format Version 0
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document describes the Ogg bitstream format version 0, which is
+   a general, freely-available encapsulation format for media streams.
+   It is able to encapsulate any kind and number of video and audio
+   encoding formats as well as other data streams in a single bitstream.
+
+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 BCP 14, RFC 2119 [2].
+
+Table of Contents
+
+   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2. Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .   2
+   3. Requirements for a generic encapsulation format  . . . . . . .   3
+   4. The Ogg bitstream format . . . . . . . . . . . . . . . . . . .   3
+   5. The encapsulation process  . . . . . . . . . . . . . . . . . .   6
+   6. The Ogg page format  . . . . . . . . . . . . . . . . . . . . .   9
+   7. Security Considerations  . . . . . . . . . . . . . . . . . . .  11
+   8. References . . . . . . . . . . . . . . . . . . . . . . . . . .  12
+   A. Glossary of terms and abbreviations  . . . . . . . . . . . . .  13
+   B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  14
+      Author's Address . . . . . . . . . . . . . . . . . . . . . . .  14
+      Full Copyright Statement . . . . . . . . . . . . . . . . . . .  15
+
+
+
+
+
+
+
+Pfeiffer                     Informational                      [Page 1]
+
+RFC 3533                          OGG                           May 2003
+
+
+1. Introduction
+
+   The Ogg bitstream format has been developed as a part of a larger
+   project aimed at creating a set of components for the coding and
+   decoding of multimedia content (codecs) which are to be freely
+   available and freely re-implementable, both in software and in
+   hardware for the computing community at large, including the Internet
+   community.  It is the intention of the Ogg developers represented by
+   Xiph.Org that it be usable without intellectual property concerns.
+
+   This document describes the Ogg bitstream format and how to use it to
+   encapsulate one or several media bitstreams created by one or several
+   encoders.  The Ogg transport bitstream is designed to provide
+   framing, error protection and seeking structure for higher-level
+   codec streams that consist of raw, unencapsulated data packets, such
+   as the Vorbis audio codec or the upcoming Tarkin and Theora video
+   codecs.  It is capable of interleaving different binary media and
+   other time-continuous data streams that are prepared by an encoder as
+   a sequence of data packets.  Ogg provides enough information to
+   properly separate data back into such encoder created data packets at
+   the original packet boundaries without relying on decoding to find
+   packet boundaries.
+
+   Please note that the MIME type application/ogg has been registered
+   with the IANA [1].
+
+2. Definitions
+
+   For describing the Ogg encapsulation process, a set of terms will be
+   used whose meaning needs to be well understood.  Therefore, some of
+   the most fundamental terms are defined now before we start with the
+   description of the requirements for a generic media stream
+   encapsulation format, the process of encapsulation, and the concrete
+   format of the Ogg bitstream.  See the Appendix for a more complete
+   glossary.
+
+   The result of an Ogg encapsulation is called the "Physical (Ogg)
+   Bitstream".  It encapsulates one or several encoder-created
+   bitstreams, which are called "Logical Bitstreams".  A logical
+   bitstream, provided to the Ogg encapsulation process, has a
+   structure, i.e., it is split up into a sequence of so-called
+   "Packets".  The packets are created by the encoder of that logical
+   bitstream and represent meaningful entities for that encoder only
+   (e.g., an uncompressed stream may use video frames as packets).  They
+   do not contain boundary information - strung together they appear to
+   be streams of random bytes with no landmarks.
+
+
+
+
+
+Pfeiffer                     Informational                      [Page 2]
+
+RFC 3533                          OGG                           May 2003
+
+
+   Please note that the term "packet" is not used in this document to
+   signify entities for transport over a network.
+
+3. Requirements for a generic encapsulation format
+
+   The design idea behind Ogg was to provide a generic, linear media
+   transport format to enable both file-based storage and stream-based
+   transmission of one or several interleaved media streams independent
+   of the encoding format of the media data.  Such an encapsulation
+   format needs to provide:
+
+   o  framing for logical bitstreams.
+
+   o  interleaving of different logical bitstreams.
+
+   o  detection of corruption.
+
+   o  recapture after a parsing error.
+
+   o  position landmarks for direct random access of arbitrary positions
+      in the bitstream.
+
+   o  streaming capability (i.e., no seeking is needed to build a 100%
+      complete bitstream).
+
+   o  small overhead (i.e., use no more than approximately 1-2% of
+      bitstream bandwidth for packet boundary marking, high-level
+      framing, sync and seeking).
+
+   o  simplicity to enable fast parsing.
+
+   o  simple concatenation mechanism of several physical bitstreams.
+
+   All of these design considerations have been taken into consideration
+   for Ogg.  Ogg supports framing and interleaving of logical
+   bitstreams, seeking landmarks, detection of corruption, and stream
+   resynchronisation after a parsing error with no more than
+   approximately 1-2% overhead.  It is a generic framework to perform
+   encapsulation of time-continuous bitstreams.  It does not know any
+   specifics about the codec data that it encapsulates and is thus
+   independent of any media codec.
+
+4. The Ogg bitstream format
+
+   A physical Ogg bitstream consists of multiple logical bitstreams
+   interleaved in so-called "Pages".  Whole pages are taken in order
+   from multiple logical bitstreams multiplexed at the page level.  The
+   logical bitstreams are identified by a unique serial number in the
+
+
+
+Pfeiffer                     Informational                      [Page 3]
+
+RFC 3533                          OGG                           May 2003
+
+
+   header of each page of the physical bitstream.  This unique serial
+   number is created randomly and does not have any connection to the
+   content or encoder of the logical bitstream it represents.  Pages of
+   all logical bitstreams are concurrently interleaved, but they need
+   not be in a regular order - they are only required to be consecutive
+   within the logical bitstream.  Ogg demultiplexing reconstructs the
+   original logical bitstreams from the physical bitstream by taking the
+   pages in order from the physical bitstream and redirecting them into
+   the appropriate logical decoding entity.
+
+   Each Ogg page contains only one type of data as it belongs to one
+   logical bitstream only.  Pages are of variable size and have a page
+   header containing encapsulation and error recovery information.  Each
+   logical bitstream in a physical Ogg bitstream starts with a special
+   start page (bos=beginning of stream) and ends with a special page
+   (eos=end of stream).
+
+   The bos page contains information to uniquely identify the codec type
+   and MAY contain information to set up the decoding process.  The bos
+   page SHOULD also contain information about the encoded media - for
+   example, for audio, it should contain the sample rate and number of
+   channels.  By convention, the first bytes of the bos page contain
+   magic data that uniquely identifies the required codec.  It is the
+   responsibility of anyone fielding a new codec to make sure it is
+   possible to reliably distinguish his/her codec from all other codecs
+   in use.  There is no fixed way to detect the end of the codec-
+   identifying marker.  The format of the bos page is dependent on the
+   codec and therefore MUST be given in the encapsulation specification
+   of that logical bitstream type.  Ogg also allows but does not require
+   secondary header packets after the bos page for logical bitstreams
+   and these must also precede any data packets in any logical
+   bitstream.  These subsequent header packets are framed into an
+   integral number of pages, which will not contain any data packets.
+   So, a physical bitstream begins with the bos pages of all logical
+   bitstreams containing one initial header packet per page, followed by
+   the subsidiary header packets of all streams, followed by pages
+   containing data packets.
+
+   The encapsulation specification for one or more logical bitstreams is
+   called a "media mapping".  An example for a media mapping is "Ogg
+   Vorbis", which uses the Ogg framework to encapsulate Vorbis-encoded
+   audio data for stream-based storage (such as files) and transport
+   (such as TCP streams or pipes).  Ogg Vorbis provides the name and
+   revision of the Vorbis codec, the audio rate and the audio quality on
+   the Ogg Vorbis bos page.  It also uses two additional header pages
+   per logical bitstream.  The Ogg Vorbis bos page starts with the byte
+   0x01, followed by "vorbis" (a total of 7 bytes of identifier).
+
+
+
+
+Pfeiffer                     Informational                      [Page 4]
+
+RFC 3533                          OGG                           May 2003
+
+
+   Ogg knows two types of multiplexing: concurrent multiplexing (so-
+   called "Grouping") and sequential multiplexing (so-called
+   "Chaining").  Grouping defines how to interleave several logical
+   bitstreams page-wise in the same physical bitstream.  Grouping is for
+   example needed for interleaving a video stream with several
+   synchronised audio tracks using different codecs in different logical
+   bitstreams.  Chaining on the other hand, is defined to provide a
+   simple mechanism to concatenate physical Ogg bitstreams, as is often
+   needed for streaming applications.
+
+   In grouping, all bos pages of all logical bitstreams MUST appear
+   together at the beginning of the Ogg bitstream.  The media mapping
+   specifies the order of the initial pages.  For example, the grouping
+   of a specific Ogg video and Ogg audio bitstream may specify that the
+   physical bitstream MUST begin with the bos page of the logical video
+   bitstream, followed by the bos page of the audio bitstream.  Unlike
+   bos pages, eos pages for the logical bitstreams need not all occur
+   contiguously.  Eos pages may be 'nil' pages, that is, pages
+   containing no content but simply a page header with position
+   information and the eos flag set in the page header.  Each grouped
+   logical bitstream MUST have a unique serial number within the scope
+   of the physical bitstream.
+
+   In chaining, complete logical bitstreams are concatenated.  The
+   bitstreams do not overlap, i.e., the eos page of a given logical
+   bitstream is immediately followed by the bos page of the next.  Each
+   chained logical bitstream MUST have a unique serial number within the
+   scope of the physical bitstream.
+
+   It is possible to consecutively chain groups of concurrently
+   multiplexed bitstreams.  The groups, when unchained, MUST stand on
+   their own as a valid concurrently multiplexed bitstream.  The
+   following diagram shows a schematic example of such a physical
+   bitstream that obeys all the rules of both grouped and chained
+   multiplexed bitstreams.
+
+               physical bitstream with pages of
+          different logical bitstreams grouped and chained
+      -------------------------------------------------------------
+      |*A*|*B*|*C*|A|A|C|B|A|B|#A#|C|...|B|C|#B#|#C#|*D*|D|...|#D#|
+      -------------------------------------------------------------
+       bos bos bos             eos           eos eos bos       eos
+
+   In this example, there are two chained physical bitstreams, the first
+   of which is a grouped stream of three logical bitstreams A, B, and C.
+   The second physical bitstream is chained after the end of the grouped
+   bitstream, which ends after the last eos page of all its grouped
+   logical bitstreams.  As can be seen, grouped bitstreams begin
+
+
+
+Pfeiffer                     Informational                      [Page 5]
+
+RFC 3533                          OGG                           May 2003
+
+
+   together - all of the bos pages MUST appear before any data pages.
+   It can also be seen that pages of concurrently multiplexed bitstreams
+   need not conform to a regular order.  And it can be seen that a
+   grouped bitstream can end long before the other bitstreams in the
+   group end.
+
+   Ogg does not know any specifics about the codec data except that each
+   logical bitstream belongs to a different codec, the data from the
+   codec comes in order and has position markers (so-called "Granule
+   positions").  Ogg does not have a concept of 'time': it only knows
+   about sequentially increasing, unitless position markers.  An
+   application can only get temporal information through higher layers
+   which have access to the codec APIs to assign and convert granule
+   positions or time.
+
+   A specific definition of a media mapping using Ogg may put further
+   constraints on its specific use of the Ogg bitstream format.  For
+   example, a specific media mapping may require that all the eos pages
+   for all grouped bitstreams need to appear in direct sequence.  An
+   example for a media mapping is the specification of "Ogg Vorbis".
+   Another example is the upcoming "Ogg Theora" specification which
+   encapsulates Theora-encoded video data and usually comes multiplexed
+   with a Vorbis stream for an Ogg containing synchronised audio and
+   video.  As Ogg does not specify temporal relationships between the
+   encapsulated concurrently multiplexed bitstreams, the temporal
+   synchronisation between the audio and video stream will be specified
+   in this media mapping.  To enable streaming, pages from various
+   logical bitstreams will typically be interleaved in chronological
+   order.
+
+5. The encapsulation process
+
+   The process of multiplexing different logical bitstreams happens at
+   the level of pages as described above.  The bitstreams provided by
+   encoders are however handed over to Ogg as so-called "Packets" with
+   packet boundaries dependent on the encoding format.  The process of
+   encapsulating packets into pages will be described now.
+
+   From Ogg's perspective, packets can be of any arbitrary size.  A
+   specific media mapping will define how to group or break up packets
+   from a specific media encoder.  As Ogg pages have a maximum size of
+   about 64 kBytes, sometimes a packet has to be distributed over
+   several pages.  To simplify that process, Ogg divides each packet
+   into 255 byte long chunks plus a final shorter chunk.  These chunks
+   are called "Ogg Segments".  They are only a logical construct and do
+   not have a header for themselves.
+
+
+
+
+
+Pfeiffer                     Informational                      [Page 6]
+
+RFC 3533                          OGG                           May 2003
+
+
+   A group of contiguous segments is wrapped into a variable length page
+   preceded by a header.  A segment table in the page header tells about
+   the "Lacing values" (sizes) of the segments included in the page.  A
+   flag in the page header tells whether a page contains a packet
+   continued from a previous page.  Note that a lacing value of 255
+   implies that a second lacing value follows in the packet, and a value
+   of less than 255 marks the end of the packet after that many
+   additional bytes.  A packet of 255 bytes (or a multiple of 255 bytes)
+   is terminated by a lacing value of 0.  Note also that a 'nil' (zero
+   length) packet is not an error; it consists of nothing more than a
+   lacing value of zero in the header.
+
+   The encoding is optimized for speed and the expected case of the
+   majority of packets being between 50 and 200 bytes large.  This is a
+   design justification rather than a recommendation.  This encoding
+   both avoids imposing a maximum packet size as well as imposing
+   minimum overhead on small packets.  In contrast, e.g., simply using
+   two bytes at the head of every packet and having a max packet size of
+   32 kBytes would always penalize small packets (< 255 bytes, the
+   typical case) with twice the segmentation overhead.  Using the lacing
+   values as suggested, small packets see the minimum possible byte-
+   aligned overhead (1 byte) and large packets (>512 bytes) see a fairly
+   constant ~0.5% overhead on encoding space.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer                     Informational                      [Page 7]
+
+RFC 3533                          OGG                           May 2003
+
+
+   The following diagram shows a schematic example of a media mapping
+   using Ogg and grouped logical bitstreams:
+
+          logical bitstream with packet boundaries
+ -----------------------------------------------------------------
+ > |       packet_1             | packet_2         | packet_3 |  <
+ -----------------------------------------------------------------
+
+                     |segmentation (logically only)
+                     v
+
+      packet_1 (5 segments)          packet_2 (4 segs)    p_3 (2 segs)
+     ------------------------------ -------------------- ------------
+ ..  |seg_1|seg_2|seg_3|seg_4|s_5 | |seg_1|seg_2|seg_3|| |seg_1|s_2 | ..
+     ------------------------------ -------------------- ------------
+
+                     | page encapsulation
+                     v
+
+ page_1 (packet_1 data)   page_2 (pket_1 data)   page_3 (packet_2 data)
+------------------------  ----------------  ------------------------
+|H|------------------- |  |H|----------- |  |H|------------------- |
+|D||seg_1|seg_2|seg_3| |  |D|seg_4|s_5 | |  |D||seg_1|seg_2|seg_3| | ...
+|R|------------------- |  |R|----------- |  |R|------------------- |
+------------------------  ----------------  ------------------------
+
+                    |
+pages of            |
+other    --------|  |
+logical         -------
+bitstreams      | MUX |
+                -------
+                   |
+                   v
+
+              page_1  page_2          page_3
+      ------  ------  -------  -----  -------
+ ...  ||   |  ||   |  ||    |  ||  |  ||    |  ...
+      ------  ------  -------  -----  -------
+              physical Ogg bitstream
+
+   In this example we take a snapshot of the encapsulation process of
+   one logical bitstream.  We can see part of that bitstream's
+   subdivision into packets as provided by the codec.  The Ogg
+   encapsulation process chops up the packets into segments.  The
+   packets in this example are rather large such that packet_1 is split
+   into 5 segments - 4 segments with 255 bytes and a final smaller one.
+   Packet_2 is split into 4 segments - 3 segments with 255 bytes and a
+
+
+
+Pfeiffer                     Informational                      [Page 8]
+
+RFC 3533                          OGG                           May 2003
+
+
+   final very small one - and packet_3 is split into two segments.  The
+   encapsulation process then creates pages, which are quite small in
+   this example.  Page_1 consists of the first three segments of
+   packet_1, page_2 contains the remaining 2 segments from packet_1, and
+   page_3 contains the first three pages of packet_2.  Finally, this
+   logical bitstream is multiplexed into a physical Ogg bitstream with
+   pages of other logical bitstreams.
+
+6. The Ogg page format
+
+   A physical Ogg bitstream consists of a sequence of concatenated
+   pages.  Pages are of variable size, usually 4-8 kB, maximum 65307
+   bytes.  A page header contains all the information needed to
+   demultiplex the logical bitstreams out of the physical bitstream and
+   to perform basic error recovery and landmarks for seeking.  Each page
+   is a self-contained entity such that the page decode mechanism can
+   recognize, verify, and handle single pages at a time without
+   requiring the overall bitstream.
+
+   The Ogg page header has the following format:
+
+ 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| Byte
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| capture_pattern: Magic number for page start "OggS"           | 0-3
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| version       | header_type   | granule_position              | 4-7
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                                                               | 8-11
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                               | bitstream_serial_number       | 12-15
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                               | page_sequence_number          | 16-19
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                               | CRC_checksum                  | 20-23
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                               |page_segments  | segment_table | 24-27
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| ...                                                           | 28-
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The LSb (least significant bit) comes first in the Bytes.  Fields
+   with more than one byte length are encoded LSB (least significant
+   byte) first.
+
+
+
+
+
+
+
+Pfeiffer                     Informational                      [Page 9]
+
+RFC 3533                          OGG                           May 2003
+
+
+   The fields in the page header have the following meaning:
+
+   1. capture_pattern: a 4 Byte field that signifies the beginning of a
+      page.  It contains the magic numbers:
+
+            0x4f 'O'
+
+            0x67 'g'
+
+            0x67 'g'
+
+            0x53 'S'
+
+      It helps a decoder to find the page boundaries and regain
+      synchronisation after parsing a corrupted stream.  Once the
+      capture pattern is found, the decoder verifies page sync and
+      integrity by computing and comparing the checksum.
+
+   2. stream_structure_version: 1 Byte signifying the version number of
+      the Ogg file format used in this stream (this document specifies
+      version 0).
+
+   3. header_type_flag: the bits in this 1 Byte field identify the
+      specific type of this page.
+
+      *  bit 0x01
+
+         set: page contains data of a packet continued from the previous
+            page
+
+         unset: page contains a fresh packet
+
+      *  bit 0x02
+
+         set: this is the first page of a logical bitstream (bos)
+
+         unset: this page is not a first page
+
+      *  bit 0x04
+
+         set: this is the last page of a logical bitstream (eos)
+
+         unset: this page is not a last page
+
+   4. granule_position: an 8 Byte field containing position information.
+      For example, for an audio stream, it MAY contain the total number
+      of PCM samples encoded after including all frames finished on this
+      page.  For a video stream it MAY contain the total number of video
+
+
+
+Pfeiffer                     Informational                     [Page 10]
+
+RFC 3533                          OGG                           May 2003
+
+
+      frames encoded after this page.  This is a hint for the decoder
+      and gives it some timing and position information.  Its meaning is
+      dependent on the codec for that logical bitstream and specified in
+      a specific media mapping.  A special value of -1 (in two's
+      complement) indicates that no packets finish on this page.
+
+   5. bitstream_serial_number: a 4 Byte field containing the unique
+      serial number by which the logical bitstream is identified.
+
+   6. page_sequence_number: a 4 Byte field containing the sequence
+      number of the page so the decoder can identify page loss.  This
+      sequence number is increasing on each logical bitstream
+      separately.
+
+   7. CRC_checksum: a 4 Byte field containing a 32 bit CRC checksum of
+      the page (including header with zero CRC field and page content).
+      The generator polynomial is 0x04c11db7.
+
+   8. number_page_segments: 1 Byte giving the number of segment entries
+      encoded in the segment table.
+
+   9. segment_table: number_page_segments Bytes containing the lacing
+      values of all segments in this page.  Each Byte contains one
+      lacing value.
+
+   The total header size in bytes is given by:
+   header_size = number_page_segments + 27 [Byte]
+
+   The total page size in Bytes is given by:
+   page_size = header_size + sum(lacing_values: 1..number_page_segments)
+   [Byte]
+
+7. Security Considerations
+
+   The Ogg encapsulation format is a container format and only
+   encapsulates content (such as Vorbis-encoded audio).  It does not
+   provide for any generic encryption or signing of itself or its
+   contained content bitstreams.  However, it encapsulates any kind of
+   content bitstream as long as there is a codec for it, and is thus
+   able to contain encrypted and signed content data.  It is also
+   possible to add an external security mechanism that encrypts or signs
+   an Ogg physical bitstream and thus provides content confidentiality
+   and authenticity.
+
+   As Ogg encapsulates binary data, it is possible to include executable
+   content in an Ogg bitstream.  This can be an issue with applications
+   that are implemented using the Ogg format, especially when Ogg is
+   used for streaming or file transfer in a networking scenario.  As
+
+
+
+Pfeiffer                     Informational                     [Page 11]
+
+RFC 3533                          OGG                           May 2003
+
+
+   such, Ogg does not pose a threat there.  However, an application
+   decoding Ogg and its encapsulated content bitstreams has to ensure
+   correct handling of manipulated bitstreams, of buffer overflows and
+   the like.
+
+8. References
+
+   [1] Walleij, L., "The application/ogg Media Type", RFC 3534, May
+       2003.
+
+   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer                     Informational                     [Page 12]
+
+RFC 3533                          OGG                           May 2003
+
+
+Appendix A. Glossary of terms and abbreviations
+
+   bos page: The initial page (beginning of stream) of a logical
+      bitstream which contains information to identify the codec type
+      and other decoding-relevant information.
+
+   chaining (or sequential multiplexing): Concatenation of two or more
+      complete physical Ogg bitstreams.
+
+   eos page: The final page (end of stream) of a logical bitstream.
+
+   granule position: An increasing position number for a specific
+      logical bitstream stored in the page header.  Its meaning is
+      dependent on the codec for that logical bitstream and specified in
+      a specific media mapping.
+
+   grouping (or concurrent multiplexing): Interleaving of pages of
+      several logical bitstreams into one complete physical Ogg
+      bitstream under the restriction that all bos pages of all grouped
+      logical bitstreams MUST appear before any data pages.
+
+   lacing value: An entry in the segment table of a page header
+      representing the size of the related segment.
+
+   logical bitstream: A sequence of bits being the result of an encoded
+      media stream.
+
+   media mapping: A specific use of the Ogg encapsulation format
+      together with a specific (set of) codec(s).
+
+   (Ogg) packet: A subpart of a logical bitstream that is created by the
+      encoder for that bitstream and represents a meaningful entity for
+      the encoder, but only a sequence of bits to the Ogg encapsulation.
+
+   (Ogg) page: A physical bitstream consists of a sequence of Ogg pages
+      containing data of one logical bitstream only.  It usually
+      contains a group of contiguous segments of one packet only, but
+      sometimes packets are too large and need to be split over several
+      pages.
+
+   physical (Ogg) bitstream: The sequence of bits resulting from an Ogg
+      encapsulation of one or several logical bitstreams.  It consists
+      of a sequence of pages from the logical bitstreams with the
+      restriction that the pages of one logical bitstream MUST come in
+      their correct temporal order.
+
+
+
+
+
+
+Pfeiffer                     Informational                     [Page 13]
+
+RFC 3533                          OGG                           May 2003
+
+
+   (Ogg) segment: The Ogg encapsulation process splits each packet into
+      chunks of 255 bytes plus a last fractional chunk of less than 255
+      bytes.  These chunks are called segments.
+
+Appendix B. Acknowledgements
+
+   The author gratefully acknowledges the work that Christopher
+   Montgomery  and the Xiph.Org foundation have done in defining the Ogg
+   multimedia project and as part of it the open file format described
+   in this document.  The author hopes that providing this document to
+   the Internet community will help in promoting the Ogg multimedia
+   project at http://www.xiph.org/.  Many thanks also for the many
+   technical and typo corrections that C. Montgomery and the Ogg
+   community provided as feedback to this RFC.
+
+Author's Address
+
+   Silvia Pfeiffer
+   CSIRO, Australia
+   Locked Bag 17
+   North Ryde, NSW  2113
+   Australia
+
+   Phone: +61 2 9325 3141
+   EMail: Silvia.Pfeiffer@csiro.au
+   URI:   http://www.cmis.csiro.au/Silvia.Pfeiffer/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer                     Informational                     [Page 14]
+
+RFC 3533                          OGG                           May 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer                     Informational                     [Page 15]
+

rhubarb/lib/ogg-1.3.3/doc/rfc3534.txt

@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                         L. Walleij
+Request for Comments: 3534                      The Ogg Vorbis Community
+Category: Standards Track                                       May 2003
+
+
+                     The application/ogg Media Type
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   The Ogg Bitstream Format aims at becoming a general, freely-available
+   standard for transporting multimedia content across computing
+   platforms and networks.  The intention of this document is to define
+   the MIME media type application/ogg to refer to this kind of content
+   when transported across the Internet.  It is the intention of the Ogg
+   Bitstream Format developers that it be usable without intellectual
+   property concerns.
+
+Conventions used in this Document
+
+   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].
+
+1. The Ogg Bitstream Format
+
+   The Ogg Bitstream format has been developed as a part of a larger
+   project aimed at creating a set of components for the coding and
+   decoding of multimedia content (codecs) which are to be freely
+   available and freely re-implementable both in software and in
+   hardware for the computing community at large, including the Internet
+   community.
+
+   Raw packets from these codecs may be used directly by transport
+   mechanisms that provide their own framing and packet-separation
+   mechanisms (such as UDP datagrams).
+
+
+
+
+Walleij                     Standards Track                     [Page 1]
+
+RFC 3534             The application/ogg Media Type             May 2003
+
+
+   One such framing and content-separation mechanism is the real-time
+   transport protocol (RTP).  RTP allows the streaming of synchronous
+   lossy data for broadcasting and similar purposes.  If this function
+   is desired then a separate RTP wrapping mechanism should be used.  A
+   wrapping mechanism is currently under development.
+
+   For stream based storage (such as files) and transport (such as TCP
+   streams or pipes), Ogg codecs use the Ogg Bitstream Format to provide
+   framing/sync, sync recapture after error, landmarks during seeking,
+   and enough information to properly separate data back into packets at
+   the original packet boundaries without relying on decoding to find
+   packet boundaries.  The application/ogg MIME type refers to this kind
+   of bitstreams, when no further knowledge of the bitstream content
+   exists.
+
+   The bitstream format in itself is documented in [1].
+
+2. Registration Information
+
+   To: ietf-types@iana.org
+
+   Subject: Registration of MIME media type application/ogg
+
+   MIME media type name: application
+
+   MIME subtype name: ogg
+
+   Required parameters: none
+
+   Optional parameters: none
+
+   Encoding Considerations:
+
+   The Ogg bitstream format is binary data, and must be encoded for
+   non-binary transport; the Base64 encoding is suitable for Email.
+   Binary encoding could also be used.
+
+   Security Considerations:
+
+   As the Ogg bitstream file is a container format and only a carrier of
+   content (such as Vorbis audio) with a very rigid definition (see
+   [1]), this format in itself is not more vulnerable than any other
+   content framing mechanism.  The main security consideration for the
+   receiving application is to ensure that manipulated packages can not
+   cause buffer overflows and the like.  It is possible to encapsulate
+   even executable content in the bitstream, so for such uses additional
+   security considerations must be taken.
+
+
+
+
+Walleij                     Standards Track                     [Page 2]
+
+RFC 3534             The application/ogg Media Type             May 2003
+
+
+   Ogg bitstream files are not signed or encrypted using any applicable
+   encryption schemes.  External security mechanisms must be added if
+   content confidentiality and authenticity is to be achieved.
+
+   Interoperability considerations:
+
+   The Ogg bitstream format has proved to be widely implementable across
+   different computing platforms.  A broadly portable reference
+   implementation is available under a BSD license.
+
+   The Ogg bitstream format is not patented and can be implemented by
+   third parties without patent considerations.
+
+   Published specification:
+
+   See [1].
+
+   Applications which use this media type:
+
+   Any application that implements the specification will be able to
+   encode or decode Ogg bitstream files.  Specifically, the format is
+   supposed to be used by subcodecs that implement, for example, Vorbis
+   audio.
+
+   Additional information:
+
+   Magic number(s):
+
+   In Ogg bitstream files, the first four bytes are 0x4f 0x67 0x67 0x53
+   corresponding to the string "OggS".
+
+   File extension: .ogg
+
+   Macintosh File Type Code(s): OggS
+
+   Object Identifier(s) or OID(s): none
+
+   Person & email address to contact for further information:
+
+   Questions about this proposal should be directed to Linus Walleij
+   <triad@df.lth.se>.  Technical questions about the Ogg bitstream
+   standard may be asked on the mailing lists for the developer
+   community.  <http://www.xiph.org/archives/>
+
+   Intended usage: COMMON
+
+
+
+
+
+
+Walleij                     Standards Track                     [Page 3]
+
+RFC 3534             The application/ogg Media Type             May 2003
+
+
+   Author/Change controller:
+
+   This document was written by Linus Walleij <triad@df.lth.se>.
+   Changes to this document will either be handled by him, a
+   representative of the Xiph.org, or the associated development
+   communities.
+
+   The Ogg bitstream format is controlled by the Xiph.org and the
+   respective development communities.
+
+3. Security Considerations
+
+   Security considerations are discussed in the security considerations
+   clause of the MIME registration in section 2.
+
+4.  Normative References
+
+   [1]  Pfeiffer, S., "The Ogg encapsulation format version 0", RFC
+        3533, May 2003.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+5.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property 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; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication 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 implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+Walleij                     Standards Track                     [Page 4]
+
+RFC 3534             The application/ogg Media Type             May 2003
+
+
+6.  Author's Address
+
+   Linus Walleij
+   The Ogg Vorbis Community
+   Master Olofs Vag 24
+   Lund  224 66
+   SE
+
+   Phone: +46 703 193678
+   EMail: triad@df.lth.se
+   URI:   http://www.xiph.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Walleij                     Standards Track                     [Page 5]
+
+RFC 3534             The application/ogg Media Type             May 2003
+
+
+7.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Walleij                     Standards Track                     [Page 6]
+

rhubarb/lib/ogg-1.3.3/doc/rfc5334.txt

@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                       I. Goncalves
+Request for Comments: 5334                                   S. Pfeiffer
+Obsoletes: 3534                                            C. Montgomery
+Category: Standards Track                                           Xiph
+                                                          September 2008
+
+
+                            Ogg Media Types
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes the registration of media types for the Ogg
+   container format and conformance requirements for implementations of
+   these types.  This document obsoletes RFC 3534.
+
+Table of Contents
+
+   1.     Introduction  . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.     Changes Since RFC 3534  . . . . . . . . . . . . . . . . . .  2
+   3.     Conformance and Document Conventions  . . . . . . . . . . .  3
+   4.     Deployed Media Types and Compatibility  . . . . . . . . . .  3
+   5.     Relation between the Media Types  . . . . . . . . . . . . .  5
+   6.     Encoding Considerations . . . . . . . . . . . . . . . . . .  5
+   7.     Security Considerations . . . . . . . . . . . . . . . . . .  6
+   8.     Interoperability Considerations . . . . . . . . . . . . . .  7
+   9.     IANA Considerations . . . . . . . . . . . . . . . . . . . .  7
+   10.    Ogg Media Types . . . . . . . . . . . . . . . . . . . . . .  7
+   10.1.  application/ogg . . . . . . . . . . . . . . . . . . . . . .  7
+   10.2.  video/ogg . . . . . . . . . . . . . . . . . . . . . . . . .  8
+   10.3.  audio/ogg . . . . . . . . . . . . . . . . . . . . . . . . .  9
+   11.    Acknowledgements  . . . . . . . . . . . . . . . . . . . . . 10
+   12.    Copying Conditions  . . . . . . . . . . . . . . . . . . . . 10
+   13.    References  . . . . . . . . . . . . . . . . . . . . . . . . 11
+   13.1.  Normative References  . . . . . . . . . . . . . . . . . . . 11
+   13.2.  Informative References  . . . . . . . . . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+Goncalves, et al.           Standards Track                     [Page 1]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+1.  Introduction
+
+   This document describes media types for Ogg, a data encapsulation
+   format defined by the Xiph.Org Foundation for public use.  Refer to
+   "Introduction" in [RFC3533] and "Overview" in [Ogg] for background
+   information on this container format.
+
+   Binary data contained in Ogg, such as Vorbis and Theora, has
+   historically been interchanged using the application/ogg media type
+   as defined by [RFC3534].  This document obsoletes [RFC3534] and
+   defines three media types for different types of content in Ogg to
+   reflect this usage in the IANA media type registry, to foster
+   interoperability by defining underspecified aspects, and to provide
+   general security considerations.
+
+   The Ogg container format is known to contain [Theora] or [Dirac]
+   video, [Speex] (narrow-band and wide-band) speech, [Vorbis] or [FLAC]
+   audio, and [CMML] timed text/metadata.  As Ogg encapsulates binary
+   data, it is possible to include any other type of video, audio,
+   image, text, or, generally speaking, any time-continuously sampled
+   data.
+
+   While raw packets from these data sources may be used directly by
+   transport mechanisms that provide their own framing and packet-
+   separation mechanisms (such as UDP datagrams or RTP), Ogg is a
+   solution for stream based storage (such as files) and transport (such
+   as TCP streams or pipes).  The media types defined in this document
+   are needed to correctly identify such content when it is served over
+   HTTP, included in multi-part documents, or used in other places where
+   media types [RFC2045] are used.
+
+2.  Changes Since RFC 3534
+
+   o  The type "application/ogg" is redefined.
+
+   o  The types "video/ogg" and "audio/ogg" are defined.
+
+   o  New file extensions are defined.
+
+   o  New Macintosh file type codes are defined.
+
+   o  The codecs parameter is defined for optional use.
+
+   o  The Ogg Skeleton extension becomes a recommended addition for
+      content served under the new types.
+
+
+
+
+
+
+Goncalves, et al.           Standards Track                     [Page 2]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+3.  Conformance and Document Conventions
+
+   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 BCP 14, [RFC2119] and
+   indicate requirement levels for compliant implementations.
+   Requirements apply to all implementations unless otherwise stated.
+
+   An implementation is a software module that supports one of the media
+   types defined in this document.  Software modules may support
+   multiple media types, but conformance is considered individually for
+   each type.
+
+   Implementations that fail to satisfy one or more "MUST" requirements
+   are considered non-compliant.  Implementations that satisfy all
+   "MUST" requirements, but fail to satisfy one or more "SHOULD"
+   requirements, are said to be "conditionally compliant".  All other
+   implementations are "unconditionally compliant".
+
+4.  Deployed Media Types and Compatibility
+
+   The application/ogg media type has been used in an ad hoc fashion to
+   label and exchange multimedia content in Ogg containers.
+
+   Use of the "application" top-level type for this kind of content is
+   known to be problematic, in particular since it obfuscates video and
+   audio content.  This document thus defines the media types,
+
+   o  video/ogg
+
+   o  audio/ogg
+
+   which are intended for common use and SHOULD be used when dealing
+   with video or audio content, respectively.  This document also
+   obsoletes the [RFC3534] definition of application/ogg and marks it
+   for complex data (e.g., multitrack visual, audio, textual, and other
+   time-continuously sampled data), which is not clearly video or audio
+   data and thus not suited for either the video/ogg or audio/ogg types.
+   Refer to the following section for more details.
+
+   An Ogg bitstream generally consists of one or more logical bitstreams
+   that each consist of a series of header and data pages packetising
+   time-continuous binary data [RFC3533].  The content types of the
+   logical bitstreams may be identified without decoding the header
+   pages of the logical bitstreams through use of a [Skeleton]
+   bitstream.  Using Ogg Skeleton is REQUIRED for content served under
+
+
+
+
+
+Goncalves, et al.           Standards Track                     [Page 3]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+   the application/ogg type and RECOMMENDED for video/ogg and audio/ogg,
+   as Skeleton contains identifiers to describe the different
+   encapsulated data.
+
+   Furthermore, it is RECOMMENDED that implementations that identify a
+   logical bitstream that they cannot decode SHOULD ignore it, while
+   continuing to decode the ones they can.  Such precaution ensures
+   backward and forward compatibility with existing and future data.
+
+   These media types can optionally use the "codecs" parameter described
+   in [RFC4281].  Codecs encapsulated in Ogg require a text identifier
+   at the beginning of the first header page, hence a machine-readable
+   method to identify the encapsulated codecs would be through this
+   header.  The following table illustrates how those header values map
+   into strings that are used in the "codecs" parameter when dealing
+   with Ogg media types.
+
+        Codec Identifier             | Codecs Parameter
+       -----------------------------------------------------------
+        char[5]: 'BBCD\0'            | dirac
+        char[5]: '\177FLAC'          | flac
+        char[7]: '\x80theora'        | theora
+        char[7]: '\x01vorbis'        | vorbis
+        char[8]: 'CELT    '          | celt
+        char[8]: 'CMML\0\0\0\0'      | cmml
+        char[8]: '\213JNG\r\n\032\n' | jng
+        char[8]: '\x80kate\0\0\0'    | kate
+        char[8]: 'OggMIDI\0'         | midi
+        char[8]: '\212MNG\r\n\032\n' | mng
+        char[8]: 'PCM     '          | pcm
+        char[8]: '\211PNG\r\n\032\n' | png
+        char[8]: 'Speex   '          | speex
+        char[8]: 'YUV4MPEG'          | yuv4mpeg
+
+   An up-to-date version of this table is kept at Xiph.org (see
+   [Codecs]).
+
+   Possible examples include:
+
+   o  application/ogg; codecs="theora, cmml, ecmascript"
+
+   o  video/ogg; codecs="theora, vorbis"
+
+   o  audio/ogg; codecs=speex
+
+
+
+
+
+
+
+Goncalves, et al.           Standards Track                     [Page 4]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+5.  Relation between the Media Types
+
+   As stated in the previous section, this document describes three
+   media types that are targeted at different data encapsulated in Ogg.
+   Since Ogg is capable of encapsulating any kind of data, the multiple
+   usage scenarios have revealed interoperability issues between
+   implementations when dealing with content served solely under the
+   application/ogg type.
+
+   While this document does redefine the earlier definition of
+   application/ogg, this media type will continue to embrace the widest
+   net possible of content with the video/ogg and audio/ogg types being
+   smaller subsets of it.  However, the video/ogg and audio/ogg types
+   take precedence in a subset of the usages, specifically when serving
+   multimedia content that is not complex enough to warrant the use of
+   application/ogg.  Following this line of thought, the audio/ogg type
+   is an even smaller subset within video/ogg, as it is not intended to
+   refer to visual content.
+
+   As such, the application/ogg type is the recommended choice to serve
+   content aimed at scientific and other applications that require
+   various multiplexed signals or streams of continuous data, with or
+   without scriptable control of content.  For bitstreams containing
+   visual, timed text, and any other type of material that requires a
+   visual interface, but that is not complex enough to warrant serving
+   under application/ogg, the video/ogg type is recommended.  In
+   situations where the Ogg bitstream predominantly contains audio data
+   (lyrics, metadata, or cover art notwithstanding), it is recommended
+   to use the audio/ogg type.
+
+6.  Encoding Considerations
+
+   Binary: The content consists of an unrestricted sequence of octets.
+
+   Note:
+
+   o  Ogg encapsulated content is binary data and should be transmitted
+      in a suitable encoding without CR/LF conversion, 7-bit stripping,
+      etc.; base64 [RFC4648] is generally preferred for binary-to-text
+      encoding.
+
+   o  Media types described in this document are used for stream based
+      storage (such as files) and transport (such as TCP streams or
+      pipes); separate types are used to identify codecs such as in
+      real-time applications for the RTP payload formats of Theora
+      [ThRTP] video, Vorbis [RFC5215], or Speex [SpRTP] audio, as well
+      as for identification of encapsulated data within Ogg through
+      Skeleton.
+
+
+
+Goncalves, et al.           Standards Track                     [Page 5]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+7.  Security Considerations
+
+   Refer to [RFC3552] for a discussion of terminology used in this
+   section.
+
+   The Ogg encapsulation format is a container and only a carrier of
+   content (such as audio, video, and displayable text data) with a very
+   rigid definition.  This format in itself is not more vulnerable than
+   any other content framing mechanism.
+
+   Ogg does not provide for any generic encryption or signing of itself
+   or its contained bitstreams.  However, it encapsulates any kind of
+   binary content and is thus able to contain encrypted and signed
+   content data.  It is also possible to add an external security
+   mechanism that encrypts or signs an Ogg bitstream and thus provides
+   content confidentiality and authenticity.
+
+   As Ogg encapsulates binary data, it is possible to include executable
+   content in an Ogg bitstream.  Implementations SHOULD NOT execute such
+   content without prior validation of its origin by the end-user.
+
+   Issues may arise on applications that use Ogg for streaming or file
+   transfer in a networking scenario.  In such cases, implementations
+   decoding Ogg and its encapsulated bitstreams have to ensure correct
+   handling of manipulated bitstreams, of buffer overflows, and similar
+   issues.
+
+   It is also possible to author malicious Ogg bitstreams, which attempt
+   to call for an excessively large picture size, high sampling-rate
+   audio, etc.  Implementations SHOULD protect themselves against this
+   kind of attack.
+
+   Ogg has an extensible structure, so that it is theoretically possible
+   that metadata fields or media formats might be defined in the future
+   which might be used to induce particular actions on the part of the
+   recipient, thus presenting additional security risks.  However, this
+   type of capability is currently not supported in the referenced
+   specification.
+
+   Implementations may fail to implement a specific security model or
+   other means to prevent possibly dangerous operations.  Such failure
+   might possibly be exploited to gain unauthorized access to a system
+   or sensitive information; such failure constitutes an unknown factor
+   and is thus considered out of the scope of this document.
+
+
+
+
+
+
+
+Goncalves, et al.           Standards Track                     [Page 6]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+8.  Interoperability Considerations
+
+   The Ogg container format is device-, platform-, and vendor-neutral
+   and has proved to be widely implementable across different computing
+   platforms through a wide range of encoders and decoders.  A broadly
+   portable reference implementation [libogg] is available under the
+   revised (3-clause) BSD license, which is a Free Software license.
+
+   The Xiph.Org Foundation has defined the specification,
+   interoperability, and conformance and conducts regular
+   interoperability testing.
+
+   The use of the Ogg Skeleton extension has been confirmed to not cause
+   interoperability issues with existing implementations.  Third parties
+   are, however, welcome to conduct their own testing.
+
+9.  IANA Considerations
+
+   In accordance with the procedures set forth in [RFC4288], this
+   document registers two new media types and redefines the existing
+   application/ogg as defined in the following section.
+
+10.  Ogg Media Types
+
+10.1.  application/ogg
+
+   Type name: application
+
+   Subtype name: ogg
+
+   Required parameters: none
+
+   Optional parameters: codecs, whose syntax is defined in RFC 4281.
+   See section 4 of RFC 5334 for a list of allowed values.
+
+   Encoding considerations: See section 6 of RFC 5334.
+
+   Security considerations: See section 7 of RFC 5334.
+
+   Interoperability considerations: None, as noted in section 8 of RFC
+   5334.
+
+   Published specification: RFC 3533
+
+   Applications which use this media type: Scientific and otherwise that
+   require various multiplexed signals or streams of data, with or
+   without scriptable control of content.
+
+
+
+
+Goncalves, et al.           Standards Track                     [Page 7]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+   Additional information:
+
+   Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
+   correspond to the string "OggS".
+
+   File extension(s): .ogx
+
+      RFC 3534 defined the file extension .ogg for application/ogg,
+      which RFC 5334 obsoletes in favor of .ogx due to concerns where,
+      historically, some implementations expect .ogg files to be solely
+      Vorbis-encoded audio.
+
+   Macintosh File Type Code(s): OggX
+
+   Person & Email address to contact for further information: See
+   "Authors' Addresses" section.
+
+   Intended usage: COMMON
+
+   Restrictions on usage: The type application/ogg SHOULD only be used
+   in situations where it is not appropriate to serve data under the
+   video/ogg or audio/ogg types.  Data served under the application/ogg
+   type SHOULD use the .ogx file extension and MUST contain an Ogg
+   Skeleton logical bitstream to identify all other contained logical
+   bitstreams.
+
+   Author: See "Authors' Addresses" section.
+
+   Change controller: The Xiph.Org Foundation.
+
+10.2.  video/ogg
+
+   Type name: video
+
+   Subtype name: ogg
+
+   Required parameters: none
+
+   Optional parameters: codecs, whose syntax is defined in RFC 4281.
+   See section 4 of RFC 5334 for a list of allowed values.
+
+   Encoding considerations: See section 6 of RFC 5334.
+
+   Security considerations: See section 7 of RFC 5334.
+
+   Interoperability considerations: None, as noted in section 8 of RFC
+   5334.
+
+
+
+
+Goncalves, et al.           Standards Track                     [Page 8]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+   Published specification: RFC 3533
+
+   Applications which use this media type: Multimedia applications,
+   including embedded, streaming, and conferencing tools.
+
+   Additional information:
+
+   Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
+   correspond to the string "OggS".
+
+   File extension(s): .ogv
+
+   Macintosh File Type Code(s): OggV
+
+   Person & Email address to contact for further information: See
+   "Authors' Addresses" section.
+
+   Intended usage: COMMON
+
+   Restrictions on usage: The type "video/ogg" SHOULD be used for Ogg
+   bitstreams containing visual, audio, timed text, or any other type of
+   material that requires a visual interface.  It is intended for
+   content not complex enough to warrant serving under "application/
+   ogg"; for example, a combination of Theora video, Vorbis audio,
+   Skeleton metadata, and CMML captioning.  Data served under the type
+   "video/ogg" SHOULD contain an Ogg Skeleton logical bitstream.
+   Implementations interacting with the type "video/ogg" SHOULD support
+   multiplexed bitstreams.
+
+   Author: See "Authors' Addresses" section.
+
+   Change controller: The Xiph.Org Foundation.
+
+10.3.  audio/ogg
+
+   Type name: audio
+
+   Subtype name: ogg
+
+   Required parameters: none
+
+   Optional parameters: codecs, whose syntax is defined in RFC 4281.
+   See section 4 of RFC 5334 for a list of allowed values.
+
+   Encoding considerations: See section 6 of RFC 5334.
+
+   Security considerations: See section 7 of RFC 5334.
+
+
+
+
+Goncalves, et al.           Standards Track                     [Page 9]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+   Interoperability considerations: None, as noted in section 8 of RFC
+   5334.
+
+   Published specification: RFC 3533
+
+   Applications which use this media type: Multimedia applications,
+   including embedded, streaming, and conferencing tools.
+
+   Additional information:
+
+   Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
+   correspond to the string "OggS".
+
+   File extension(s): .oga, .ogg, .spx
+
+   Macintosh File Type Code(s): OggA
+
+   Person & Email address to contact for further information: See
+   "Authors' Addresses" section.
+
+   Intended usage: COMMON
+
+   Restrictions on usage: The type "audio/ogg" SHOULD be used when the
+   Ogg bitstream predominantly contains audio data.  Content served
+   under the "audio/ogg" type SHOULD have an Ogg Skeleton logical
+   bitstream when using the default .oga file extension.  The .ogg and
+   .spx file extensions indicate a specialization that requires no
+   Skeleton due to backward compatibility concerns with existing
+   implementations.  In particular, .ogg is used for Ogg files that
+   contain only a Vorbis bitstream, while .spx is used for Ogg files
+   that contain only a Speex bitstream.
+
+   Author: See "Authors' Addresses" section.
+
+   Change controller: The Xiph.Org Foundation.
+
+11.  Acknowledgements
+
+   The authors gratefully acknowledge the contributions of Magnus
+   Westerlund, Alfred Hoenes, and Peter Saint-Andre.
+
+12.  Copying Conditions
+
+   The authors agree to grant third parties the irrevocable right to
+   copy, use and distribute the work, with or without modification, in
+   any medium, without royalty, provided that, unless separate
+   permission is granted, redistributed modified works do not contain
+   misleading author, version, name of work, or endorsement information.
+
+
+
+Goncalves, et al.           Standards Track                    [Page 10]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+13.  References
+
+13.1.  Normative References
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3533]   Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
+               RFC 3533, May 2003.
+
+   [RFC4281]   Gellens, R., Singer, D., and P. Frojdh, "The Codecs
+               Parameter for "Bucket" Media Types", RFC 4281,
+               November 2005.
+
+   [RFC4288]   Freed, N. and J. Klensin, "Media Type Specifications and
+               Registration Procedures", BCP 13, RFC 4288,
+               December 2005.
+
+13.2.  Informative References
+
+   [CMML]      Pfeiffer, S., Parker, C., and A. Pang, "The Continuous
+               Media Markup Language (CMML)", Work in Progress,
+               March 2006.
+
+   [Codecs]    Pfeiffer, S. and I. Goncalves, "Specification of MIME
+               types and respective codecs parameter", July 2008,
+               <http://wiki.xiph.org/index.php/MIMETypesCodecs>.
+
+   [Dirac]     Dirac Group, "Dirac Specification",
+               <http://diracvideo.org/specifications/>.
+
+   [FLAC]      Coalson, J., "The FLAC Format",
+               <http://flac.sourceforge.net/format.html>.
+
+   [libogg]    Xiph.Org Foundation, "The libogg API", June 2000,
+               <http://xiph.org/ogg/doc/libogg>.
+
+   [Ogg]       Xiph.Org Foundation, "Ogg bitstream documentation: Ogg
+               logical and physical bitstream overview, Ogg logical
+               bitstream framing, Ogg multi-stream multiplexing",
+               <http://xiph.org/ogg/doc>.
+
+   [RFC3534]   Walleij, L., "The application/ogg Media Type", RFC 3534,
+               May 2003.
+
+
+
+Goncalves, et al.           Standards Track                    [Page 11]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+   [RFC3552]   Rescorla, E. and B. Korver, "Guidelines for Writing RFC
+               Text on Security Considerations", BCP 72, RFC 3552,
+               July 2003.
+
+   [RFC4648]   Josefsson, S., "The Base16, Base32, and Base64 Data
+               Encodings", RFC 4648, October 2006.
+
+   [RFC5215]   Barbato, L., "RTP Payload Format for Vorbis Encoded
+               Audio", RFC 5215, August 2008.
+
+   [Skeleton]  Pfeiffer, S. and C. Parker, "The Ogg Skeleton Metadata
+               Bitstream", November 2007,
+               <http://xiph.org/ogg/doc/skeleton.html>.
+
+   [Speex]     Valin, J., "The Speex Codec Manual", February 2002,
+               <http://speex.org/docs/manual/speex-manual>.
+
+   [SpRTP]     Herlein, G., Valin, J., Heggestad, A., and A. Moizard,
+               "RTP Payload Format for the Speex Codec", Work
+               in Progress, February 2008.
+
+   [Theora]    Xiph.Org Foundation, "Theora Specification",
+               October 2007, <http://theora.org/doc/Theora.pdf>.
+
+   [ThRTP]     Barbato, L., "RTP Payload Format for Theora Encoded
+               Video", Work in Progress, June 2006.
+
+   [Vorbis]    Xiph.Org Foundation, "Vorbis I Specification", July 2004,
+               <http://xiph.org/vorbis/doc/Vorbis_I_spec.html>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goncalves, et al.           Standards Track                    [Page 12]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+Authors' Addresses
+
+   Ivo Emanuel Goncalves
+   Xiph.Org Foundation
+   21 College Hill Road
+   Somerville, MA  02144
+   US
+
+   EMail: justivo@gmail.com
+   URI:   xmpp:justivo@gmail.com
+
+
+   Silvia Pfeiffer
+   Xiph.Org Foundation
+
+   EMail: silvia@annodex.net
+   URI:   http://annodex.net/
+
+
+   Christopher Montgomery
+   Xiph.Org Foundation
+
+   EMail: monty@xiph.org
+   URI:   http://xiph.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goncalves, et al.           Standards Track                    [Page 13]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   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.
+
+   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, THE IETF TRUST 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.
+
+Intellectual Property
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Goncalves, et al.           Standards Track                    [Page 14]
+

rhubarb/lib/ogg-1.3.3/doc/skeleton.html

@@ -0,0 +1,222 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html dir="ltr" lang="en">
+<head>
+
+<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+<title>The Ogg Skeleton Metadata Bitstream</title>
+
+<style type="text/css">
+body {
+  margin: 0 18px 0 18px;
+  padding-bottom: 30px;
+  font-family: Verdana, "DejaVu Sans", sans-serif;
+  color: #333333;
+  font-size: .8em;
+}
+
+a {
+  color: #3366cc;
+}
+
+img {
+  border: 0;
+}
+
+#xiphlogo {
+  margin: 30px 0 16px 0;
+}
+
+#content p {
+  line-height: 1.4;
+}
+
+h1, h1 a, h2, h2 a, h3, h3 a {
+  font-weight: bold;
+  color: #ff9900;
+  margin: 1.3em 0 8px 0;
+}
+
+h1 {
+  font-size: 1.3em;
+}
+
+h2 {
+  font-size: 1.2em;
+}
+
+h3 {
+  font-size: 1.1em;
+}
+
+li {
+  line-height: 1.4;
+}
+
+#copyright {
+  margin-top: 30px;
+  line-height: 1.5em;
+  text-align: center;
+  font-size: .8em;
+  color: #888888;
+  clear: both;
+}
+</style>
+
+</head>
+
+<body>
+
+<div id="xiphlogo">
+  <a href="http://xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.org"></a>
+</div>
+
+<h1>The Ogg Skeleton Metadata Bitstream</h1>
+
+<h2>Overview</h2>
+
+<p><strong>Ogg Skeleton</strong> provides structuring information for multitrack <a href="//xiph.org/ogg">Ogg</a> files. It is compatible with Ogg <a rel="external" href="//theora.org">Theora</a> and provides extra clues for synchronization and content negotiation such as language selection.</p>
+
+<p>Ogg is a generic container format for time-continuous data streams, enabling interleaving of several tracks of frame-wise encoded content in a time-multiplexed manner. As an example, an Ogg physical bitstream could encapsulate several tracks of video encoded in Theora and multiple tracks of audio encoded in Speex or Vorbis or FLAC at the same time. A player that decodes such a bitstream could then, for example, play one video channel as the main video playback, alpha-blend another one on top of it (e.g. a caption track), play a main Vorbis audio together with several FLAC audio tracks simultaneously (e.g. as sound effects), and provide a choice of Speex channels (e.g. providing commentary in different languages). Such a file is generally possible to create with Ogg, it is however not possible to generically parse such a file, seek on it, understand what codecs are contained in such a file, and dynamically handle and play back such content.</p>
+
+<p>Ogg does not know anything about the content it carries and leaves it to the media mapping of each codec to declare and describe itself. There is no meta information available at the Ogg level about the content tracks encapsulated within an Ogg physical bitstream. This is particularly a problem if you don't have all the decoder libraries available and just want to parse an Ogg file to find out what type of data it encapsulates (such as the "file" command under *nix to determine what file it is through magic numbers), or want to seek to a temporal offset without having to decode the data (such as on a Web server that just serves out Ogg files and parts thereof).</p>
+
+<p>Ogg Skeleton is being designed to overcome these problems. Ogg Skeleton is a logical bitstream within an Ogg stream that contains information about the other encapsulated logical bitstreams. For each logical bitstream it provides information such as its media type, and explains the way the granulepos field in Ogg pages is mapped to time.</p>
+
+<p>Ogg Skeleton is also designed to allow the creation of substreams from Ogg physical bitstreams that retain the original timing information. For example, when cutting out the segment between the 7th and the 59th second of an Ogg file, it would be nice to continue to start this cut out file with a playback time of 7 seconds and not of 0. This is of particular interest if you're streaming this file from a Web server after a query for a temporal subpart such as in http://example.com/video.ogv?t=7-59</p>
+
+<h2>Specification</h2>
+
+<h3>How to describe the logical bitstreams within an Ogg container?</h3>
+
+<p>The following information about a logical bitstream is of interest to contain as meta information in the Skeleton:</p>
+<ul>
+<li>the serial number: it identifies a content track</li>
+<li>the mime type: it identifies the content type</li>
+<li>other generic name-value fields that can provide meta information such as the language of a track or the video height and width</li>
+<li>the number of header packets: this informs a parser about the number of actual header packets in an Ogg logical bitstream</li>
+<li>the granule rate: the granule rate represents the data rate in Hz at which content is sampled for the particular logical bitstream, allowing to map a granule position to time by calculating "granulepos / granulerate"</li>
+<li>the preroll: the number of past content packets to take into account when decoding the current Ogg page, which is necessary for seeking (vorbis has generally 2, speex 3)</li>
+<li>the granuleshift: the number of lower bits from the granulepos field that are used to provide position information for sub-seekable units (like the keyframe shift in theora)</li>
+<li>a basetime: it provides a mapping for granule position 0 (for all logical bitstreams) to a playback time; an example use: most content in professional analog video creation actually starts at a time of 1 hour and thus adding this additional field allows them retain this mapping on digitizing their content</li>
+<li>a UTC time: it provides a mapping for granule position 0 (for all logical bitstreams) to a real-world clock time allowing to remember e.g. the recording or broadcast time of some content</li>
+</ul>
+
+<h3>How to allow the creation of substreams from an Ogg physical bitstream?</h3>
+
+<p>When cutting out a subpart of an Ogg physical bitstream, the aim is to keep all the content pages intact (including the framing and granule positions) and just change some information in the Skeleton that allows reconstruction of the accurate time mapping. When remultiplexing such a bitstream, it is necessary to take into account all the different contained logical bitstreams. A given cut-in time maps to several different byte positions in the Ogg physical bitstream because each logical bitstream has its relevant information for that time at a different location. In addition, the resolution of each logical bitstream may not be high enough to accommodate for the given cut-in time and thus there may be some surplus information necessary to be remuxed into the new bitstream.</p>
+
+<p>The following information is necessary to be added to the Skeleton to allow a correct presentation of a subpart of an Ogg bitstream:</p>
+<ul>
+<li>the presentation time: this is the actual cut-in time and all logical bitstreams are meant to start presenting from this time onwards, not from the time their data starts, which may be some time before that (because this time may have mapped right into the middle of a packet, or because the logical bitstream has a preroll or a keyframe shift)</li>
+<li>the basegranule: this represents the granule number with which this logical bitstream starts in the remuxed stream and provides for each logical bitstream the accurate start time of its data stream; this information is necessary to allow correct decoding and timing of the first data packets contained in a logcial bitstream of a remuxed Ogg stream</li>
+</ul>
+
+<h3>Ogg Skeleton version 3.0 Format Specification</h3>
+
+<p>Adding the above information into an Ogg bitstream without breaking existing Ogg functionality and code requires the use of a logical bitstream for Ogg Skeleton. This logical bitstream may be ignored on decoding such that existing players can still continue to play back Ogg files that have a Skeleton bitstream. Skeleton enriches the Ogg bitstream to provide meta information about structure and content of the Ogg bitstream.</p>
+
+<p>The Skeleton logical bitstream starts with an ident header that contains information about all of the logical bitstreams and is mapped into the Skeleton bos page.  The first 8 bytes provide the magic identifier "fishead\0".
+After the fishead follows a set of secondary header packets, each of which contains information about one logical bitstream. These secondary header packets are identified by an 8 byte code of "fisbone\0". The Skeleton logical bitstream has no actual content packets. Its eos page is included into the stream before any data pages of the other logical bitstreams appear and contains a packet of length 0.</p>
+
+<p>The fishead ident header looks as follows:</p>
+<pre>
+
+  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| Byte
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier 'fishead\0'                                        | 0-3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 4-7
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Version major                 | Version minor                 | 8-11
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Presentationtime numerator                                    | 12-15
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 16-19
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Presentationtime denominator                                  | 20-23
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 24-27
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Basetime numerator                                            | 28-31
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 32-35
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Basetime denominator                                          | 36-39
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 40-43
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | UTC                                                           | 44-47
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 48-51
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 52-55
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 56-59
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 60-63
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+</pre>
+<p>The version fields provide version information for the Skeleton track, currently being 3.0 (the number having evolved within the Annodex project).</p>
+
+<p>Presentation time and basetime are specified as a rational number, the denominator providing the temporal resolution at which the time is given (e.g. to specify time in milliseconds, provide a denominator of 1000).</p>
+
+<p>The fisbone secondary header packet looks as follows:</p>
+<pre>
+
+  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| Byte
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier 'fisbone\0'                                        | 0-3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 4-7
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Offset to message header fields                               | 8-11
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Serial number                                                 | 12-15
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Number of header packets                                      | 16-19
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Granulerate numerator                                         | 20-23
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 24-27
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Granulerate denominator                                       | 28-31
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 32-35
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Basegranule                                                   | 36-39
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |                                                               | 40-43
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Preroll                                                       | 44-47
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Granuleshift  | Padding/future use                            | 48-51
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Message header fields ...                                     | 52-
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+</pre>
+<p>The mime type is provided as a message header field specified in the same way that HTTP header fields are given (e.g. "Content-Type: audio/vorbis"). Further meta information (such as language and screen size) are also included as message header fields. The offset to the message header fields at the beginning of a fisbone packet is included for forward compatibility - to allow further fields to be included into the packet without disrupting the message header field parsing.</p>
+
+<p>The granule rate is again given as a rational number in the same way that presentation time and basetime were provided above.</p>
+
+<p>A further restriction on how to encapsulate Skeleton into Ogg is proposed to allow for easier parsing:</p>
+<ul>
+<li>there can only be one Skeleton logical bitstream in a Ogg bitstream</li>
+<li>the Skeleton bos page is the very first bos page in the Ogg stream such that it can be identified straight away and decoders don't get confused about it being e.g. Ogg Vorbis without this meta information</li>
+<li>the bos pages of all the other logical bistreams come next (a requirement of Ogg)</li>
+<li>the secondary header pages of all logical bitstreams come next, including Skeleton's secondary header packets</li>
+<li>the Skeleton eos page end the control section of the Ogg stream before any content pages of any of the other logical bitstreams appear</li>
+</ul>
+
+<div id="copyright">
+  The Xiph Fish Logo is a
+  trademark (&trade;) of the Xiph.Org Foundation.<br>
+
+  These pages &copy; 1994 - 2008 Xiph.Org Foundation. Some rights reserved.
+</div>
+
+</body>
+</html>