Merge pull request #44 from DanielSWolf/feature/#40-ogg-vorbis

Support for Ogg Vorbis file format
This commit is contained in:
Daniel Wolf 2018-09-01 10:34:54 +02:00 committed by GitHub
commit 8648ed5640
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
547 changed files with 130049 additions and 32 deletions

View File

@ -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. > 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 ### `[pocketsphinx]` PocketSphinx
The [PocketSphinx](https://github.com/cmusphinx/pocketsphinx) library is released under a variation of the **2-clause BSD License**. The [PocketSphinx](https://github.com/cmusphinx/pocketsphinx) library is released under a variation of the **2-clause BSD License**.
@ -216,6 +232,22 @@ The [utf8proc](https://github.com/JuliaLang/utf8proc) library is released under
> >
> Unicode and the Unicode logo are trademarks of Unicode, Inc., and may be registered in some jurisdictions. All other trademarks and registered trademarks mentioned herein are the property of their respective owners. > Unicode and the Unicode logo are trademarks of Unicode, Inc., and may be registered in some jurisdictions. All other trademarks and registered trademarks mentioned herein are the property of their respective owners.
### `[vorbis]` libvorbis
libvorbis is released under the **3-clause BSD license**.
> Copyright (c) 2002-2018 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.
### `[webrtc]` WebRTC ### `[webrtc]` WebRTC
The [WebRTC](https://chromium.googlesource.com/external/webrtc) library is released under the **3-clause BSD License**. The [WebRTC](https://chromium.googlesource.com/external/webrtc) library is released under the **3-clause BSD License**.

View File

@ -1,5 +1,9 @@
# Version history # Version history
## Unreleased
* Support for Ogg Vorbis (.ogg) files
## Version 1.7.2 ## Version 1.7.2
* Fixed bug in Rhubarb for Spine where processing failed depending on the number of existing animations. See [issue #34](https://github.com/DanielSWolf/rhubarb-lip-sync/issues/34#issuecomment-378198776). * Fixed bug in Rhubarb for Spine where processing failed depending on the number of existing animations. See [issue #34](https://github.com/DanielSWolf/rhubarb-lip-sync/issues/34#issuecomment-378198776).

View File

@ -232,6 +232,46 @@ target_include_directories(utf8proc SYSTEM PUBLIC "lib/utf8proc-2a2f97e1")
target_compile_options(utf8proc PRIVATE ${disableWarningsFlags}) target_compile_options(utf8proc PRIVATE ${disableWarningsFlags})
set_target_properties(utf8proc PROPERTIES FOLDER lib) 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)
# ... Vorbis
add_library(vorbis
lib/vorbis-1.3.6/include/vorbis/vorbisfile.h
lib/vorbis-1.3.6/lib/bitrate.c
lib/vorbis-1.3.6/lib/block.c
lib/vorbis-1.3.6/lib/codebook.c
lib/vorbis-1.3.6/lib/envelope.c
lib/vorbis-1.3.6/lib/floor0.c
lib/vorbis-1.3.6/lib/floor1.c
lib/vorbis-1.3.6/lib/info.c
lib/vorbis-1.3.6/lib/lpc.c
lib/vorbis-1.3.6/lib/lsp.c
lib/vorbis-1.3.6/lib/mapping0.c
lib/vorbis-1.3.6/lib/mdct.c
lib/vorbis-1.3.6/lib/psy.c
lib/vorbis-1.3.6/lib/registry.c
lib/vorbis-1.3.6/lib/res0.c
lib/vorbis-1.3.6/lib/sharedbook.c
lib/vorbis-1.3.6/lib/smallft.c
lib/vorbis-1.3.6/lib/synthesis.c
lib/vorbis-1.3.6/lib/vorbisfile.c
lib/vorbis-1.3.6/lib/window.c
)
target_include_directories(vorbis SYSTEM PUBLIC "lib/vorbis-1.3.6/include")
target_link_libraries(vorbis
ogg
)
target_compile_options(vorbis PRIVATE ${disableWarningsFlags})
set_target_properties(vorbis PROPERTIES FOLDER lib)
# Define Rhubarb libraries # Define Rhubarb libraries
include_directories("src") include_directories("src")
@ -269,11 +309,15 @@ target_link_libraries(rhubarb-animation
add_library(rhubarb-audio add_library(rhubarb-audio
src/audio/AudioClip.cpp src/audio/AudioClip.cpp
src/audio/AudioClip.h src/audio/AudioClip.h
src/audio/audioFileReading.cpp
src/audio/audioFileReading.h
src/audio/AudioSegment.cpp src/audio/AudioSegment.cpp
src/audio/AudioSegment.h src/audio/AudioSegment.h
src/audio/DcOffset.cpp src/audio/DcOffset.cpp
src/audio/DcOffset.h src/audio/DcOffset.h
src/audio/ioTools.h src/audio/ioTools.h
src/audio/OggVorbisFileReader.cpp
src/audio/OggVorbisFileReader.h
src/audio/processing.cpp src/audio/processing.cpp
src/audio/processing.h src/audio/processing.h
src/audio/SampleRateConverter.cpp src/audio/SampleRateConverter.cpp
@ -288,6 +332,7 @@ add_library(rhubarb-audio
target_include_directories(rhubarb-audio PRIVATE "src/audio") target_include_directories(rhubarb-audio PRIVATE "src/audio")
target_link_libraries(rhubarb-audio target_link_libraries(rhubarb-audio
webRtc webRtc
vorbis
rhubarb-logging rhubarb-logging
rhubarb-time rhubarb-time
rhubarb-tools rhubarb-tools
@ -406,6 +451,8 @@ add_library(rhubarb-tools
src/tools/EnumConverter.h src/tools/EnumConverter.h
src/tools/exceptions.cpp src/tools/exceptions.cpp
src/tools/exceptions.h src/tools/exceptions.h
src/tools/fileTools.cpp
src/tools/fileTools.h
src/tools/Lazy.h src/tools/Lazy.h
src/tools/nextCombination.h src/tools/nextCombination.h
src/tools/NiceCmdLineOutput.cpp src/tools/NiceCmdLineOutput.cpp

33
rhubarb/lib/ogg-1.3.3/.gitignore vendored Normal file
View File

@ -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/

View File

@ -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

View File

@ -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.

View File

@ -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

View File

@ -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
)

View File

@ -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.

View File

@ -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@"

View File

@ -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/

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.5 KiB

View File

@ -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>

View File

@ -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>

View File

@ -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;

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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 }

Binary file not shown.

After

Width:  |  Height:  |  Size: 53 KiB

View File

@ -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>

After

Width:  |  Height:  |  Size: 31 KiB

View File

@ -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>

View File

@ -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>

Binary file not shown.

After

Width:  |  Height:  |  Size: 19 KiB

View File

@ -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>

After

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 42 KiB

File diff suppressed because it is too large Load Diff

After

Width:  |  Height:  |  Size: 62 KiB

View File

@ -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]

View File

@ -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]

View File

@ -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]

View File

@ -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>

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.2 KiB

Some files were not shown because too many files have changed in this diff Show More