From 373dc625f82b47096893add42c4472e4a57ab7eb Mon Sep 17 00:00:00 2001 From: Aki Date: Wed, 9 Feb 2022 22:23:03 +0100 Subject: Moved third-party libraries to a separate subdirectory --- ogg/.gitignore | 33 - ogg/.travis.yml | 17 - ogg/AUTHORS | 7 - ogg/CHANGES | 94 -- ogg/CMakeLists.txt | 107 -- ogg/COPYING | 28 - ogg/Makefile.am | 32 - ogg/README.md | 131 -- ogg/appveyor.yml | 19 - ogg/autogen.sh | 12 - ogg/configure.ac | 185 --- ogg/doc/Makefile.am | 9 - ogg/doc/fish_xiph_org.png | Bin 2536 -> 0 bytes ogg/doc/framing.html | 429 ----- ogg/doc/index.html | 105 -- ogg/doc/libogg/Makefile.am | 39 - ogg/doc/libogg/bitpacking.html | 103 -- ogg/doc/libogg/datastructures.html | 59 - ogg/doc/libogg/decoding.html | 104 -- ogg/doc/libogg/encoding.html | 76 - ogg/doc/libogg/general.html | 109 -- ogg/doc/libogg/index.html | 39 - ogg/doc/libogg/ogg_iovec_t.html | 62 - ogg/doc/libogg/ogg_packet.html | 75 - ogg/doc/libogg/ogg_packet_clear.html | 64 - ogg/doc/libogg/ogg_page.html | 75 - ogg/doc/libogg/ogg_page_bos.html | 65 - ogg/doc/libogg/ogg_page_checksum_set.html | 62 - ogg/doc/libogg/ogg_page_continued.html | 64 - ogg/doc/libogg/ogg_page_eos.html | 65 - ogg/doc/libogg/ogg_page_granulepos.html | 65 - ogg/doc/libogg/ogg_page_packets.html | 75 - ogg/doc/libogg/ogg_page_pageno.html | 63 - ogg/doc/libogg/ogg_page_serialno.html | 63 - ogg/doc/libogg/ogg_page_version.html | 63 - ogg/doc/libogg/ogg_stream_check.html | 71 - ogg/doc/libogg/ogg_stream_clear.html | 61 - ogg/doc/libogg/ogg_stream_destroy.html | 71 - ogg/doc/libogg/ogg_stream_eos.html | 62 - ogg/doc/libogg/ogg_stream_flush.html | 67 - ogg/doc/libogg/ogg_stream_flush_fill.html | 74 - ogg/doc/libogg/ogg_stream_init.html | 66 - ogg/doc/libogg/ogg_stream_iovecin.html | 80 - ogg/doc/libogg/ogg_stream_packetin.html | 72 - ogg/doc/libogg/ogg_stream_packetout.html | 85 - ogg/doc/libogg/ogg_stream_packetpeek.html | 85 - ogg/doc/libogg/ogg_stream_pagein.html | 67 - ogg/doc/libogg/ogg_stream_pageout.html | 84 - ogg/doc/libogg/ogg_stream_pageout_fill.html | 89 - ogg/doc/libogg/ogg_stream_reset.html | 61 - ogg/doc/libogg/ogg_stream_reset_serialno.html | 67 - ogg/doc/libogg/ogg_stream_state.html | 121 -- ogg/doc/libogg/ogg_sync_buffer.html | 67 - ogg/doc/libogg/ogg_sync_check.html | 71 - ogg/doc/libogg/ogg_sync_clear.html | 62 - ogg/doc/libogg/ogg_sync_destroy.html | 68 - ogg/doc/libogg/ogg_sync_init.html | 63 - ogg/doc/libogg/ogg_sync_pageout.html | 77 - ogg/doc/libogg/ogg_sync_pageseek.html | 68 - ogg/doc/libogg/ogg_sync_reset.html | 63 - ogg/doc/libogg/ogg_sync_state.html | 77 - ogg/doc/libogg/ogg_sync_wrote.html | 73 - ogg/doc/libogg/oggpack_adv.html | 64 - ogg/doc/libogg/oggpack_adv1.html | 62 - ogg/doc/libogg/oggpack_bits.html | 62 - ogg/doc/libogg/oggpack_buffer.html | 66 - ogg/doc/libogg/oggpack_bytes.html | 67 - ogg/doc/libogg/oggpack_get_buffer.html | 62 - ogg/doc/libogg/oggpack_look.html | 66 - ogg/doc/libogg/oggpack_look1.html | 63 - ogg/doc/libogg/oggpack_read.html | 65 - ogg/doc/libogg/oggpack_read1.html | 63 - ogg/doc/libogg/oggpack_readinit.html | 64 - ogg/doc/libogg/oggpack_reset.html | 62 - ogg/doc/libogg/oggpack_write.html | 68 - ogg/doc/libogg/oggpack_writealign.html | 65 - ogg/doc/libogg/oggpack_writecheck.html | 81 - ogg/doc/libogg/oggpack_writeclear.html | 62 - ogg/doc/libogg/oggpack_writecopy.html | 69 - ogg/doc/libogg/oggpack_writeinit.html | 62 - ogg/doc/libogg/oggpack_writetrunc.html | 65 - ogg/doc/libogg/overview.html | 44 - ogg/doc/libogg/reference.html | 98 -- ogg/doc/libogg/style.css | 7 - ogg/doc/multiplex1.png | Bin 54409 -> 0 bytes ogg/doc/multiplex1.svg | 632 -------- ogg/doc/ogg-multiplex.html | 446 ------ ogg/doc/oggstream.html | 594 ------- ogg/doc/packets.png | Bin 19776 -> 0 bytes ogg/doc/packets.svg | 876 ---------- ogg/doc/pages.png | Bin 43547 -> 0 bytes ogg/doc/pages.svg | 1219 -------------- ogg/doc/rfc3533.txt | 843 ---------- ogg/doc/rfc3534.txt | 339 ---- ogg/doc/rfc5334.txt | 787 --------- ogg/doc/skeleton.html | 222 --- ogg/doc/stream.png | Bin 2254 -> 0 bytes ogg/doc/vorbisword2.png | Bin 1394 -> 0 bytes ogg/doc/white-ogg.png | Bin 2652 -> 0 bytes ogg/doc/white-xifish.png | Bin 965 -> 0 bytes ogg/include/Makefile.am | 3 - ogg/include/ogg/Makefile.am | 6 - ogg/include/ogg/config_types.h.in | 25 - ogg/include/ogg/ogg.h | 210 --- ogg/include/ogg/os_types.h | 148 -- ogg/libogg.spec.in | 109 -- ogg/macosx/English.lproj/InfoPlist.strings | Bin 136 -> 0 bytes ogg/macosx/Info.plist | 30 - ogg/macosx/Ogg.xcodeproj/project.pbxproj | 363 ----- ogg/macosx/Ogg_Prefix.pch | 5 - ogg/ogg-uninstalled.pc.in | 14 - ogg/ogg.m4 | 116 -- ogg/ogg.pc.in | 14 - ogg/releases.sha2 | 34 - ogg/src/Makefile.am | 28 - ogg/src/bitwise.c | 1088 ------------- ogg/src/framing.c | 2140 ------------------------- ogg/symbian/bld.inf | 35 - ogg/symbian/ogg.mmp | 39 - ogg/win32/.gitignore | 21 - ogg/win32/VS2015/libogg_dynamic.sln | 26 - ogg/win32/VS2015/libogg_dynamic.vcxproj | 187 --- ogg/win32/VS2015/libogg_static.sln | 26 - ogg/win32/VS2015/libogg_static.vcxproj | 174 -- ogg/win32/ogg.def | 80 - 125 files changed, 16836 deletions(-) delete mode 100644 ogg/.gitignore delete mode 100644 ogg/.travis.yml delete mode 100644 ogg/AUTHORS delete mode 100644 ogg/CHANGES delete mode 100644 ogg/CMakeLists.txt delete mode 100644 ogg/COPYING delete mode 100644 ogg/Makefile.am delete mode 100644 ogg/README.md delete mode 100644 ogg/appveyor.yml delete mode 100755 ogg/autogen.sh delete mode 100644 ogg/configure.ac delete mode 100644 ogg/doc/Makefile.am delete mode 100644 ogg/doc/fish_xiph_org.png delete mode 100644 ogg/doc/framing.html delete mode 100644 ogg/doc/index.html delete mode 100644 ogg/doc/libogg/Makefile.am delete mode 100644 ogg/doc/libogg/bitpacking.html delete mode 100644 ogg/doc/libogg/datastructures.html delete mode 100644 ogg/doc/libogg/decoding.html delete mode 100644 ogg/doc/libogg/encoding.html delete mode 100644 ogg/doc/libogg/general.html delete mode 100644 ogg/doc/libogg/index.html delete mode 100644 ogg/doc/libogg/ogg_iovec_t.html delete mode 100644 ogg/doc/libogg/ogg_packet.html delete mode 100644 ogg/doc/libogg/ogg_packet_clear.html delete mode 100644 ogg/doc/libogg/ogg_page.html delete mode 100644 ogg/doc/libogg/ogg_page_bos.html delete mode 100644 ogg/doc/libogg/ogg_page_checksum_set.html delete mode 100644 ogg/doc/libogg/ogg_page_continued.html delete mode 100644 ogg/doc/libogg/ogg_page_eos.html delete mode 100644 ogg/doc/libogg/ogg_page_granulepos.html delete mode 100644 ogg/doc/libogg/ogg_page_packets.html delete mode 100644 ogg/doc/libogg/ogg_page_pageno.html delete mode 100644 ogg/doc/libogg/ogg_page_serialno.html delete mode 100644 ogg/doc/libogg/ogg_page_version.html delete mode 100644 ogg/doc/libogg/ogg_stream_check.html delete mode 100644 ogg/doc/libogg/ogg_stream_clear.html delete mode 100644 ogg/doc/libogg/ogg_stream_destroy.html delete mode 100644 ogg/doc/libogg/ogg_stream_eos.html delete mode 100644 ogg/doc/libogg/ogg_stream_flush.html delete mode 100644 ogg/doc/libogg/ogg_stream_flush_fill.html delete mode 100644 ogg/doc/libogg/ogg_stream_init.html delete mode 100644 ogg/doc/libogg/ogg_stream_iovecin.html delete mode 100644 ogg/doc/libogg/ogg_stream_packetin.html delete mode 100644 ogg/doc/libogg/ogg_stream_packetout.html delete mode 100644 ogg/doc/libogg/ogg_stream_packetpeek.html delete mode 100644 ogg/doc/libogg/ogg_stream_pagein.html delete mode 100644 ogg/doc/libogg/ogg_stream_pageout.html delete mode 100644 ogg/doc/libogg/ogg_stream_pageout_fill.html delete mode 100644 ogg/doc/libogg/ogg_stream_reset.html delete mode 100644 ogg/doc/libogg/ogg_stream_reset_serialno.html delete mode 100644 ogg/doc/libogg/ogg_stream_state.html delete mode 100644 ogg/doc/libogg/ogg_sync_buffer.html delete mode 100644 ogg/doc/libogg/ogg_sync_check.html delete mode 100644 ogg/doc/libogg/ogg_sync_clear.html delete mode 100644 ogg/doc/libogg/ogg_sync_destroy.html delete mode 100644 ogg/doc/libogg/ogg_sync_init.html delete mode 100644 ogg/doc/libogg/ogg_sync_pageout.html delete mode 100644 ogg/doc/libogg/ogg_sync_pageseek.html delete mode 100644 ogg/doc/libogg/ogg_sync_reset.html delete mode 100644 ogg/doc/libogg/ogg_sync_state.html delete mode 100644 ogg/doc/libogg/ogg_sync_wrote.html delete mode 100644 ogg/doc/libogg/oggpack_adv.html delete mode 100644 ogg/doc/libogg/oggpack_adv1.html delete mode 100644 ogg/doc/libogg/oggpack_bits.html delete mode 100644 ogg/doc/libogg/oggpack_buffer.html delete mode 100644 ogg/doc/libogg/oggpack_bytes.html delete mode 100644 ogg/doc/libogg/oggpack_get_buffer.html delete mode 100644 ogg/doc/libogg/oggpack_look.html delete mode 100644 ogg/doc/libogg/oggpack_look1.html delete mode 100644 ogg/doc/libogg/oggpack_read.html delete mode 100644 ogg/doc/libogg/oggpack_read1.html delete mode 100644 ogg/doc/libogg/oggpack_readinit.html delete mode 100644 ogg/doc/libogg/oggpack_reset.html delete mode 100644 ogg/doc/libogg/oggpack_write.html delete mode 100644 ogg/doc/libogg/oggpack_writealign.html delete mode 100644 ogg/doc/libogg/oggpack_writecheck.html delete mode 100644 ogg/doc/libogg/oggpack_writeclear.html delete mode 100644 ogg/doc/libogg/oggpack_writecopy.html delete mode 100644 ogg/doc/libogg/oggpack_writeinit.html delete mode 100644 ogg/doc/libogg/oggpack_writetrunc.html delete mode 100644 ogg/doc/libogg/overview.html delete mode 100644 ogg/doc/libogg/reference.html delete mode 100644 ogg/doc/libogg/style.css delete mode 100644 ogg/doc/multiplex1.png delete mode 100644 ogg/doc/multiplex1.svg delete mode 100644 ogg/doc/ogg-multiplex.html delete mode 100644 ogg/doc/oggstream.html delete mode 100644 ogg/doc/packets.png delete mode 100644 ogg/doc/packets.svg delete mode 100644 ogg/doc/pages.png delete mode 100644 ogg/doc/pages.svg delete mode 100644 ogg/doc/rfc3533.txt delete mode 100644 ogg/doc/rfc3534.txt delete mode 100644 ogg/doc/rfc5334.txt delete mode 100755 ogg/doc/skeleton.html delete mode 100644 ogg/doc/stream.png delete mode 100644 ogg/doc/vorbisword2.png delete mode 100644 ogg/doc/white-ogg.png delete mode 100644 ogg/doc/white-xifish.png delete mode 100644 ogg/include/Makefile.am delete mode 100644 ogg/include/ogg/Makefile.am delete mode 100644 ogg/include/ogg/config_types.h.in delete mode 100644 ogg/include/ogg/ogg.h delete mode 100644 ogg/include/ogg/os_types.h delete mode 100644 ogg/libogg.spec.in delete mode 100644 ogg/macosx/English.lproj/InfoPlist.strings delete mode 100644 ogg/macosx/Info.plist delete mode 100644 ogg/macosx/Ogg.xcodeproj/project.pbxproj delete mode 100644 ogg/macosx/Ogg_Prefix.pch delete mode 100644 ogg/ogg-uninstalled.pc.in delete mode 100644 ogg/ogg.m4 delete mode 100644 ogg/ogg.pc.in delete mode 100644 ogg/releases.sha2 delete mode 100644 ogg/src/Makefile.am delete mode 100644 ogg/src/bitwise.c delete mode 100644 ogg/src/framing.c delete mode 100644 ogg/symbian/bld.inf delete mode 100644 ogg/symbian/ogg.mmp delete mode 100644 ogg/win32/.gitignore delete mode 100644 ogg/win32/VS2015/libogg_dynamic.sln delete mode 100644 ogg/win32/VS2015/libogg_dynamic.vcxproj delete mode 100644 ogg/win32/VS2015/libogg_static.sln delete mode 100644 ogg/win32/VS2015/libogg_static.vcxproj delete mode 100644 ogg/win32/ogg.def (limited to 'ogg') diff --git a/ogg/.gitignore b/ogg/.gitignore deleted file mode 100644 index 255f7b0..0000000 --- a/ogg/.gitignore +++ /dev/null @@ -1,33 +0,0 @@ -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/ diff --git a/ogg/.travis.yml b/ogg/.travis.yml deleted file mode 100644 index 43a3b1a..0000000 --- a/ogg/.travis.yml +++ /dev/null @@ -1,17 +0,0 @@ -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 diff --git a/ogg/AUTHORS b/ogg/AUTHORS deleted file mode 100644 index a0023f2..0000000 --- a/ogg/AUTHORS +++ /dev/null @@ -1,7 +0,0 @@ -Monty -Greg Maxwell -Ralph Giles -Cristian Adam -Tim Terriberry - -and the rest of the Xiph.Org Foundation. diff --git a/ogg/CHANGES b/ogg/CHANGES deleted file mode 100644 index 6814e31..0000000 --- a/ogg/CHANGES +++ /dev/null @@ -1,94 +0,0 @@ -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 - diff --git a/ogg/CMakeLists.txt b/ogg/CMakeLists.txt deleted file mode 100644 index 24f204f..0000000 --- a/ogg/CMakeLists.txt +++ /dev/null @@ -1,107 +0,0 @@ -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}) -target_include_directories(ogg PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include) -add_library(Ogg::ogg ALIAS ogg) - -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) diff --git a/ogg/COPYING b/ogg/COPYING deleted file mode 100644 index 6111c6c..0000000 --- a/ogg/COPYING +++ /dev/null @@ -1,28 +0,0 @@ -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. diff --git a/ogg/Makefile.am b/ogg/Makefile.am deleted file mode 100644 index 8bfe303..0000000 --- a/ogg/Makefile.am +++ /dev/null @@ -1,32 +0,0 @@ -## 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@" diff --git a/ogg/README.md b/ogg/README.md deleted file mode 100644 index 2e8a3d7..0000000 --- a/ogg/README.md +++ /dev/null @@ -1,131 +0,0 @@ -# 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/ diff --git a/ogg/appveyor.yml b/ogg/appveyor.yml deleted file mode 100644 index c419edb..0000000 --- a/ogg/appveyor.yml +++ /dev/null @@ -1,19 +0,0 @@ -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 diff --git a/ogg/autogen.sh b/ogg/autogen.sh deleted file mode 100755 index c9782e1..0000000 --- a/ogg/autogen.sh +++ /dev/null @@ -1,12 +0,0 @@ -#!/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 diff --git a/ogg/configure.ac b/ogg/configure.ac deleted file mode 100644 index 33c88ab..0000000 --- a/ogg/configure.ac +++ /dev/null @@ -1,185 +0,0 @@ -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 diff --git a/ogg/doc/Makefile.am b/ogg/doc/Makefile.am deleted file mode 100644 index 3dd47b9..0000000 --- a/ogg/doc/Makefile.am +++ /dev/null @@ -1,9 +0,0 @@ -## 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 - diff --git a/ogg/doc/fish_xiph_org.png b/ogg/doc/fish_xiph_org.png deleted file mode 100644 index b398c06..0000000 Binary files a/ogg/doc/fish_xiph_org.png and /dev/null differ diff --git a/ogg/doc/framing.html b/ogg/doc/framing.html deleted file mode 100644 index b5ac6ac..0000000 --- a/ogg/doc/framing.html +++ /dev/null @@ -1,429 +0,0 @@ - - - - - -Ogg Documentation - - - - - - - - - -

Ogg logical bitstream framing

- -

Ogg bitstreams

- -

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.

- -

Application example: Vorbis

- -

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.

- -

Design constraints for Ogg bitstreams

- -
    -
  1. True streaming; we must not need to seek to build a 100% - complete bitstream.
    2. -
  2. Use no more than approximately 1-2% of bitstream bandwidth for - packet boundary marking, high-level framing, sync and seeking.
    3. -
  3. Specification of absolute position within the original sample - stream.
    4. -
  4. Simple mechanism to ease limited editing, such as a simplified - concatenation mechanism.
    5. -
  5. Detection of corruption, recapture after error and direct, random - access to data at arbitrary positions in the bitstream.
    6. -
- -

Logical and Physical Bitstreams

- -

A logical Ogg bitstream is a contiguous stream of -sequential pages belonging only to the logical bitstream. A -physical 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 -Ogg bitstream overview. The exact -mapping of raw Vorbis packets into a valid Ogg Vorbis physical -bitstream is described in the Vorbis I Specification.

- -

Bitstream structure

- -

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.

- -

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.

- -

Packet segmentation

- -

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.

- -

The raw packet is logically divided into [n] 255 byte segments and a -last fractional segment of < 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.

- -

An example should make the basic concept clear:

- -
-
-raw packet:
-  ___________________________________________
- |______________packet data__________________| 753 bytes
-
-lacing values for page header segment table: 255,255,243
-
-
- -

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

- -

Note that a lacing value of 255 implies that a second lacing value -follows in the packet, and a value of < 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:

- -

-raw packet:
-  _______________________________
- |________packet data____________|          255 bytes
-
-lacing values: 255, 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.

- -

Packets spanning pages

- -

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.

- -

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

- -

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.

- -

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.

- -

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

- -

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.

- - -

Page header

- -

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.

- -

capture_pattern

- -

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

- -

- byte value
-
-  0  0x4f 'O'
-  1  0x67 'g'
-  2  0x67 'g'
-  3  0x53 'S'  
-
- -

stream_structure_version

- -

The capture pattern is followed by the stream structure revision:

- -

- byte value
-
-  4  0x00
-
- -

header_type_flag

- -

The header type flag identifies this page's context in the bitstream:

- -

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

absolute granule position

- -

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

- -

A special value of '-1' (in two's complement) indicates that no packets -finish on this page.

- -

- byte value
-
-  6  0xXX LSB
-  7  0xXX
-  8  0xXX
-  9  0xXX
- 10  0xXX
- 11  0xXX
- 12  0xXX
- 13  0xXX MSB
-
- -

stream serial number

- -

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:

- -

- byte value
-
- 14  0xXX LSB
- 15  0xXX
- 16  0xXX
- 17  0xXX MSB
-
- -

page sequence no

- -

Page counter; lets us know if a page is lost (useful where packets -span page boundaries).

- -

- byte value
-
- 18  0xXX LSB
- 19  0xXX
- 20  0xXX
- 21  0xXX MSB
-
- -

page checksum

- -

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.

- -

(A thorough discussion of CRC algorithms can be found in "A -Painless Guide to CRC Error Detection Algorithms" by Ross -Williams ross@ross.net.)

- -

- byte value
-
- 22  0xXX LSB
- 23  0xXX
- 24  0xXX
- 25  0xXX MSB
-
- -

page_segments

- -

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

- -

- byte value
-
- 26 0x00-0xff (0-255)
-
- -

segment_table (containing packet lacing values)

- -

The lacing values for each packet segment physically appearing in -this page are listed in contiguous order.

- -

- byte value
-
- 27 0x00-0xff (0-255)
- [...]
- n  0x00-0xff (0-255, n=page_segments+26)
-
- -

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.

- -

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.

- - - - - diff --git a/ogg/doc/index.html b/ogg/doc/index.html deleted file mode 100644 index 6e02f79..0000000 --- a/ogg/doc/index.html +++ /dev/null @@ -1,105 +0,0 @@ - - - - - -Ogg Documentation - - - - - - - - - -

Ogg Documentation

- -

Ogg programming documentation

- - - -

Ogg bitstream documentation

- - - -

RFC documentation

- - - - - - - diff --git a/ogg/doc/libogg/Makefile.am b/ogg/doc/libogg/Makefile.am deleted file mode 100644 index 4007907..0000000 --- a/ogg/doc/libogg/Makefile.am +++ /dev/null @@ -1,39 +0,0 @@ -## 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; - diff --git a/ogg/doc/libogg/bitpacking.html b/ogg/doc/libogg/bitpacking.html deleted file mode 100644 index cc76015..0000000 --- a/ogg/doc/libogg/bitpacking.html +++ /dev/null @@ -1,103 +0,0 @@ - - - -libogg - Bitpacking Functions - - - - - - - - - -

libogg documentation

libogg release 1.3.2 - 20140527

- -

Bitpacking Functions

-

Libogg contains a basic bitpacking library that is useful for manipulating data within a buffer. -

-All the libogg specific functions are declared in "ogg/ogg.h". -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
functionpurpose
oggpack_writeinitInitializes a buffer for writing using this bitpacking library.
oggpack_writecheckAsynchronously checks error status of bitpacker write buffer.
oggpack_resetClears and resets the buffer to the initial position.
oggpack_writeclearFrees the memory used by the buffer.
oggpack_readinitInitializes a buffer for reading using this bitpacking library.
oggpack_writeWrites bytes to the specified location within the buffer.
oggpack_lookLook at a specified number of bits, <=32, without advancing the location pointer.
oggpack_look1Looks at one bit without advancing the location pointer.
oggpack_advAdvances the location pointer by a specified number of bits.
oggpack_adv1Advances the location pointer by one bit.
oggpack_readReads a specified number of bits from the buffer.
oggpack_read1Reads one bit from the buffer.
oggpack_bytesReturns the total number of bytes contained within the buffer.
oggpack_bitsReturns the total number of bits contained within the buffer.
oggpack_get_bufferReturns a pointer to the buffer encapsulated within the oggpack_buffer struct.
- -

-

- - - - - - - - -

copyright © 2000-2014 Xiph.Org

Ogg Container Format

libogg documentation

libogg release 1.3.2 - 20140527

- - - - diff --git a/ogg/doc/libogg/datastructures.html b/ogg/doc/libogg/datastructures.html deleted file mode 100644 index 0f56102..0000000 --- a/ogg/doc/libogg/datastructures.html +++ /dev/null @@ -1,59 +0,0 @@ - - - -libogg - Base Data Structures - - - - - - - - - -

libogg documentation

libogg release 1.3.2 - 20140527

- -

Base Data Structures

-

Libogg uses several data structures to hold data and state information. -

-All the libogg specific data structures are declared in "ogg/ogg.h". -

- - - - - - - - - - - - - - - - - - - - - - -
datatypepurpose
ogg_pageThis structure encapsulates data into one ogg bitstream page.
ogg_stream_stateThis structure contains current encode/decode data for a logical bitstream.
ogg_packetThis structure encapsulates the data and metadata for a single Ogg packet.
ogg_sync_stateContains bitstream synchronization information.
- -

-

- - - - - - - - -

copyright © 2000-2014 Xiph.Org

Ogg Container Format

libogg documentation

libogg release 1.3.2 - 20140527

- - - - diff --git a/ogg/doc/libogg/decoding.html b/ogg/doc/libogg/decoding.html deleted file mode 100644 index f393a07..0000000 --- a/ogg/doc/libogg/decoding.html +++ /dev/null @@ -1,104 +0,0 @@ - - - -libogg - Decoding - - - - - - - - - -

libogg documentation

libogg release 1.3.2 - 20140527

- -

Decoding

-

Libogg contains a set of functions used in the decoding process. -

-All the libogg specific functions are declared in "ogg/ogg.h". -

-

Decoding is based around the ogg synchronization layer. The ogg_sync_state 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. -

Decoding through the Ogg layer follows a specific logical sequence. A read loop follows these logical steps: -

-

In practice, streams are more complex, and Ogg also must handle headers, incomplete or dropped pages, and other errors in input. -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
functionpurpose
ogg_sync_initInitializes an Ogg bitstream.
ogg_sync_clearClears the status information from the synchronization struct. -
ogg_sync_resetResets the synchronization status to initial values.
ogg_sync_destroyFrees the synchronization struct.
ogg_sync_checkCheck for asynchronous errors.
ogg_sync_bufferExposes a buffer from the synchronization layer in order to read data.
ogg_sync_wroteTells the synchronization layer how many bytes were written into the buffer.
ogg_sync_pageseekFinds the borders of pages and resynchronizes the stream.
ogg_sync_pageoutOutputs a page from the synchronization layer.
ogg_stream_pageinSubmits a complete page to the stream layer.
ogg_stream_packetoutOutputs a packet to the codec-specific decoding engine.
ogg_stream_packetpeekProvides access to the next packet in the bitstream without -advancing decoding.
- -

-

- - - - - - - - -

copyright © 2000-2014 Xiph.Org

Ogg Container Format

libogg documentation

libogg release 1.3.2 - 20140527

- - - - diff --git a/ogg/doc/libogg/encoding.html b/ogg/doc/libogg/encoding.html deleted file mode 100644 index 6aa8470..0000000 --- a/ogg/doc/libogg/encoding.html +++ /dev/null @@ -1,76 +0,0 @@ - - - -libogg - Encoding - - - - - - - - - -

libogg documentation

libogg release 1.3.2 - 20140527

- -

Encoding

-

Libogg contains a set of functions used in the encoding process. -

-All the libogg specific functions are declared in "ogg/ogg.h". -

-

When encoding, the encoding engine will output raw packets which must be placed into an Ogg bitstream. -

Raw packets are inserted into the stream, and an ogg_page 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. -

There are a couple of basic steps: -

    -
  • Use the encoding engine to produce a raw packet of data. -
  • Call ogg_stream_packetin to submit a raw packet to the stream. -
  • Use ogg_stream_pageout to output a page, if enough data has been submitted. Otherwise, continue submitting data. -
-

- - - - - - - - - - - - - - - - - - - - - - - - - - -
functionpurpose
ogg_stream_packetinSubmits a raw packet to the streaming layer, so that it can be formed into a page.
ogg_stream_ioveciniovec version of ogg_stream_packetin() above.
ogg_stream_pageoutOutputs a completed page if the stream contains enough packets to form a full page. -
ogg_stream_pageout_fillSimilar to ogg_stream_pageout(), but specifies a page spill threshold in bytes. -
ogg_stream_flushForces any remaining packets in the stream to be returned as a page of any size. -
ogg_stream_flush_fillSimilar to ogg_stream_flush(), but specifies a page spill threshold in bytes. -
- -

-
- - - - - - - - -

copyright © 2000-2014 Xiph.Org

Ogg Container Format

libogg documentation

libogg release 1.3.2 - 20140527

- - - - diff --git a/ogg/doc/libogg/general.html b/ogg/doc/libogg/general.html deleted file mode 100644 index d892dd3..0000000 --- a/ogg/doc/libogg/general.html +++ /dev/null @@ -1,109 +0,0 @@ - - - -libogg - General Functions - - - - - - - - - -

libogg documentation

libogg release 1.3.2 - 20140527

- -

General Functions

-

Libogg contains several functions which are generally useful when using Ogg streaming, whether encoding or decoding. -

-All the libogg specific functions are declared in "ogg/ogg.h". -

-

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. -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
functionpurpose
ogg_stream_initInitializes an Ogg bitstream.
ogg_stream_clearClears the storage within the Ogg stream, but does not free the stream itself. -
ogg_stream_resetResets the stream status to its initial position.
ogg_stream_destroyFrees the entire Ogg stream.
ogg_stream_checkCheck for asyncronous errors.
ogg_stream_eosIndicates whether we are at the end of the stream.
ogg_page_versionReturns the version of ogg_page that this stream/page uses
ogg_page_continuedIndicates if the current page contains a continued packet from the last page.
ogg_page_packetsIndicates the number of packets contained in a page.
ogg_page_bosIndicates if the current page is the beginning of the stream.
ogg_page_eosIndicates if the current page is the end of the stream.
ogg_page_granuleposReturns the precise playback location of this page.
ogg_page_serialnoReturns the unique serial number of the logical bitstream associated with this page.
ogg_page_pagenoReturns the sequential page number for this page.
ogg_packet_clearClears the ogg_packet structure.
ogg_page_checksum_setChecksums an ogg_page.
- -

-

- - - - - - - - -

copyright © 2000-2014 Xiph.Org

Ogg Container Format

libogg documentation

libogg release 1.3.2 - 20140527

- - - - diff --git a/ogg/doc/libogg/index.html b/ogg/doc/libogg/index.html deleted file mode 100644 index 6d3feab..0000000 --- a/ogg/doc/libogg/index.html +++ /dev/null @@ -1,39 +0,0 @@ - - - -libogg - Documentation - - - - - - - - - -

libogg documentation

libogg release 1.3.2 - 20140527

- -

Libogg Documentation

- -

-Libogg contains necessary functionality to create, decode, and work with Ogg bitstreams. -

This document explains how to use the libogg API in detail. -

-libogg api overview
-libogg api reference
- -

-

- - - - - - - - -

copyright © 2000-2014 Xiph.Org

Ogg Container Format

libogg documentation

libogg release 1.3.2 - 20140527

- - - - diff --git a/ogg/doc/libogg/ogg_iovec_t.html b/ogg/doc/libogg/ogg_iovec_t.html deleted file mode 100644 index 2cf7e8b..0000000 --- a/ogg/doc/libogg/ogg_iovec_t.html +++ /dev/null @@ -1,62 +0,0 @@ - - - -libogg - datatype - ogg_iovec_t - - - - - - - - - -

libogg documentation

libogg release 1.3.2 - 20140527

- -

ogg_iovec_t

- -

declared in "ogg/ogg.h"

- -

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

- - - - - -
-

-typedef struct {
-  void *iov_base;
-  size_t iov_len;
-} ogg_iovec_t;
-
-
- -

Relevant Struct Members

-
-
iov_base
-
Pointer to the buffer data.
-
iov_len
-
Length of buffer data in bytes.
-
- - -

-
- - - - - - - - -

copyright © 2000-2014 Xiph.Org

Ogg Container Format

libogg documentation

libogg release 1.3.2 - 20140527

- - - - diff --git a/ogg/doc/libogg/ogg_packet.html b/ogg/doc/libogg/ogg_packet.html deleted file mode 100644 index 5672eba..0000000 --- a/ogg/doc/libogg/ogg_packet.html +++ /dev/null @@ -1,75 +0,0 @@ - - - -libogg - datatype - ogg_packet - - - - - - - - - -

libogg documentation

libogg release 1.3.2 - 20140527

- -

ogg_packet

- -

declared in "ogg/ogg.h"

- -

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

- - - - - -
-

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

Relevant Struct Members

-
-
packet
-
Pointer to the packet's data. This is treated as an opaque type by the ogg layer.
-
bytes
-
Indicates the size of the packet data in bytes. Packets can be of arbitrary size.
-
b_o_s
-
Flag indicating whether this packet begins a logical bitstream. 1 indicates this is the first packet, 0 indicates any other position in the stream.
-
e_o_s
-
Flag indicating whether this packet ends a bitstream. 1 indicates the last packet, 0 indicates any other position in the stream.
-
granulepos
-
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.
-
packetno
-
Sequential number of this packet in the ogg bitstream.
-
- - -

-
- - - - - - - - -

copyright © 2000-2014 Xiph.Org

Ogg Container Format

libogg documentation

libogg release 1.3.2 - 20140527

- - - - diff --git a/ogg/doc/libogg/ogg_packet_clear.html b/ogg/doc/libogg/ogg_packet_clear.html deleted file mode 100644 index 87dadea..0000000 --- a/ogg/doc/libogg/ogg_packet_clear.html +++ /dev/null @@ -1,64 +0,0 @@ - - - -libogg - function - ogg_packet_clear - - - - - - - - - -

libogg documentation

libogg release 1.3.2 - 20140527

- -

ogg_packet_clear

- -

declared in "ogg/ogg.h";

- -

This function clears the memory used by the ogg_packet struct, -but does not free the structure itself. -It unconditionally frees the packet data buffer, -then it zeros all structure members. -

- - - - -
-

-void ogg_packet_clear(ogg_packet *op);
-
-
- -

Parameters

-
-
op
-
Pointer to the ogg_packet struct to be cleared.
-
- - -

Return Values

-
-
  • -None.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_page.html b/ogg/doc/libogg/ogg_page.html deleted file mode 100644 index ac1a994..0000000 --- a/ogg/doc/libogg/ogg_page.html +++ /dev/null @@ -1,75 +0,0 @@ - - - -libogg - datatype - ogg_page - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_page

    - -

    declared in "ogg/ogg.h"

    - -

    -The ogg_page struct encapsulates the data for an Ogg page. -

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

    -

    For a complete description of ogg pages and headers, please refer to the framing document. - - - - - -
    -
    
-typedef struct {
-  unsigned char *header;
-  long           header_len;
-  unsigned char *body;
-  long           body_len;
-} ogg_page;
-
    -
    - -

    Relevant Struct Members

    -
    -
    header
    -
    Pointer to the page header for this page. The exact contents of this header are defined in the framing spec document.
    -
    header_len
    -
    Length of the page header in bytes. -
    body
    -
    Pointer to the data for this page.
    -
    body_len
    -
    Length of the body data in bytes.
    -
    - - -

    -
    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - diff --git a/ogg/doc/libogg/ogg_page_bos.html b/ogg/doc/libogg/ogg_page_bos.html deleted file mode 100644 index 9286e1a..0000000 --- a/ogg/doc/libogg/ogg_page_bos.html +++ /dev/null @@ -1,65 +0,0 @@ - - - -libogg - function - ogg_page_bos - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_page_bos

    - -

    declared in "ogg/ogg.h";

    - -

    Indicates whether this page is at the beginning of the logical bitstream. -

    -

    - - - - -
    -
    
-int ogg_page_bos(ogg_page *og);
-
-
    -
    - -

    Parameters

    -
    -
    og
    -
    Pointer to the current ogg_page struct.
    -
    - - -

    Return Values

    -
    -
  • -greater than 0 if this page is the beginning of a bitstream.
    • -
  • -0 if this page is from any other location in the stream.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_page_checksum_set.html b/ogg/doc/libogg/ogg_page_checksum_set.html deleted file mode 100644 index 9af7d4e..0000000 --- a/ogg/doc/libogg/ogg_page_checksum_set.html +++ /dev/null @@ -1,62 +0,0 @@ - - - -libogg - function - ogg_page_checksum_set - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_page_checksum_set

    - -

    declared in "ogg/ogg.h";

    - -

    Checksums an ogg_page. -

    -

    - - - - -
    -
    
-int ogg_page_checksum_set(ogg_page *og);
-
-
    -
    - -

    Parameters

    -
    -
    og
    -
    Pointer to an ogg_page struct.
    -
    - - -

    Return Values

    -
    -None. -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_page_continued.html b/ogg/doc/libogg/ogg_page_continued.html deleted file mode 100644 index 20b4ede..0000000 --- a/ogg/doc/libogg/ogg_page_continued.html +++ /dev/null @@ -1,64 +0,0 @@ - - - -libogg - function - ogg_page_version - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_page_continued

    - -

    declared in "ogg/ogg.h";

    - -

    Indicates whether this page contains packet data which has been continued from the previous page. -

    - - - - -
    -
    
-int ogg_page_continued(ogg_page *og);
-
-
    -
    - -

    Parameters

    -
    -
    og
    -
    Pointer to the current ogg_page struct.
    -
    - - -

    Return Values

    -
    -
  • -1 if this page contains packet data continued from the last page.
    • -
  • -0 if this page does not contain continued data.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_page_eos.html b/ogg/doc/libogg/ogg_page_eos.html deleted file mode 100644 index d81ebae..0000000 --- a/ogg/doc/libogg/ogg_page_eos.html +++ /dev/null @@ -1,65 +0,0 @@ - - - -libogg - function - ogg_page_eos - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_page_eos

    - -

    declared in "ogg/ogg.h";

    - -

    Indicates whether this page is at the end of the logical bitstream. -

    -

    - - - - -
    -
    
-int ogg_page_eos(ogg_page *og);
-
-
    -
    - -

    Parameters

    -
    -
    og
    -
    Pointer to the current ogg_page struct.
    -
    - - -

    Return Values

    -
    -
  • -greater than zero if this page contains the end of a bitstream.
    • -
  • -0 if this page is from any other location in the stream.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_page_granulepos.html b/ogg/doc/libogg/ogg_page_granulepos.html deleted file mode 100644 index 826b48e..0000000 --- a/ogg/doc/libogg/ogg_page_granulepos.html +++ /dev/null @@ -1,65 +0,0 @@ - - - -libogg - function - ogg_page_granulepos - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_page_granulepos

    - -

    declared in "ogg/ogg.h";

    - -

    Returns the exact granular position of the packet data contained at the end of this page. -

    This is useful for tracking location when seeking or decoding. -

    For example, in audio codecs this position is the pcm sample number and in video this is the frame number. -

    -

    - - - - -
    -
    
-ogg_in64_t ogg_page_granulepos(ogg_page *og);
-
-
    -
    - -

    Parameters

    -
    -
    og
    -
    Pointer to the current ogg_page struct.
    -
    - - -

    Return Values

    -
    -
  • -n is the specific last granular position of the decoded data contained in the page.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_page_packets.html b/ogg/doc/libogg/ogg_page_packets.html deleted file mode 100644 index 0115777..0000000 --- a/ogg/doc/libogg/ogg_page_packets.html +++ /dev/null @@ -1,75 +0,0 @@ - - - -libogg - function - ogg_page_packets - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_page_packets

    - -

    declared in "ogg/ogg.h";

    - -

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

    -

    - - - - -
    -
    
-int ogg_page_packets(ogg_page *og);
-
-
    -
    - -

    Parameters

    -
    -
    og
    -
    Pointer to the current ogg_page struct.
    -
    - - -

    Return Values

    -
    -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:
    -
    -ogg_page_packets(page) will return 1,
    -ogg_page_continued(paged) will return non-zero.
    -

    -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:
    -
    -ogg_page_packets(page) will return 0,
    -ogg_page_continued(page) will return non-zero.
    -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_page_pageno.html b/ogg/doc/libogg/ogg_page_pageno.html deleted file mode 100644 index b70b550..0000000 --- a/ogg/doc/libogg/ogg_page_pageno.html +++ /dev/null @@ -1,63 +0,0 @@ - - - -libogg - function - ogg_page_pageno - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_page_pageno

    - -

    declared in "ogg/ogg.h";

    - -

    Returns the sequential page number. -

    This is useful for ordering pages or determining when pages have been lost. -

    - - - - -
    -
    
-long ogg_page_pageno(ogg_page *og);
-
-
    -
    - -

    Parameters

    -
    -
    og
    -
    Pointer to the current ogg_page struct.
    -
    - - -

    Return Values

    -
    -
  • -n is the page number for this page.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_page_serialno.html b/ogg/doc/libogg/ogg_page_serialno.html deleted file mode 100644 index 12ff580..0000000 --- a/ogg/doc/libogg/ogg_page_serialno.html +++ /dev/null @@ -1,63 +0,0 @@ - - - -libogg - function - ogg_page_serialno - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_page_serialno

    - -

    declared in "ogg/ogg.h";

    - -

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

    -

    - - - - -
    -
    
-int ogg_page_serialno(ogg_page *og);
-
-
    -
    - -

    Parameters

    -
    -
    og
    -
    Pointer to the current ogg_page struct.
    -
    - - -

    Return Values

    -
    -
  • -n is the serial number for this page.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_page_version.html b/ogg/doc/libogg/ogg_page_version.html deleted file mode 100644 index 01062ff..0000000 --- a/ogg/doc/libogg/ogg_page_version.html +++ /dev/null @@ -1,63 +0,0 @@ - - - -libogg - function - ogg_page_version - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_page_version

    - -

    declared in "ogg/ogg.h";

    - -

    This function returns the version of ogg_page used in this page. -

    In current versions of libogg, all ogg_page structs have the same version, so 0 should always be returned. -

    - - - - -
    -
    
-int ogg_page_version(ogg_page *og);
-
-
    -
    - -

    Parameters

    -
    -
    og
    -
    Pointer to the current ogg_page struct.
    -
    - - -

    Return Values

    -
    -
  • -n 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.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_stream_check.html b/ogg/doc/libogg/ogg_stream_check.html deleted file mode 100644 index 64d171f..0000000 --- a/ogg/doc/libogg/ogg_stream_check.html +++ /dev/null @@ -1,71 +0,0 @@ - - - -libogg - function - ogg_stream_check - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_check

    - -

    declared in "ogg/ogg.h";

    - -

    This function is used to check the error or readiness condition of an ogg_stream_state structure. -

    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 ogg_stream_state structure will be cleared (equivalent to a -call to -ogg_stream_clear) and subsequent calls -using this ogg_stream_state will be -noops. Error detection is then handled via a single call to -ogg_stream_check at the end of the operational block.

    - -

    - - - - -
    -
    
-int ogg_stream_check(ogg_stream_state *os);
-
    -
    - -

    Parameters

    -
    -
    os
    -
    Pointer to a previously declared ogg_stream_state struct.
    -
    - - -

    Return Values

    -
    -
  • -0 is returned if the ogg_stream_state structure is initialized and ready.
    • -
  • -nonzero is returned if the structure was never initialized, or if an unrecoverable internal error occurred in a previous call using the passed in ogg_stream_state struct.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_stream_clear.html b/ogg/doc/libogg/ogg_stream_clear.html deleted file mode 100644 index 83149e0..0000000 --- a/ogg/doc/libogg/ogg_stream_clear.html +++ /dev/null @@ -1,61 +0,0 @@ - - - -libogg - function - ogg_stream_clear - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_clear

    - -

    declared in "ogg/ogg.h";

    - -

    This function clears and frees the internal memory used by the ogg_stream_state struct, but does not free the structure itself. It is safe to call ogg_stream_clear on the same structure more than once. -

    - - - - -
    -
    
-int ogg_stream_clear(ogg_stream_state *os);
-
    -
    - -

    Parameters

    -
    -
    os
    -
    Pointer to the ogg_stream_state struct to be cleared.
    -
    - - -

    Return Values

    -
    -
  • -0 is always returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_stream_destroy.html b/ogg/doc/libogg/ogg_stream_destroy.html deleted file mode 100644 index 5eee7f0..0000000 --- a/ogg/doc/libogg/ogg_stream_destroy.html +++ /dev/null @@ -1,71 +0,0 @@ - - - -libogg - function - ogg_stream_destroy - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_destroy

    - -

    declared in "ogg/ogg.h";

    - -

    This function frees the internal memory used by -the ogg_stream_state struct as -well as the structure itself. - -

    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.

    - -

    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 -ogg_stream_clear instead.

    - -

    - - - - -
    -
    
-int ogg_stream_destroy(ogg_stream_state *os);
-
    -
    - -

    Parameters

    -
    -
    os
    -
    Pointer to the ogg_stream_state struct to be destroyed.
    -
    - - -

    Return Values

    -
    -
  • -0 is always returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_stream_eos.html b/ogg/doc/libogg/ogg_stream_eos.html deleted file mode 100644 index 519e618..0000000 --- a/ogg/doc/libogg/ogg_stream_eos.html +++ /dev/null @@ -1,62 +0,0 @@ - - - -libogg - function - ogg_stream_eos - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_eos

    - -

    declared in "ogg/ogg.h";

    - -

    This function indicates whether we have reached the end of the stream or not. -

    - - - - -
    -
    
-int ogg_stream_eos(ogg_stream_state *os);
-
    -
    - -

    Parameters

    -
    -
    os
    -
    Pointer to the current ogg_stream_state struct.
    -
    - - -

    Return Values

    -
    -
  • 1 if we are at the end of the stream or an internal error occurred.
    • -
  • -0 if we have not yet reached the end of the stream.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_stream_flush.html b/ogg/doc/libogg/ogg_stream_flush.html deleted file mode 100644 index 317f442..0000000 --- a/ogg/doc/libogg/ogg_stream_flush.html +++ /dev/null @@ -1,67 +0,0 @@ - - - -libogg - function - ogg_stream_flush - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_flush

    - -

    declared in "ogg/ogg.h";

    - -

    This function checks for remaining packets inside the stream and forces remaining packets into a page, regardless of the size of the page. -

    This should only be used when you want to flush an undersized page from the middle of the stream. Otherwise, ogg_stream_pageout or ogg_stream_pageout_fill should always be used. -

    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 ogg_stream_pageout, it should generally be called in a loop until available packet data has been flushes, since even a single packet may span multiple pages. - -

    - - - - -
    -
    
-int ogg_stream_flush(ogg_stream_state *os, ogg_page *og);
-
    -
    - -

    Parameters

    -
    -
    os
    -
    Pointer to a previously declared ogg_stream_state struct, which represents the current logical bitstream.
    -
    og
    -
    Pointer to a page of data. The remaining packets in the stream will be placed into this page, if any remain. -
    - - -

    Return Values

    -
    -
  • 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 ogg_stream_state that has been cleared explicitly or implicitly due to an internal error.
    • -
  • -Nonzero means that remaining packets have successfully been flushed into the page.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_stream_flush_fill.html b/ogg/doc/libogg/ogg_stream_flush_fill.html deleted file mode 100644 index 62aa11a..0000000 --- a/ogg/doc/libogg/ogg_stream_flush_fill.html +++ /dev/null @@ -1,74 +0,0 @@ - - - -libogg - function - ogg_stream_flush_fill - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_flush_fill

    - -

    declared in "ogg/ogg.h";

    - -

    This function flushes available packets into pages, similar to -ogg_stream_flush(), but -allows applications to explicitly request a specific page spill -size.

    - -

    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. ogg_stream_flush may be used instead if a particular page size isn't important. -

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

    - - - - -
    -
    
-int ogg_stream_flush_fill(ogg_stream_state *os, ogg_page *og, int fillbytes);
-
    -
    - -

    Parameters

    -
    -
    os
    -
    Pointer to a previously declared ogg_stream_state struct, which represents the current logical bitstream.
    -
    og
    -
    Pointer to a page of data. The remaining packets in the stream will be placed into this page, if any remain. -
    fillbytes
    -
    Packet data watermark in bytes.
    -
    - - -

    Return Values

    -
    -
  • 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 ogg_stream_state that has been cleared explicitly or implicitly due to an internal error.
    • -
  • -Nonzero means that remaining packets have successfully been flushed into the page.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_stream_init.html b/ogg/doc/libogg/ogg_stream_init.html deleted file mode 100644 index 4459ee9..0000000 --- a/ogg/doc/libogg/ogg_stream_init.html +++ /dev/null @@ -1,66 +0,0 @@ - - - -libogg - function - ogg_stream_init - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_init

    - -

    declared in "ogg/ogg.h";

    - -

    This function is used to initialize an ogg_stream_state struct and allocates appropriate memory in preparation for encoding or decoding. -

    It also assigns the stream a given serial number. -

    - - - - -
    -
    
-int ogg_stream_init(ogg_stream_state *os,int serialno);
-
    -
    - -

    Parameters

    -
    -
    os
    -
    Pointer to the ogg_stream_state struct that we will be initializing.
    -
    serialno
    -
    Serial number that we will attach to this stream.
    -
    - - -

    Return Values

    -
    -
  • -0 if successful
    • -
  • --1 if unsuccessful.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_stream_iovecin.html b/ogg/doc/libogg/ogg_stream_iovecin.html deleted file mode 100644 index b7cfe67..0000000 --- a/ogg/doc/libogg/ogg_stream_iovecin.html +++ /dev/null @@ -1,80 +0,0 @@ - - - -libogg - function - ogg_stream_iovecin - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_iovecin

    - -

    declared in "ogg/ogg.h";

    - -

    This function submits packet data (in the form of -an array of ogg_iovec_t, rather than using -an ogg_packet structure) to the -bitstream for page encapsulation. After this is called, more packets -can be submitted, or pages can be written out.

    - -

    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 ogg_stream_state, so the caller -is free to alter the contents of os after this call has returned. - -

    - - - - -
    -
    
-int ogg_stream_iovecin(ogg_stream_state *os, ogg_iovec_t *iov, int count, long e_o_s, ogg_int64_t granulepos);
-
    -
    - -

    Parameters

    -
    -
    os
    -
    Pointer to a previously declared ogg_stream_state struct.
    -
    iov
    -
    Length-encoded buffers held in an array of ogg_iovec_t. -
    count
    -
    Length of the iov array. -
    e_o_s
    -
    End of stream flag, analagous to the e_o_s field in an ogg_packet. -
    granulepos
    -
    Granule position value, analagous to the granpos field in an ogg_packet. -
    - - -

    Return Values

    -
    -
  • -0 returned on success. -1 returned in the event of internal error.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_stream_packetin.html b/ogg/doc/libogg/ogg_stream_packetin.html deleted file mode 100644 index bc05f52..0000000 --- a/ogg/doc/libogg/ogg_stream_packetin.html +++ /dev/null @@ -1,72 +0,0 @@ - - - -libogg - function - ogg_stream_packetin - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_packetin

    - -

    declared in "ogg/ogg.h";

    - -

    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.

    - -

    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 ogg_stream_state, so the caller -is free to alter the contents of op after this call has returned. - -

    - - - - -
    -
    
-int ogg_stream_packetin(ogg_stream_state *os,ogg_packet *op);
-
    -
    - -

    Parameters

    -
    -
    os
    -
    Pointer to a previously declared ogg_stream_state struct.
    -
    op
    -
    Pointer to the packet we are putting into the bitstream. -
    - - -

    Return Values

    -
    -
  • -0 returned on success. -1 returned in the event of internal error.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_stream_packetout.html b/ogg/doc/libogg/ogg_stream_packetout.html deleted file mode 100644 index 148f782..0000000 --- a/ogg/doc/libogg/ogg_stream_packetout.html +++ /dev/null @@ -1,85 +0,0 @@ - - - -libogg - function - ogg_stream_packetout - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_packetout

    - -

    declared in "ogg/ogg.h";

    - -

    This function assembles a data packet for output to the codec -decoding engine. The data has already been submitted to the -ogg_stream_state and broken -into segments. Each successive call returns the next complete packet -built from those segments.

    - -

    In a typical decoding situation, this should be used after calling -ogg_stream_pagein() 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.

    - -

    The op 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.

    - -

    - - - - -
    -
    
-int ogg_stream_packetout(ogg_stream_state *os,ogg_packet *op);
-
    -
    - -

    Parameters

    -
    -
    os
    -
    Pointer to a previously declared ogg_stream_state struct. Before this function is called, an ogg_page should be submitted to the stream using ogg_stream_pagein().
    -
    op
    -
    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.
    -
    - - -

    Return Values

    -
    -
      -
    • -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. op has not been updated.
      • -
    • 0 if there is insufficient data available to complete a packet, or on unrecoverable internal error occurred. op has not been updated. -
    • 1 if a packet was assembled normally. op contains the next packet from the stream.
      • -
    -
    - -

    - -
    - - - - - - - - - -

    copyright © 2000-2010 xiph.org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - diff --git a/ogg/doc/libogg/ogg_stream_packetpeek.html b/ogg/doc/libogg/ogg_stream_packetpeek.html deleted file mode 100644 index a6dc678..0000000 --- a/ogg/doc/libogg/ogg_stream_packetpeek.html +++ /dev/null @@ -1,85 +0,0 @@ - - - -libogg - function - ogg_stream_packetpeek - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_packetpeek

    - -

    declared in "ogg/ogg.h";

    - -

    This function attempts to assemble a raw data packet and returns -it without advancing decoding.

    - -

    In a typical situation, this would be called -speculatively after ogg_stream_pagein() 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 -ogg_stream_packetout().

    - -

    - - - - - -
    -
    
-int ogg_stream_packetpeek(ogg_stream_state *os,ogg_packet *op);
-
    -
    - -

    Parameters

    -
    -
    os
    -
    Pointer to a previously declared -ogg_stream_state struct. Before this -function is called, an ogg_page should be -submitted to the stream using -ogg_stream_pagein().
    -
    op
    -
    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.
    -
    - - -

    Return Values

    -
    -
      -
    • -1 if there's no packet available due to lost sync or a hole in the data.
      • -
    • 0 if there is insufficient data available to complete a packet, or on unrecoverable internal error occurred.
      • -
    • 1 if a packet is available.
      • -
    -
    - - -

    - -
    - - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_stream_pagein.html b/ogg/doc/libogg/ogg_stream_pagein.html deleted file mode 100644 index fddaed1..0000000 --- a/ogg/doc/libogg/ogg_stream_pagein.html +++ /dev/null @@ -1,67 +0,0 @@ - - - -libogg - function - ogg_stream_pagein - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_pagein

    - -

    declared in "ogg/ogg.h";

    - -

    This function adds a complete page to the bitstream. -

    In a typical decoding situation, this function would be called after using ogg_sync_pageout to create a valid ogg_page struct. -

    Internally, this function breaks the page into packet segments in preparation for outputting a valid packet to the codec decoding layer. - -

    - - - - -
    -
    
-int ogg_stream_pagein(ogg_stream_state *os, ogg_page *og);
-
    -
    - -

    Parameters

    -
    -
    os
    -
    Pointer to a previously declared ogg_stream_state struct, which represents the current logical bitstream.
    -
    og
    -
    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. -
    - - -

    Return Values

    -
    -
  • -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.
    • -
  • -0 means that the page was successfully submitted to the bitstream.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_stream_pageout.html b/ogg/doc/libogg/ogg_stream_pageout.html deleted file mode 100644 index 66139e3..0000000 --- a/ogg/doc/libogg/ogg_stream_pageout.html +++ /dev/null @@ -1,84 +0,0 @@ - - - -libogg - function - ogg_stream_pageout - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_pageout

    - -

    declared in "ogg/ogg.h";

    - -

    This function forms packets into pages.

    - -

    In a typical encoding situation, this would be called after using ogg_stream_packetin() 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.

    - -

    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 ogg_stream_flush() -if immediate page generation is desired. This may be occasionally -necessary, for example, to limit the temporal latency of a variable -bitrate stream.

    - -

    - - - - -
    -
    
-int ogg_stream_pageout(ogg_stream_state *os, ogg_page *og);
-
    -
    - -

    Parameters

    -
    -
    os
    -
    Pointer to a previously declared ogg_stream struct, which represents the current logical bitstream.
    -
    og
    -
    Pointer to an ogg_page 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().
    -
    - - -

    Return Values

    -
    -
  • Zero means that insufficient data has accumulated to fill a page, or an internal error occurred. In -this case og is not modified.
    • -
  • Non-zero means that a page has been completed and returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2010 xiph.org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_stream_pageout_fill.html b/ogg/doc/libogg/ogg_stream_pageout_fill.html deleted file mode 100644 index af95531..0000000 --- a/ogg/doc/libogg/ogg_stream_pageout_fill.html +++ /dev/null @@ -1,89 +0,0 @@ - - - -libogg - function - ogg_stream_pageout_fill - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_pageout_fill

    - -

    declared in "ogg/ogg.h";

    - -

    This function forms packets into pages, similar -to ogg_stream_pageout(), but -allows applications to explicitly request a specific page spill -size.

    - -

    In a typical encoding situation, this would be called after using ogg_stream_packetin() 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.

    - -

    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, and/or when the accumulated packet -data meets/exceeds the maximum page size regardless of accumulated -packet count. -Call ogg_stream_flush() or -ogg_stream_flush_fill() if -immediate page generation is desired regardless of accumulated data.

    - -

    - - - - -
    -
    
-int ogg_stream_pageout_fill(ogg_stream_state *os, ogg_page *og, int fillbytes);
-
    -
    - -

    Parameters

    -
    -
    os
    -
    Pointer to a previously declared ogg_stream struct, which represents the current logical bitstream.
    -
    og
    -
    Pointer to an ogg_page 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().
    -
    fillbytes
    -
    Packet data watermark in bytes.
    -
    - - -

    Return Values

    -
    -
  • Zero means that insufficient data has accumulated to fill a page, or an internal error occurred. In -this case og is not modified.
    • -
  • Non-zero means that a page has been completed and returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2010 xiph.org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_stream_reset.html b/ogg/doc/libogg/ogg_stream_reset.html deleted file mode 100644 index eb7ee36..0000000 --- a/ogg/doc/libogg/ogg_stream_reset.html +++ /dev/null @@ -1,61 +0,0 @@ - - - -libogg - function - ogg_stream_reset - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_reset

    - -

    declared in "ogg/ogg.h";

    - -

    This function sets values in the ogg_stream_state struct back to initial values. -

    - - - - -
    -
    
-int ogg_stream_reset(ogg_stream_state *os);
-
    -
    - -

    Parameters

    -
    -
    os
    -
    Pointer to the ogg_stream_state struct to be cleared.
    -
    - - -

    Return Values

    -
    -
  • -0 indicates success. nonzero is returned on internal error.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_stream_reset_serialno.html b/ogg/doc/libogg/ogg_stream_reset_serialno.html deleted file mode 100644 index 6805018..0000000 --- a/ogg/doc/libogg/ogg_stream_reset_serialno.html +++ /dev/null @@ -1,67 +0,0 @@ - - - -libogg - function - ogg_stream_reset_serialno - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_reset

    - -

    declared in "ogg/ogg.h";

    - -

    This function reinitializes the values in the -ogg_stream_state, -just like ogg_stream_reset(). -Additionally, it sets the stream serial number to the given value.

    - -

    - - - - -
    -
    
-int ogg_stream_reset_serialno(ogg_stream_state *os, int serialno);
-
    -
    - -

    Parameters

    -
    -
    os
    -
    Pointer to the ogg_stream_state struct to be cleared.
    -
    serialno
    -
    New stream serial number to use
    -
    - - -

    Return Values

    -
    -
  • -0 indicates success. nonzero is returned on internal error.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org Foundation

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_stream_state.html b/ogg/doc/libogg/ogg_stream_state.html deleted file mode 100644 index 6f42faf..0000000 --- a/ogg/doc/libogg/ogg_stream_state.html +++ /dev/null @@ -1,121 +0,0 @@ - - - -libogg - datatype - ogg_stream_state - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_stream_state

    - -

    declared in "ogg/ogg.h"

    - -

    -The ogg_stream_state struct tracks the current encode/decode state of the current logical bitstream. -

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

    Relevant Struct Members

    -
    -
    body_data
    -
    Pointer to data from packet bodies.
    -
    body_storage
    -
    Storage allocated for bodies in bytes (filled or unfilled).
    -
    body_fill
    -
    Amount of storage filled with stored packet bodies.
    -
    body_returned
    -
    Number of elements returned from storage.
    -
    lacing_vals
    -
    String of lacing values for the packet segments within the current page. Each value is a byte, indicating packet segment length.
    -
    granule_vals
    -
    Pointer to the lacing values for the packet segments within the current page.
    -
    lacing_storage
    -
    Total amount of storage (in bytes) allocated for storing lacing values.
    -
    lacing_fill
    -
    Fill marker for the current vs. total allocated storage of lacing values for the page.
    -
    lacing_packet
    -
    Lacing value for current packet segment.
    -
    lacing_returned
    -
    Number of lacing values returned from lacing_storage.
    -
    header
    -
    Temporary storage for page header during encode process, while the header is being created.
    -
    header_fill
    -
    Fill marker for header storage allocation. Used during the header creation process.
    -
    e_o_s
    -
    Marker set when the last packet of the logical bitstream has been buffered.
    -
    b_o_s
    -
    Marker set after we have written the first page in the logical bitstream.
    -
    serialno
    -
    Serial number of this logical bitstream.
    -
    pageno
    -
    Number of the current page within the stream.
    -
    packetno
    -
    Number of the current packet.
    -
    granulepos
    -
    Exact position of decoding/encoding process.
    -
    - - -

    -
    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - diff --git a/ogg/doc/libogg/ogg_sync_buffer.html b/ogg/doc/libogg/ogg_sync_buffer.html deleted file mode 100644 index be7915a..0000000 --- a/ogg/doc/libogg/ogg_sync_buffer.html +++ /dev/null @@ -1,67 +0,0 @@ - - - -libogg - function - ogg_sync_buffer - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_sync_buffer

    - -

    declared in "ogg/ogg.h";

    - -

    This function is used to provide a properly-sized buffer for writing. -

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

    The buffer exposed by this function is empty internal storage from the ogg_sync_state struct, beginning at the fill mark within the struct. -

    A pointer to this buffer is returned to be used by the calling application. - -

    - - - - -
    -
    
-char *ogg_sync_buffer(ogg_sync_state *oy, long size);
-
    -
    - -

    Parameters

    -
    -
    oy
    -
    Pointer to a previously declared ogg_sync_state struct.
    -
    size
    -
    Size of the desired buffer. The actual size of the buffer returned will be this size plus some extra bytes (currently 4096). -
    - - -

    Return Values

    -
    -
  • -Returns a pointer to the newly allocated buffer or NULL on error
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_sync_check.html b/ogg/doc/libogg/ogg_sync_check.html deleted file mode 100644 index daac330..0000000 --- a/ogg/doc/libogg/ogg_sync_check.html +++ /dev/null @@ -1,71 +0,0 @@ - - - -libogg - function - ogg_sync_check - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_sync_check

    - -

    declared in "ogg/ogg.h";

    - -

    This function is used to check the error or readiness condition of an ogg_sync_state structure. -

    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 ogg_sync_state structure will be cleared (equivalent to a -call to -ogg_sync_clear) and subsequent calls -using this ogg_sync_state will be -noops. Error detection is then handled via a single call to -ogg_sync_check at the end of the operational block.

    - -

    - - - - -
    -
    
-int ogg_sync_check(ogg_sync_state *oy);
-
    -
    - -

    Parameters

    -
    -
    oy
    -
    Pointer to a previously declared ogg_sync_state struct.
    -
    - - -

    Return Values

    -
    -
  • -0 is returned if the ogg_sync_state structure is initialized and ready.
    • -
  • -nonzero is returned if the structure was never initialized, or if an unrecoverable internal error occurred in a previous call using the passed in ogg_sync_state struct.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_sync_clear.html b/ogg/doc/libogg/ogg_sync_clear.html deleted file mode 100644 index 209317b..0000000 --- a/ogg/doc/libogg/ogg_sync_clear.html +++ /dev/null @@ -1,62 +0,0 @@ - - - -libogg - function - ogg_sync_clear - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_sync_clear

    - -

    declared in "ogg/ogg.h";

    - -

    This function is used to free the internal storage of an ogg_sync_state struct and resets the struct to the initial state. To free the entire struct, ogg_sync_destroy should be used instead. In situations where the struct needs to be reset but the internal storage does not need to be freed, ogg_sync_reset should be used. - -

    - - - - -
    -
    
-int ogg_sync_clear(ogg_sync_state *oy);
-
    -
    - -

    Parameters

    -
    -
    oy
    -
    Pointer to a previously declared ogg_sync_state struct.
    -
    - - -

    Return Values

    -
    -
  • -0 is always returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_sync_destroy.html b/ogg/doc/libogg/ogg_sync_destroy.html deleted file mode 100644 index 333faf3..0000000 --- a/ogg/doc/libogg/ogg_sync_destroy.html +++ /dev/null @@ -1,68 +0,0 @@ - - - -libogg - function - ogg_sync_destroy - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_sync_destroy

    - -

    declared in "ogg/ogg.h";

    - -

    This function is used to destroy an ogg_sync_state struct and free all memory used.

    - -

    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 ogg_sync_clear instead -to release just the internal memory.

    - -

    - - - - -
    -
    
-int ogg_sync_destroy(ogg_sync_state *oy);
-
    -
    - -

    Parameters

    -
    -
    oy
    -
    Pointer to a previously declared ogg_sync_state struct.
    -
    - - -

    Return Values

    -
    -
  • -0 is always returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_sync_init.html b/ogg/doc/libogg/ogg_sync_init.html deleted file mode 100644 index 590edc8..0000000 --- a/ogg/doc/libogg/ogg_sync_init.html +++ /dev/null @@ -1,63 +0,0 @@ - - - -libogg - function - ogg_sync_init - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_sync_init

    - -

    declared in "ogg/ogg.h";

    - -

    This function is used to initialize an ogg_sync_state struct to a known initial value in preparation for manipulation of an Ogg bitstream. -

    The ogg_sync struct is important when decoding, as it synchronizes retrieval and return of data. - -

    - - - - -
    -
    
-int ogg_sync_init(ogg_sync_state *oy);
-
    -
    - -

    Parameters

    -
    -
    oy
    -
    Pointer to a previously declared ogg_sync_state struct. After this function call, this struct has been initialized.
    -
    - - -

    Return Values

    -
    -
  • -0 is always returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_sync_pageout.html b/ogg/doc/libogg/ogg_sync_pageout.html deleted file mode 100644 index 5f3f24c..0000000 --- a/ogg/doc/libogg/ogg_sync_pageout.html +++ /dev/null @@ -1,77 +0,0 @@ - - - -libogg - function - ogg_sync_pageout - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_sync_pageout

    - -

    declared in "ogg/ogg.h";

    - -

    This function takes the data stored in the buffer of the ogg_sync_state struct and inserts them into an ogg_page. - -

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

    Caution: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. - -

    - - - - -
    -
    
-int ogg_sync_pageout(ogg_sync_state *oy, ogg_page *og);
-
    -
    - -

    Parameters

    -
    -
    oy
    -
    Pointer to a previously declared ogg_sync_state struct. Normally, the internal storage of this struct should be filled with newly read data and verified using ogg_sync_wrote.
    -
    og
    -
    Pointer to page struct filled by this function. -
    - - -

    Return Values

    -
    -
  • -1 returned if stream has not yet captured sync (bytes were skipped).
    • -
  • 0 returned if more data needed or an internal error occurred.
    • -
  • 1 indicated a page was synced and returned.
    • -
    -

    - -

    Example Usage

    -
    -if (ogg_sync_pageout(&oy, &og) != 1) {
-	buffer = ogg_sync_buffer(&oy, 8192);
-	bytes = fread(buffer, 1, 8192, stdin);
-	ogg_sync_wrote(&oy, bytes);
-}
-
    - -

    -
    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_sync_pageseek.html b/ogg/doc/libogg/ogg_sync_pageseek.html deleted file mode 100644 index b2efe89..0000000 --- a/ogg/doc/libogg/ogg_sync_pageseek.html +++ /dev/null @@ -1,68 +0,0 @@ - - - -libogg - function - ogg_sync_pageseek - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_sync_pageseek

    - -

    declared in "ogg/ogg.h";

    - -

    This function synchronizes the ogg_sync_state struct to the next ogg_page. -

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

    - - - - -
    -
    
-int ogg_sync_pageseek(ogg_sync_state *oy, ogg_page *og);
-
    -
    - -

    Parameters

    -
    -
    oy
    -
    Pointer to a previously declared ogg_sync_state struct.
    -
    og
    -
    Pointer to a page (or an incomplete page) of data. This is the page we are attempting to sync. -
    - - -

    Return Values

    -
    -
  • -n means that we skipped n bytes within the bitstream.
    • -
  • -0 means that the page isn't ready and we need more data, or than an internal error occurred. No bytes have been skipped.
    • -
  • -n means that the page was synced at the current location, with a page length of n bytes. -
    • -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_sync_reset.html b/ogg/doc/libogg/ogg_sync_reset.html deleted file mode 100644 index 12cd6c1..0000000 --- a/ogg/doc/libogg/ogg_sync_reset.html +++ /dev/null @@ -1,63 +0,0 @@ - - - -libogg - function - ogg_sync_reset - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_sync_reset

    - -

    declared in "ogg/ogg.h";

    - -

    This function is used to reset the internal counters of the ogg_sync_state struct to initial values. -

    It is a good idea to call this before seeking within a bitstream. - -

    - - - - -
    -
    
-int ogg_sync_reset(ogg_sync_state *oy);
-
    -
    - -

    Parameters

    -
    -
    oy
    -
    Pointer to a previously declared ogg_sync_state struct.
    -
    - - -

    Return Values

    -
    -
  • -0 is always returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/ogg_sync_state.html b/ogg/doc/libogg/ogg_sync_state.html deleted file mode 100644 index 78f8388..0000000 --- a/ogg/doc/libogg/ogg_sync_state.html +++ /dev/null @@ -1,77 +0,0 @@ - - - -libogg - datatype - ogg_sync_state - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_sync_state

    - -

    declared in "ogg/ogg.h"

    - -

    -The ogg_sync_state struct tracks the synchronization of the current page. -

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

    - - - - - -
    -
    
-typedef struct {
-  unsigned char *data;
-  int storage;
-  int fill;
-  int returned;
-
-  int unsynced;
-  int headerbytes;
-  int bodybytes;
-} ogg_sync_state;
-
    -
    - -

    Relevant Struct Members

    -
    -
    data
    -
    Pointer to buffered stream data.
    -
    storage
    -
    Current allocated size of the stream buffer held in *data.
    -
    fill
    -
    The number of valid bytes currently held in *data; functions as the buffer head pointer.
    -
    returned
    -
    The number of bytes at the head of *data that have already been returned as pages; functions as the buffer tail pointer.
    -
    unsynced
    -
    Synchronization state flag; nonzero if sync has not yet been attained or has been lost.
    -
    headerbytes
    -
    If synced, the number of bytes used by the synced page's header.
    -
    bodybytes
    -
    If synced, the number of bytes used by the synced page's body.
    -
    - - -

    -
    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - diff --git a/ogg/doc/libogg/ogg_sync_wrote.html b/ogg/doc/libogg/ogg_sync_wrote.html deleted file mode 100644 index 1825185..0000000 --- a/ogg/doc/libogg/ogg_sync_wrote.html +++ /dev/null @@ -1,73 +0,0 @@ - - - -libogg - function - ogg_sync_wrote - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    ogg_sync_wrote

    - -

    declared in "ogg/ogg.h";

    - -

    This function is used to tell the ogg_sync_state struct how many bytes we wrote into the buffer. - -

    -The general proceedure is to request a pointer into an internal -ogg_sync_state buffer by calling -ogg_sync_buffer(). 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.

    - -
    - - - - -
    -
    
-int ogg_sync_wrote(ogg_sync_state *oy, long bytes);
-
    -
    - -

    Parameters

    -
    -
    oy
    -
    Pointer to a previously declared ogg_sync_state struct.
    -
    bytes
    -
    Number of bytes of new data written.
    -
    - - -

    Return Values

    -
    -
  • -1 if the number of bytes written overflows the internal storage of the ogg_sync_state struct or an internal error occurred. -
  • -0 in all other cases.
    • -
    - - -

    -
    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_adv.html b/ogg/doc/libogg/oggpack_adv.html deleted file mode 100644 index 0e67b93..0000000 --- a/ogg/doc/libogg/oggpack_adv.html +++ /dev/null @@ -1,64 +0,0 @@ - - - -libogg - function - oggpack_adv - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_adv

    - -

    declared in "ogg/ogg.h";

    - -

    This function advances the location pointer by the specified number of bits without reading any data. - -

    - - - - -
    -
    
-void  oggpack_adv(oggpack_buffer *b,int bits);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    Pointer to the current oggpack_buffer.
    -
    bits
    -
    Number of bits to advance.
    -
    - - -

    Return Values

    -
    -
  • -No values are returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org Foundation

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_adv1.html b/ogg/doc/libogg/oggpack_adv1.html deleted file mode 100644 index 0b7dd89..0000000 --- a/ogg/doc/libogg/oggpack_adv1.html +++ /dev/null @@ -1,62 +0,0 @@ - - - -libogg - function - oggpack_adv1 - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_adv1

    - -

    declared in "ogg/ogg.h";

    - -

    This function advances the location pointer by one bit without reading any data. - -

    - - - - -
    -
    
-void  oggpack_adv1(oggpack_buffer *b);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    Pointer to the current oggpack_buffer.
    -
    - - -

    Return Values

    -
    -
  • No values are returned. -
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_bits.html b/ogg/doc/libogg/oggpack_bits.html deleted file mode 100644 index a31bd1b..0000000 --- a/ogg/doc/libogg/oggpack_bits.html +++ /dev/null @@ -1,62 +0,0 @@ - - - -libogg - function - oggpack_bits - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_bits

    - -

    declared in "ogg/ogg.h";

    - -

    This function returns the total number of bits currently in the oggpack_buffer's internal buffer. - -

    - - - - -
    -
    
-long oggpack_bits(oggpack_buffer *b);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    oggpack_buffer struct to be .
    -
    - - -

    Return Values

    -
    -
  • -n is the total number of bits within the current buffer.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_buffer.html b/ogg/doc/libogg/oggpack_buffer.html deleted file mode 100644 index 906cbf9..0000000 --- a/ogg/doc/libogg/oggpack_buffer.html +++ /dev/null @@ -1,66 +0,0 @@ - - - -libogg - datatype - oggpack_buffer - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_buffer

    - -

    declared in "ogg/ogg.h"

    - -

    -The oggpack_buffer struct is used with libogg's bitpacking functions. You should never need to directly access anything in this structure. -

    - - - - - -
    -
    
-typedef struct {
-  long endbyte;
-  int  endbit;
-
-  unsigned char *buffer;
-  unsigned char *ptr;
-  long storage;
-} oggpack_buffer;
-
    -
    - -

    Relevant Struct Members

    -
    -
    buffer
    -
    Pointer to data being manipulated.
    -
    ptr
    -
    Location pointer to mark which data has been read.
    -
    storage
    -
    Size of buffer. -
    - - -

    -
    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - diff --git a/ogg/doc/libogg/oggpack_bytes.html b/ogg/doc/libogg/oggpack_bytes.html deleted file mode 100644 index 4eb48fe..0000000 --- a/ogg/doc/libogg/oggpack_bytes.html +++ /dev/null @@ -1,67 +0,0 @@ - - - -libogg - function - oggpack_bytes - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_bytes

    - -

    declared in "ogg/ogg.h";

    - -

    This function returns the total number of bytes behind the current -access point in the oggpack_buffer. -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. -

    The return value is the number of complete bytes in the buffer. -There may be extra (<8) bits. -

    - - - - -
    -
    
-long oggpack_bytes(oggpack_buffer *b);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    oggpack_buffer struct to be checked.
    -
    - - -

    Return Values

    -
    -
  • -n is the total number of bytes within the current buffer.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2010 xiph.org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_get_buffer.html b/ogg/doc/libogg/oggpack_get_buffer.html deleted file mode 100644 index a4bfad2..0000000 --- a/ogg/doc/libogg/oggpack_get_buffer.html +++ /dev/null @@ -1,62 +0,0 @@ - - - -libogg - function - oggpack_get_buffer - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_get_buffer

    - -

    declared in "ogg/ogg.h";

    - -

    This function returns a pointer to the data buffer within the given oggpack_buffer struct. - -

    - - - - -
    -
    
-unsigned char *oggpack_get_buffer(oggpack_buffer *b);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    Pointer to the current oggpack_buffer.
    -
    - - -

    Return Values

    -
    -
  • -No values are returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_look.html b/ogg/doc/libogg/oggpack_look.html deleted file mode 100644 index 076eff3..0000000 --- a/ogg/doc/libogg/oggpack_look.html +++ /dev/null @@ -1,66 +0,0 @@ - - - -libogg - function - oggpack_look - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_look

    - -

    declared in "ogg/ogg.h";

    - -

    This function looks at a specified number of bits inside the buffer without advancing the location pointer. -

    The specified number of bits are read, starting from the location pointer. -

    This function can be used to read 32 or fewer bits. - -

    - - - - -
    -
    
-long  oggpack_look(oggpack_buffer *b,int bits);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    Pointer to oggpack_buffer to be read.
    -
    bits
    -
    Number of bits to look at. For this function, must be 32 or fewer.
    -
    - - -

    Return Values

    -
    -
  • -n represents the requested bits.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_look1.html b/ogg/doc/libogg/oggpack_look1.html deleted file mode 100644 index 5361164..0000000 --- a/ogg/doc/libogg/oggpack_look1.html +++ /dev/null @@ -1,63 +0,0 @@ - - - -libogg - function - oggpack_look1 - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_look1

    - -

    declared in "ogg/ogg.h";

    - -

    This function looks at the next bit without advancing the location pointer. -

    The next bit is read starting from the location pointer. - -

    - - - - -
    -
    
-long  oggpack_look1(oggpack_buffer *b);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    Pointer to an oggpack_buffer struct containing our buffer.
    -
    - - -

    Return Values

    -
    -
  • -n represents the value of the next bit after the location pointer.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_read.html b/ogg/doc/libogg/oggpack_read.html deleted file mode 100644 index a826916..0000000 --- a/ogg/doc/libogg/oggpack_read.html +++ /dev/null @@ -1,65 +0,0 @@ - - - -libogg - function - oggpack_read - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_read

    - -

    declared in "ogg/ogg.h";

    - -

    This function reads the requested number of bits from the buffer and advances the location pointer. -

    Before reading, the buffer should be initialized using oggpack_readinit. - -

    - - - - -
    -
    
-long oggpack_read(oggpack_buffer *b,int bits);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    Pointer to an oggpack_buffer struct containing buffered data to be read.
    -
    bits
    -
    Number of bits to read.
    -
    - - -

    Return Values

    -
    -
  • -n represents the requested bits.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_read1.html b/ogg/doc/libogg/oggpack_read1.html deleted file mode 100644 index 9a7e1cb..0000000 --- a/ogg/doc/libogg/oggpack_read1.html +++ /dev/null @@ -1,63 +0,0 @@ - - - -libogg - function - oggpack_read1 - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_read1

    - -

    declared in "ogg/ogg.h";

    - -

    This function reads one bit from the oggpack_buffer data buffer and advances the location pointer. -

    Before reading, the buffer should be initialized using oggpack_readinit. - -

    - - - - -
    -
    
-long  oggpack_read1(oggpack_buffer *b);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    Pointer to an oggpack_buffer struct containing buffered data to be read.
    -
    - - -

    Return Values

    -
    -
  • -n is the bit read by this function.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_readinit.html b/ogg/doc/libogg/oggpack_readinit.html deleted file mode 100644 index 6f27ee9..0000000 --- a/ogg/doc/libogg/oggpack_readinit.html +++ /dev/null @@ -1,64 +0,0 @@ - - - -libogg - function - oggpack_readinit - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_readinit

    - -

    declared in "ogg/ogg.h";

    - -

    This function takes an ordinary buffer and prepares an oggpack_buffer for reading using the Ogg bitpacking functions. - -

    - - - - -
    -
    
-void oggpack_readinit(oggpack_buffer *b,unsigned char *buf,int bytes);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    Pointer to oggpack_buffer to be initialized with some extra markers to ease bit navigation and manipulation.
    -
    buf
    -
    Original data buffer, to be inserted into the oggpack_buffer so that it can be read using bitpacking functions. -
    - - -

    Return Values

    -
    -
  • -No values are returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_reset.html b/ogg/doc/libogg/oggpack_reset.html deleted file mode 100644 index d9fedbc..0000000 --- a/ogg/doc/libogg/oggpack_reset.html +++ /dev/null @@ -1,62 +0,0 @@ - - - -libogg - function - oggpack_reset - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_reset

    - -

    declared in "ogg/ogg.h";

    - -

    This function resets the contents of an oggpack_buffer to their original state but does not free the memory used. - -

    - - - - -
    -
    
-void  oggpack_reset(oggpack_buffer *b);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    oggpack_buffer to be reset.
    -
    - - -

    Return Values

    -
    -
  • -No values are returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_write.html b/ogg/doc/libogg/oggpack_write.html deleted file mode 100644 index ad1d7ee..0000000 --- a/ogg/doc/libogg/oggpack_write.html +++ /dev/null @@ -1,68 +0,0 @@ - - - -libogg - function - oggpack_write - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_write

    - -

    declared in "ogg/ogg.h";

    - -

    This function writes bits into an oggpack_buffer. -

    The oggpack_buffer must already be initialized for writing using oggpack_writeinit. -

    Only 32 bits can be written at a time. - -

    - - - - -
    -
    
-void  oggpack_write(oggpack_buffer *b,unsigned long value,int bits);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    Buffer to be used for writing.
    -
    value
    -
    The data to be written into the buffer. This must be 32 bits or fewer.
    -
    bits
    -
    The number of bits being written into the buffer.
    -
    - - -

    Return Values

    -
    -
  • -No values are returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_writealign.html b/ogg/doc/libogg/oggpack_writealign.html deleted file mode 100644 index acedc2c..0000000 --- a/ogg/doc/libogg/oggpack_writealign.html +++ /dev/null @@ -1,65 +0,0 @@ - - - -libogg - function - oggpack_writealign - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_writealign

    - -

    declared in "ogg/ogg.h";

    - -

    This function pads the oggpack_buffer with zeros out to the -next byte boundary.

    -

    The oggpack_buffer must already be initialized for writing using oggpack_writeinit. -

    Only 32 bits can be written at a time.

    - -

    - - - - -
    -
    
-void  oggpack_writetrunc(oggpack_buffer *b);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    Buffer to be used for writing.
    -
    - - -

    Return Values

    -
    -
  • -No values are returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org Foundation

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_writecheck.html b/ogg/doc/libogg/oggpack_writecheck.html deleted file mode 100644 index e23131b..0000000 --- a/ogg/doc/libogg/oggpack_writecheck.html +++ /dev/null @@ -1,81 +0,0 @@ - - - -libogg - function - oggpack_writecheck - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_writecheck

    - -

    declared in "ogg/ogg.h";

    - -

    This function checks the readiness status of -an oggpack_buffer previously -initialized for writing using the -Ogg bitpacking 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 oggpack_writeclear() on a buffer that -has flagged an error and released its resources. - -

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

    - - - - -
    -
    
-int  oggpack_writecheck(oggpack_buffer *b);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    An oggpack_buffer previously initialized for writing.
    -
    - - -

    Return Values

    -
    -
  • zero: buffer is ready for writing
    • -
  • nonzero: buffer is not ready or encountered an error
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_writeclear.html b/ogg/doc/libogg/oggpack_writeclear.html deleted file mode 100644 index 5dadaa9..0000000 --- a/ogg/doc/libogg/oggpack_writeclear.html +++ /dev/null @@ -1,62 +0,0 @@ - - - -libogg - function - oggpack_reset - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_writeclear

    - -

    declared in "ogg/ogg.h";

    - -

    This function clears the buffer after writing and frees the memory used by the oggpack_buffer. - -

    - - - - -
    -
    
-void oggpack_writeclear(oggpack_buffer *b);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    Our oggpack_buffer. This is an ordinary data buffer with some extra markers to ease bit navigation and manipulation.
    -
    - - -

    Return Values

    -
    -
  • -No values are returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_writecopy.html b/ogg/doc/libogg/oggpack_writecopy.html deleted file mode 100644 index 94d3124..0000000 --- a/ogg/doc/libogg/oggpack_writecopy.html +++ /dev/null @@ -1,69 +0,0 @@ - - - -libogg - function - oggpack_writecopy - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_writecopy

    - -

    declared in "ogg/ogg.h";

    - -

    This function copies a sequence of bits from a source buffer into an -oggpack_buffer.

    -

    The oggpack_buffer must already be initialized for writing using oggpack_writeinit.

    -

    Only 32 bits can be written at a time.

    - -

    - - - - -
    -
    
-void  oggpack_writecopy(oggpack_buffer *b, void *source, long bits);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    Buffer to be used for writing.
    -
    source
    -
    A pointer to the data to be written into the buffer.
    -
    bits
    -
    The number of bits to be copied into the buffer.
    -
    - - -

    Return Values

    -
    -
  • -No values are returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org Foundation

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_writeinit.html b/ogg/doc/libogg/oggpack_writeinit.html deleted file mode 100644 index 7999b9c..0000000 --- a/ogg/doc/libogg/oggpack_writeinit.html +++ /dev/null @@ -1,62 +0,0 @@ - - - -libogg - function - oggpack_writeinit - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_writeinit

    - -

    declared in "ogg/ogg.h";

    - -

    This function initializes an oggpack_buffer for writing using the Ogg bitpacking functions. - -

    - - - - -
    -
    
-void  oggpack_writeinit(oggpack_buffer *b);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    Buffer to be used for writing. This is an ordinary data buffer with some extra markers to ease bit navigation and manipulation.
    -
    - - -

    Return Values

    -
    -
  • -No values are returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/oggpack_writetrunc.html b/ogg/doc/libogg/oggpack_writetrunc.html deleted file mode 100644 index bf23b2e..0000000 --- a/ogg/doc/libogg/oggpack_writetrunc.html +++ /dev/null @@ -1,65 +0,0 @@ - - - -libogg - function - oggpack_writetrunc - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    oggpack_writetrunc

    - -

    declared in "ogg/ogg.h";

    - -

    This function truncates an already written-to oggpack_buffer.

    -

    The oggpack_buffer must already be initialized for writing using oggpack_writeinit.

    - -

    - - - - -
    -
    
-void  oggpack_writetrunc(oggpack_buffer *b, long bits);
-
    -
    - -

    Parameters

    -
    -
    b
    -
    Buffer to be truncated.
    -
    bits
    -
    Number of bits to keep in the buffer (size after truncation)
    -
    - - -

    Return Values

    -
    -
  • -No values are returned.
    • -
    -

    - -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org Foundation

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - - diff --git a/ogg/doc/libogg/overview.html b/ogg/doc/libogg/overview.html deleted file mode 100644 index 347ebeb..0000000 --- a/ogg/doc/libogg/overview.html +++ /dev/null @@ -1,44 +0,0 @@ - - - -libogg - API Overview - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    Libogg API Overview

    - -

    -The libogg API consists of the following functional categories: -

    -

    - -

    -
    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - diff --git a/ogg/doc/libogg/reference.html b/ogg/doc/libogg/reference.html deleted file mode 100644 index cfe1608..0000000 --- a/ogg/doc/libogg/reference.html +++ /dev/null @@ -1,98 +0,0 @@ - - - -Libogg API Reference - - - - - - - - - -

    libogg documentation

    libogg release 1.3.2 - 20140527

    - -

    Libogg API Reference

    - -

    -Data Structures
    -oggpack_buffer
    -ogg_page
    -ogg_stream_state
    -ogg_packet
    -ogg_sync_state
    -
    -Bitpacking
    -oggpack_writeinit()
    -oggpack_writecheck()
    -oggpack_reset()
    -oggpack_writetrunc()
    -oggpack_writealign()
    -oggpack_writecopy()
    -oggpack_writeclear()
    -oggpack_readinit()
    -oggpack_write()
    -oggpack_look()
    -oggpack_look1()
    -oggpack_adv()
    -oggpack_adv1()
    -oggpack_read()
    -oggpack_read1()
    -oggpack_bytes()
    -oggpack_bits()
    -oggpack_get_buffer()
    -
    -Decoding-Related
    -ogg_sync_init()
    -ogg_sync_check()
    -ogg_sync_clear()
    -ogg_sync_destroy()
    -ogg_sync_reset()
    -ogg_sync_buffer()
    -ogg_sync_wrote()
    -ogg_sync_pageseek()
    -ogg_sync_pageout()
    -ogg_stream_pagein()
    -ogg_stream_packetout()
    -ogg_stream_packetpeek()
    -
    -Encoding-Related
    -ogg_stream_packetin()
    -ogg_stream_pageout()
    -ogg_stream_pageout_fill()
    -ogg_stream_flush()
    -ogg_stream_flush_fill()
    -
    -General
    -ogg_stream_init()
    -ogg_stream_check()
    -ogg_stream_clear()
    -ogg_stream_reset()
    -ogg_stream_reset_serialno()
    -ogg_stream_destroy()
    -ogg_page_version()
    -ogg_page_continued()
    -ogg_page_packets()
    -ogg_page_bos()
    -ogg_page_eos()
    -ogg_page_granulepos()
    -ogg_page_serialno()
    -ogg_page_pageno()
    -ogg_packet_clear()
    -ogg_page_checksum_set()
    -

    -

    - - - - - - - - -

    copyright © 2000-2014 Xiph.Org Foundation

    Ogg Container Format

    libogg documentation

    libogg release 1.3.2 - 20140527

    - - - - diff --git a/ogg/doc/libogg/style.css b/ogg/doc/libogg/style.css deleted file mode 100644 index 81cf417..0000000 --- a/ogg/doc/libogg/style.css +++ /dev/null @@ -1,7 +0,0 @@ -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 } diff --git a/ogg/doc/multiplex1.png b/ogg/doc/multiplex1.png deleted file mode 100644 index e48d1dd..0000000 Binary files a/ogg/doc/multiplex1.png and /dev/null differ diff --git a/ogg/doc/multiplex1.svg b/ogg/doc/multiplex1.svg deleted file mode 100644 index 46e6d52..0000000 --- a/ogg/doc/multiplex1.svg +++ /dev/null @@ -1,632 +0,0 @@ - - - - - - - - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - - - - - elementary physical bitstream A - logical bitstream A - OggS - OggS - OggS - OggS - OggS - OggS - - - - - - - - - - - - - elementary physical bitstream B - logical bitstream B - OggS - OggS - OggS - OggS - OggS - OggS - - - - - - - - - - - - - - - multiplexed physical bitstream - - - - - - - - - - OggS - OggS - OggS - OggS - OggS - OggS - - diff --git a/ogg/doc/ogg-multiplex.html b/ogg/doc/ogg-multiplex.html deleted file mode 100644 index bd08e25..0000000 --- a/ogg/doc/ogg-multiplex.html +++ /dev/null @@ -1,446 +0,0 @@ - - - - - -Ogg Documentation - - - - - - - - - -

    Page Multiplexing and Ordering in a Physical Ogg Stream

    - -

    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.

    - -

    Design Elements

    - -

    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.

    - -

    Linear media

    - -

    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.

    - -

    Multiplexing

    - -

    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.

    - -

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

    - -

    Seeking

    - -

    Ogg is designed to use an interpolated bisection search to -implement exact positional seeking. Interpolated bisection search is -a spec-mandated mechanism.

    - -

    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.

    - -

    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.

    - -

    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.

    - -

    Continuous and Discontinuous Streams

    - -

    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.

    - -

    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.

    - -

    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.

    - -

    The fundamental design distinction between continuous and -discontinuous streams concerns buffering.

    - -

    Buffering

    - -

    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.

    - -

    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.

    - -

    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.

    - -

    Further details, mechanisms and reasons for the differing arrangement -and behavior of continuous and discontinuous streams is discussed -later.

    - -

    Whole-stream navigation

    - -

    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.

    - -

    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.

    - -

    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.

    - -

    Granule Position

    - -

    Description

    - -

    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.

    - -

    The granule position is governed by the following rules:

    - -
      - -
    • 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. (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.)
      • - -
    • 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).
      • - -
    • 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.
      • - -
    • 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.
      • - -
    - -

    Example: timestamp

    - -

    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.

    - -

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

    - -

    Example: framestamp

    - -

    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.

    - -

    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 [granule_position] * -[samples_per_frame] / [samples_per_second].

    - -

    Example: samplestamp (Vorbis)

    - -

    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 [granule_position] / -[samples_per_second].

    - -

    Example: bit-divided framestamp (Theora)

    - -

    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:

    - -
      - -
    • 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 -<.015, .035, .055...> as at <.00, .02, .04...>.
      • - -
    • frame rates often include drop-frames, leap-frames or other -rational-but-non-integer timings.
      • - -
    • Decode must begin at a 'key frame' or 'I frame'. Keyframes usually -occur relatively seldom.
      • - -
    - -

    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.

    - -

    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.

    - -

    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.

    - -

    granule position, packets and pages

    - -

    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.

    - -

    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.

    - -

    start-time and end-time positioning

    - -

    A granule position represents the instantaneous time location -between two pages. 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.

    - -

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

    - -

    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.

    - -

    Multiplex/Demultiplex Division of Labor

    - -

    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.

    - -

    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.

    - -

    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.

    - -

    Unsorted Discussion Points

    - -

    flushes around key frames? RFC suggestion: repaginating or building a -stream this way is nice but not required

    - -

    Appendix A: multiplexing examples

    - - - - - diff --git a/ogg/doc/oggstream.html b/ogg/doc/oggstream.html deleted file mode 100644 index 71bbce7..0000000 --- a/ogg/doc/oggstream.html +++ /dev/null @@ -1,594 +0,0 @@ - - - - - -Ogg Documentation - - - - - - -
    - - - -

    Ogg bitstream overview

    - -

    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 index page -give distilled technical descriptions and references of the container -mechanisms. This document is intended to aid understanding. - -

    Container format design points

    - -

    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 Skeleton or Annodex/CMML). - -

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

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

    Streaming

    - -

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

    Variable Bit Rate, Variable Payload Size

    - -

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

    Simple pagination

    - -

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

    Capture

    - -

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

    Seeking

    - -

    Ogg implements simple coarse- and fine-grained seeking by design. - -

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

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

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

    Seeking without use of an index is a major point of the Ogg -design. There two primary reasons why Ogg transport forgoes an index: - -

      - -
    1. 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. - -
    2. '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. - -
    - -

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

    All this said, it's become clear that an optional index is a -demanded feature. For this reason, the OggSkeleton now defines a -proposed index. - -

    Simple multiplexing

    - -

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

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

    Continuous and Discontinuous Media

    - -

    Ogg streams belong to one of two categories, "Continuous" streams and -"Discontinuous" streams. - -

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

    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 Ogg Kate. 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. - -

    The fundamental reason for distinction between continuous and -discontinuous streams concerns buffering. - -

    Buffering

    - -

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

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

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

    Codec metadata

    - -

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

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

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

    Stream structure metadata

    - -

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

    Frame accurate absolute position

    - -

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

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

    Ogg stream arrangement

    - -

    Packets, pages, and bitstreams

    - -

    Ogg codecs place raw compressed data into packets. -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 logical -bitstream of codec data with no internal landmarks. - -

    - - -

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

    - -

    Logical bitstream packets are grouped and framed into Ogg pages -along with a unique stream serial number to produce a -physical bitstream. An elementary stream 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. - -

    - - -

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

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

    - - -

    Ogg Bitstream Framing specifies -the page format of an Ogg bitstream, the packet coding process -and elementary bitstreams in detail. - -

    Multiplexed bitstreams

    - -

    Multiple logical/elementary bitstreams can be combined into a single -multiplexed bitstream 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 Ogg Skeleton) 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. - -

    - - -

    Multiple media types are mutliplexed into a single Ogg stream by -interleaving the pages from each elementary physical stream. - -

    - -

    Ogg Bitstream Multiplexing specifies -proper multiplexing of an Ogg bitstream in detail. - -

    Chaining

    - -

    Multiple Ogg physical bitstreams may be concatenated into a single new -stream; this is chaining. The bitstreams do not overlap; the -final page of a given logical bitstream is immediately followed by the -initial page of the next.

    - -

    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 link or segment of the chain.

    - -

    Continuous and discontinuous streams

    - -

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

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

    Multiplexing Requirements

    - -

    Multiplexing requirements within Ogg are straightforward. When -constructing a single-link (unchained) physical bitstream consisting -of multiple elementary streams: - -

      - -

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

    2. All auxiliary headers for all streams must follow. Order -is unspecified. The final auxiliary header of each stream must flush -its page. - -

    3. Data pages for each stream follow, interleaved in time order. - -

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

    - -

    Each grouped bitstream must have a unique serial number within the -scope of the physical bitstream.

    - -

    chaining and multiplexing

    - -

    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.

    - -

    Codec Mapping Requirements

    - -

    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 mapping. Ogg imposes a few mapping requirements -on any codec. - -

      - -

    1. The framing specification 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.

      - -

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

      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.

      - -

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

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

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

    6. Packets and pages must be arranged in ascending -granule-position and time order. - -

    - -

    Examples

    - -[More to come shortly; this section is currently being revised and expanded] - -

    Below, we present an example of a multiplexed and chained bitstream:

    - -

    stream

    - -

    In this example, we see pages from five total logical bitstreams -multiplexed into a physical bitstream. Note the following -characteristics:

    - -
      -
    1. 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.
      2. - -
    2. 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.
      3. -
    - - - -
    - - diff --git a/ogg/doc/packets.png b/ogg/doc/packets.png deleted file mode 100644 index 917b6c1..0000000 Binary files a/ogg/doc/packets.png and /dev/null differ diff --git a/ogg/doc/packets.svg b/ogg/doc/packets.svg deleted file mode 100644 index 6b426c7..0000000 --- a/ogg/doc/packets.svg +++ /dev/null @@ -1,876 +0,0 @@ - - - - - - - - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - - - - - - - - - - - - - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - - - - - - - - - - - - - - - - - - - - - - - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - - packet stream - unframed logical bitstream - - diff --git a/ogg/doc/pages.png b/ogg/doc/pages.png deleted file mode 100644 index b4b431e..0000000 Binary files a/ogg/doc/pages.png and /dev/null differ diff --git a/ogg/doc/pages.svg b/ogg/doc/pages.svg deleted file mode 100644 index 436849c..0000000 --- a/ogg/doc/pages.svg +++ /dev/null @@ -1,1219 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - image/svg+xml - - - - - - - - - - - - - - OggS - OggS - OggS - - - - - - - - - - - - - - - 23 - 24 - 25 - - ... - ... - physical bitstream - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - framed logical bitstream - - - - - - - - - - - - - - - - - - - - - - - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - packet - - - diff --git a/ogg/doc/rfc3533.txt b/ogg/doc/rfc3533.txt deleted file mode 100644 index f2fcd1a..0000000 --- a/ogg/doc/rfc3533.txt +++ /dev/null @@ -1,843 +0,0 @@ - - - - - - -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] - diff --git a/ogg/doc/rfc3534.txt b/ogg/doc/rfc3534.txt deleted file mode 100644 index 840f1ec..0000000 --- a/ogg/doc/rfc3534.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -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 - . Technical questions about the Ogg bitstream - standard may be asked on the mailing lists for the developer - community. - - 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 . - 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] - diff --git a/ogg/doc/rfc5334.txt b/ogg/doc/rfc5334.txt deleted file mode 100644 index fea91fb..0000000 --- a/ogg/doc/rfc5334.txt +++ /dev/null @@ -1,787 +0,0 @@ - - - - - - -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, - . - - [Dirac] Dirac Group, "Dirac Specification", - . - - [FLAC] Coalson, J., "The FLAC Format", - . - - [libogg] Xiph.Org Foundation, "The libogg API", June 2000, - . - - [Ogg] Xiph.Org Foundation, "Ogg bitstream documentation: Ogg - logical and physical bitstream overview, Ogg logical - bitstream framing, Ogg multi-stream multiplexing", - . - - [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, - . - - [Speex] Valin, J., "The Speex Codec Manual", February 2002, - . - - [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, . - - [ThRTP] Barbato, L., "RTP Payload Format for Theora Encoded - Video", Work in Progress, June 2006. - - [Vorbis] Xiph.Org Foundation, "Vorbis I Specification", July 2004, - . - - - - - - - - - - - - - - - - - - - - - - -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] - diff --git a/ogg/doc/skeleton.html b/ogg/doc/skeleton.html deleted file mode 100755 index 8b29c18..0000000 --- a/ogg/doc/skeleton.html +++ /dev/null @@ -1,222 +0,0 @@ - - - - - -The Ogg Skeleton Metadata Bitstream - - - - - - - - - -

    The Ogg Skeleton Metadata Bitstream

    - -

    Overview

    - -

    Ogg Skeleton provides structuring information for multitrack Ogg files. It is compatible with Ogg Theora and provides extra clues for synchronization and content negotiation such as language selection.

    - -

    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.

    - -

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

    - -

    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.

    - -

    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

    - -

    Specification

    - -

    How to describe the logical bitstreams within an Ogg container?

    - -

    The following information about a logical bitstream is of interest to contain as meta information in the Skeleton:

    -
      -
    • the serial number: it identifies a content track
      • -
    • the mime type: it identifies the content type
      • -
    • other generic name-value fields that can provide meta information such as the language of a track or the video height and width
      • -
    • the number of header packets: this informs a parser about the number of actual header packets in an Ogg logical bitstream
      • -
    • 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"
      • -
    • 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)
      • -
    • 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)
      • -
    • 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
      • -
    • 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
      • -
    - -

    How to allow the creation of substreams from an Ogg physical bitstream?

    - -

    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.

    - -

    The following information is necessary to be added to the Skeleton to allow a correct presentation of a subpart of an Ogg bitstream:

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

    Ogg Skeleton version 3.0 Format Specification

    - -

    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.

    - -

    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.

    - -

    The fishead ident header looks as follows:

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

    The version fields provide version information for the Skeleton track, currently being 3.0 (the number having evolved within the Annodex project).

    - -

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

    - -

    The fisbone secondary header packet looks as follows:

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

    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.

    - -

    The granule rate is again given as a rational number in the same way that presentation time and basetime were provided above.

    - -

    A further restriction on how to encapsulate Skeleton into Ogg is proposed to allow for easier parsing:

    -
      -
    • there can only be one Skeleton logical bitstream in a Ogg bitstream
      • -
    • 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
      • -
    • the bos pages of all the other logical bistreams come next (a requirement of Ogg)
      • -
    • the secondary header pages of all logical bitstreams come next, including Skeleton's secondary header packets
      • -
    • the Skeleton eos page end the control section of the Ogg stream before any content pages of any of the other logical bitstreams appear
      • -
    - - - - - \ No newline at end of file diff --git a/ogg/doc/stream.png b/ogg/doc/stream.png deleted file mode 100644 index ce2d2da..0000000 Binary files a/ogg/doc/stream.png and /dev/null differ diff --git a/ogg/doc/vorbisword2.png b/ogg/doc/vorbisword2.png deleted file mode 100644 index 12e3d31..0000000 Binary files a/ogg/doc/vorbisword2.png and /dev/null differ diff --git a/ogg/doc/white-ogg.png b/ogg/doc/white-ogg.png deleted file mode 100644 index 2694296..0000000 Binary files a/ogg/doc/white-ogg.png and /dev/null differ diff --git a/ogg/doc/white-xifish.png b/ogg/doc/white-xifish.png deleted file mode 100644 index ab25cc8..0000000 Binary files a/ogg/doc/white-xifish.png and /dev/null differ diff --git a/ogg/include/Makefile.am b/ogg/include/Makefile.am deleted file mode 100644 index 0084e4d..0000000 --- a/ogg/include/Makefile.am +++ /dev/null @@ -1,3 +0,0 @@ -## Process this file with automake to produce Makefile.in - -SUBDIRS = ogg diff --git a/ogg/include/ogg/Makefile.am b/ogg/include/ogg/Makefile.am deleted file mode 100644 index 142699d..0000000 --- a/ogg/include/ogg/Makefile.am +++ /dev/null @@ -1,6 +0,0 @@ -## Process this file with automake to produce Makefile.in - -oggincludedir = $(includedir)/ogg - -ogginclude_HEADERS = ogg.h os_types.h -nodist_ogginclude_HEADERS = config_types.h diff --git a/ogg/include/ogg/config_types.h.in b/ogg/include/ogg/config_types.h.in deleted file mode 100644 index 750e29d..0000000 --- a/ogg/include/ogg/config_types.h.in +++ /dev/null @@ -1,25 +0,0 @@ -#ifndef __CONFIG_TYPES_H__ -#define __CONFIG_TYPES_H__ - -/* these are filled in by configure */ -#define INCLUDE_INTTYPES_H @INCLUDE_INTTYPES_H@ -#define INCLUDE_STDINT_H @INCLUDE_STDINT_H@ -#define INCLUDE_SYS_TYPES_H @INCLUDE_SYS_TYPES_H@ - -#if INCLUDE_INTTYPES_H -# include -#endif -#if INCLUDE_STDINT_H -# include -#endif -#if INCLUDE_SYS_TYPES_H -# include -#endif - -typedef @SIZE16@ ogg_int16_t; -typedef @USIZE16@ ogg_uint16_t; -typedef @SIZE32@ ogg_int32_t; -typedef @USIZE32@ ogg_uint32_t; -typedef @SIZE64@ ogg_int64_t; - -#endif diff --git a/ogg/include/ogg/ogg.h b/ogg/include/ogg/ogg.h deleted file mode 100644 index 7609fc2..0000000 --- a/ogg/include/ogg/ogg.h +++ /dev/null @@ -1,210 +0,0 @@ -/******************************************************************** - * * - * 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 (C) COPYRIGHT 1994-2007 * - * by the Xiph.Org Foundation http://www.xiph.org/ * - * * - ******************************************************************** - - function: toplevel libogg include - last mod: $Id$ - - ********************************************************************/ -#ifndef _OGG_H -#define _OGG_H - -#ifdef __cplusplus -extern "C" { -#endif - -#include -#include - -typedef struct { - void *iov_base; - size_t iov_len; -} ogg_iovec_t; - -typedef struct { - long endbyte; - int endbit; - - unsigned char *buffer; - unsigned char *ptr; - long storage; -} oggpack_buffer; - -/* ogg_page is used to encapsulate the data in one Ogg bitstream page *****/ - -typedef struct { - unsigned char *header; - long header_len; - unsigned char *body; - long body_len; -} ogg_page; - -/* ogg_stream_state contains the current encode/decode state of a logical - Ogg bitstream **********************************************************/ - -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; - long 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 separate abstraction - layer) also knows about the gap */ - ogg_int64_t granulepos; - -} ogg_stream_state; - -/* ogg_packet is used to encapsulate the data and metadata belonging - to a single raw Ogg/Vorbis packet *************************************/ - -typedef struct { - unsigned char *packet; - long bytes; - long b_o_s; - long e_o_s; - - ogg_int64_t granulepos; - - 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 separate abstraction - layer) also knows about the gap */ -} ogg_packet; - -typedef struct { - unsigned char *data; - int storage; - int fill; - int returned; - - int unsynced; - int headerbytes; - int bodybytes; -} ogg_sync_state; - -/* Ogg BITSTREAM PRIMITIVES: bitstream ************************/ - -extern void oggpack_writeinit(oggpack_buffer *b); -extern int oggpack_writecheck(oggpack_buffer *b); -extern void oggpack_writetrunc(oggpack_buffer *b,long bits); -extern void oggpack_writealign(oggpack_buffer *b); -extern void oggpack_writecopy(oggpack_buffer *b,void *source,long bits); -extern void oggpack_reset(oggpack_buffer *b); -extern void oggpack_writeclear(oggpack_buffer *b); -extern void oggpack_readinit(oggpack_buffer *b,unsigned char *buf,int bytes); -extern void oggpack_write(oggpack_buffer *b,unsigned long value,int bits); -extern long oggpack_look(oggpack_buffer *b,int bits); -extern long oggpack_look1(oggpack_buffer *b); -extern void oggpack_adv(oggpack_buffer *b,int bits); -extern void oggpack_adv1(oggpack_buffer *b); -extern long oggpack_read(oggpack_buffer *b,int bits); -extern long oggpack_read1(oggpack_buffer *b); -extern long oggpack_bytes(oggpack_buffer *b); -extern long oggpack_bits(oggpack_buffer *b); -extern unsigned char *oggpack_get_buffer(oggpack_buffer *b); - -extern void oggpackB_writeinit(oggpack_buffer *b); -extern int oggpackB_writecheck(oggpack_buffer *b); -extern void oggpackB_writetrunc(oggpack_buffer *b,long bits); -extern void oggpackB_writealign(oggpack_buffer *b); -extern void oggpackB_writecopy(oggpack_buffer *b,void *source,long bits); -extern void oggpackB_reset(oggpack_buffer *b); -extern void oggpackB_writeclear(oggpack_buffer *b); -extern void oggpackB_readinit(oggpack_buffer *b,unsigned char *buf,int bytes); -extern void oggpackB_write(oggpack_buffer *b,unsigned long value,int bits); -extern long oggpackB_look(oggpack_buffer *b,int bits); -extern long oggpackB_look1(oggpack_buffer *b); -extern void oggpackB_adv(oggpack_buffer *b,int bits); -extern void oggpackB_adv1(oggpack_buffer *b); -extern long oggpackB_read(oggpack_buffer *b,int bits); -extern long oggpackB_read1(oggpack_buffer *b); -extern long oggpackB_bytes(oggpack_buffer *b); -extern long oggpackB_bits(oggpack_buffer *b); -extern unsigned char *oggpackB_get_buffer(oggpack_buffer *b); - -/* Ogg BITSTREAM PRIMITIVES: encoding **************************/ - -extern int ogg_stream_packetin(ogg_stream_state *os, ogg_packet *op); -extern int ogg_stream_iovecin(ogg_stream_state *os, ogg_iovec_t *iov, - int count, long e_o_s, ogg_int64_t granulepos); -extern int ogg_stream_pageout(ogg_stream_state *os, ogg_page *og); -extern int ogg_stream_pageout_fill(ogg_stream_state *os, ogg_page *og, int nfill); -extern int ogg_stream_flush(ogg_stream_state *os, ogg_page *og); -extern int ogg_stream_flush_fill(ogg_stream_state *os, ogg_page *og, int nfill); - -/* Ogg BITSTREAM PRIMITIVES: decoding **************************/ - -extern int ogg_sync_init(ogg_sync_state *oy); -extern int ogg_sync_clear(ogg_sync_state *oy); -extern int ogg_sync_reset(ogg_sync_state *oy); -extern int ogg_sync_destroy(ogg_sync_state *oy); -extern int ogg_sync_check(ogg_sync_state *oy); - -extern char *ogg_sync_buffer(ogg_sync_state *oy, long size); -extern int ogg_sync_wrote(ogg_sync_state *oy, long bytes); -extern long ogg_sync_pageseek(ogg_sync_state *oy,ogg_page *og); -extern int ogg_sync_pageout(ogg_sync_state *oy, ogg_page *og); -extern int ogg_stream_pagein(ogg_stream_state *os, ogg_page *og); -extern int ogg_stream_packetout(ogg_stream_state *os,ogg_packet *op); -extern int ogg_stream_packetpeek(ogg_stream_state *os,ogg_packet *op); - -/* Ogg BITSTREAM PRIMITIVES: general ***************************/ - -extern int ogg_stream_init(ogg_stream_state *os,int serialno); -extern int ogg_stream_clear(ogg_stream_state *os); -extern int ogg_stream_reset(ogg_stream_state *os); -extern int ogg_stream_reset_serialno(ogg_stream_state *os,int serialno); -extern int ogg_stream_destroy(ogg_stream_state *os); -extern int ogg_stream_check(ogg_stream_state *os); -extern int ogg_stream_eos(ogg_stream_state *os); - -extern void ogg_page_checksum_set(ogg_page *og); - -extern int ogg_page_version(const ogg_page *og); -extern int ogg_page_continued(const ogg_page *og); -extern int ogg_page_bos(const ogg_page *og); -extern int ogg_page_eos(const ogg_page *og); -extern ogg_int64_t ogg_page_granulepos(const ogg_page *og); -extern int ogg_page_serialno(const ogg_page *og); -extern long ogg_page_pageno(const ogg_page *og); -extern int ogg_page_packets(const ogg_page *og); - -extern void ogg_packet_clear(ogg_packet *op); - - -#ifdef __cplusplus -} -#endif - -#endif /* _OGG_H */ diff --git a/ogg/include/ogg/os_types.h b/ogg/include/ogg/os_types.h deleted file mode 100644 index b8f5630..0000000 --- a/ogg/include/ogg/os_types.h +++ /dev/null @@ -1,148 +0,0 @@ -/******************************************************************** - * * - * 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 (C) COPYRIGHT 1994-2002 * - * by the Xiph.Org Foundation http://www.xiph.org/ * - * * - ******************************************************************** - - function: #ifdef jail to whip a few platforms into the UNIX ideal. - last mod: $Id$ - - ********************************************************************/ -#ifndef _OS_TYPES_H -#define _OS_TYPES_H - -/* make it easy on the folks that want to compile the libs with a - different malloc than stdlib */ -#define _ogg_malloc malloc -#define _ogg_calloc calloc -#define _ogg_realloc realloc -#define _ogg_free free - -#if defined(_WIN32) - -# if defined(__CYGWIN__) -# include - typedef int16_t ogg_int16_t; - typedef uint16_t ogg_uint16_t; - typedef int32_t ogg_int32_t; - typedef uint32_t ogg_uint32_t; - typedef int64_t ogg_int64_t; - typedef uint64_t ogg_uint64_t; -# elif defined(__MINGW32__) -# include - typedef short ogg_int16_t; - typedef unsigned short ogg_uint16_t; - typedef int ogg_int32_t; - typedef unsigned int ogg_uint32_t; - typedef long long ogg_int64_t; - typedef unsigned long long ogg_uint64_t; -# elif defined(__MWERKS__) - typedef long long ogg_int64_t; - typedef int ogg_int32_t; - typedef unsigned int ogg_uint32_t; - typedef short ogg_int16_t; - typedef unsigned short ogg_uint16_t; -# else -# if defined(_MSC_VER) && (_MSC_VER >= 1800) /* MSVC 2013 and newer */ -# include - typedef int16_t ogg_int16_t; - typedef uint16_t ogg_uint16_t; - typedef int32_t ogg_int32_t; - typedef uint32_t ogg_uint32_t; - typedef int64_t ogg_int64_t; - typedef uint64_t ogg_uint64_t; -# else - /* MSVC/Borland */ - typedef __int64 ogg_int64_t; - typedef __int32 ogg_int32_t; - typedef unsigned __int32 ogg_uint32_t; - typedef __int16 ogg_int16_t; - typedef unsigned __int16 ogg_uint16_t; -# endif -# endif - -#elif (defined(__APPLE__) && defined(__MACH__)) /* MacOS X Framework build */ - -# include - typedef int16_t ogg_int16_t; - typedef uint16_t ogg_uint16_t; - typedef int32_t ogg_int32_t; - typedef uint32_t ogg_uint32_t; - typedef int64_t ogg_int64_t; - -#elif defined(__HAIKU__) - - /* Haiku */ -# include - typedef short ogg_int16_t; - typedef unsigned short ogg_uint16_t; - typedef int ogg_int32_t; - typedef unsigned int ogg_uint32_t; - typedef long long ogg_int64_t; - -#elif defined(__BEOS__) - - /* Be */ -# include - typedef int16_t ogg_int16_t; - typedef uint16_t ogg_uint16_t; - typedef int32_t ogg_int32_t; - typedef uint32_t ogg_uint32_t; - typedef int64_t ogg_int64_t; - -#elif defined (__EMX__) - - /* OS/2 GCC */ - typedef short ogg_int16_t; - typedef unsigned short ogg_uint16_t; - typedef int ogg_int32_t; - typedef unsigned int ogg_uint32_t; - typedef long long ogg_int64_t; - -#elif defined (DJGPP) - - /* DJGPP */ - typedef short ogg_int16_t; - typedef int ogg_int32_t; - typedef unsigned int ogg_uint32_t; - typedef long long ogg_int64_t; - -#elif defined(R5900) - - /* PS2 EE */ - typedef long ogg_int64_t; - typedef int ogg_int32_t; - typedef unsigned ogg_uint32_t; - typedef short ogg_int16_t; - -#elif defined(__SYMBIAN32__) - - /* Symbian GCC */ - typedef signed short ogg_int16_t; - typedef unsigned short ogg_uint16_t; - typedef signed int ogg_int32_t; - typedef unsigned int ogg_uint32_t; - typedef long long int ogg_int64_t; - -#elif defined(__TMS320C6X__) - - /* TI C64x compiler */ - typedef signed short ogg_int16_t; - typedef unsigned short ogg_uint16_t; - typedef signed int ogg_int32_t; - typedef unsigned int ogg_uint32_t; - typedef long long int ogg_int64_t; - -#else - -# include - -#endif - -#endif /* _OS_TYPES_H */ diff --git a/ogg/libogg.spec.in b/ogg/libogg.spec.in deleted file mode 100644 index 41e9307..0000000 --- a/ogg/libogg.spec.in +++ /dev/null @@ -1,109 +0,0 @@ -Name: libogg -Version: @VERSION@ -Release: 0.xiph.1 -Summary: Ogg Bitstream Library. - -Group: System Environment/Libraries -License: BSD -URL: http://www.xiph.org/ -Vendor: Xiph.org Foundation -Source: http://www.vorbis.com/files/1.0.1/unix/%{name}-%{version}.tar.gz -BuildRoot: %{_tmppath}/%{name}-%{version}-root - -# We're forced to use an epoch since both Red Hat and Ximian use it in their -# rc packages -Epoch: 2 -# Dirty trick to tell rpm that this package actually provides what the -# last rc and beta was offering -Provides: %{name} = %{epoch}:1.0rc3-%{release} -Provides: %{name} = %{epoch}:1.0beta4-%{release} - -%description -Libogg is a library for manipulating ogg bitstreams. It handles -both making ogg bitstreams and getting packets from ogg bitstreams. - -%package devel -Summary: Ogg Bitstream Library Development -Group: Development/Libraries -Requires: libogg = %{version} -# Dirty trick to tell rpm that this package actually provides what the -# last rc and beta was offering -Provides: %{name}-devel = %{epoch}:1.0rc3-%{release} -Provides: %{name}-devel = %{epoch}:1.0beta4-%{release} - -%description devel -The libogg-devel package contains the header files, static libraries -and documentation needed to develop applications with libogg. - -%prep -%setup -q -n %{name}-%{version} - -%build -CFLAGS="$RPM_OPT_FLAGS" ./configure --prefix=%{_prefix} --enable-static -make - -%install -rm -rf $RPM_BUILD_ROOT - -make DESTDIR=$RPM_BUILD_ROOT install - -%clean -rm -rf $RPM_BUILD_ROOT - -%post -p /sbin/ldconfig - -%postun -p /sbin/ldconfig - -%files -%defattr(-,root,root) -%doc AUTHORS CHANGES COPYING README -%{_libdir}/libogg.so.* - -%files devel -%defattr(-,root,root) -%doc doc/index.html -%doc doc/framing.html -%doc doc/oggstream.html -%doc doc/white-ogg.png -%doc doc/white-xifish.png -%doc doc/stream.png -%doc doc/libogg/*.html -%doc doc/libogg/style.css -%dir %{_includedir}/ogg -%{_includedir}/ogg/ogg.h -%{_includedir}/ogg/os_types.h -%{_includedir}/ogg/config_types.h -%{_libdir}/libogg.a -%{_libdir}/libogg.la -%{_libdir}/libogg.so -%{_libdir}/pkgconfig/ogg.pc -%{_datadir}/aclocal/ogg.m4 - -%changelog -* Thu Nov 08 2007 Conrad Parker -- update doc dir (reported by thosmos on #vorbis) - -* Thu Jun 10 2004 Thomas Vander Stichele -- autogenerate from configure -- fix download location -- remove Prefix -- own include dir -- move ldconfig runs to -p scripts -- change Release tag to include xiph - -* Tue Oct 07 2003 Warren Dukes -- update for 1.1 release - -* Sun Jul 14 2002 Thomas Vander Stichele -- update for 1.0 release -- conform Group to Red Hat's idea of it -- take out case where configure doesn't exist; a tarball should have it - -* Tue Dec 18 2001 Jack Moffitt -- Update for RC3 release - -* Sun Oct 07 2001 Jack Moffitt -- add support for configurable prefixes - -* Sat Sep 02 2000 Jack Moffitt -- initial spec file created diff --git a/ogg/macosx/English.lproj/InfoPlist.strings b/ogg/macosx/English.lproj/InfoPlist.strings deleted file mode 100644 index b230fea..0000000 Binary files a/ogg/macosx/English.lproj/InfoPlist.strings and /dev/null differ diff --git a/ogg/macosx/Info.plist b/ogg/macosx/Info.plist deleted file mode 100644 index d075456..0000000 --- a/ogg/macosx/Info.plist +++ /dev/null @@ -1,30 +0,0 @@ - - - - - CFBundleDevelopmentRegion - English - CFBundleExecutable - Ogg - CFBundleGetInfoString - Ogg framework 1.1.4, Copyright © 1994-2009 Xiph.Org Foundation - CFBundleIconFile - - CFBundleIdentifier - org.xiph.ogg - CFBundleInfoDictionaryVersion - 6.0 - CFBundlePackageType - FMWK - CFBundleShortVersionString - 1.1.4 - CFBundleSignature - ???? - CFBundleVersion - 1.1.4 - NSHumanReadableCopyright - Ogg framework 1.1.4, Copyright © 1994-2009 Xiph.Org Foundation - CSResourcesFileMapped - - - diff --git a/ogg/macosx/Ogg.xcodeproj/project.pbxproj b/ogg/macosx/Ogg.xcodeproj/project.pbxproj deleted file mode 100644 index 596ccda..0000000 --- a/ogg/macosx/Ogg.xcodeproj/project.pbxproj +++ /dev/null @@ -1,363 +0,0 @@ -// !$*UTF8*$! -{ - archiveVersion = 1; - classes = { - }; - objectVersion = 42; - objects = { - -/* Begin PBXBuildFile section */ - 730F236309181A8D00AB638C /* bitwise.c in Sources */ = {isa = PBXBuildFile; fileRef = 730F236109181A8D00AB638C /* bitwise.c */; }; - 730F236409181A8D00AB638C /* framing.c in Sources */ = {isa = PBXBuildFile; fileRef = 730F236209181A8D00AB638C /* framing.c */; }; - 730F236709181ABE00AB638C /* ogg.h in Headers */ = {isa = PBXBuildFile; fileRef = 730F236509181ABE00AB638C /* ogg.h */; settings = {ATTRIBUTES = (Public, ); }; }; - 730F236809181ABE00AB638C /* os_types.h in Headers */ = {isa = PBXBuildFile; fileRef = 730F236609181ABE00AB638C /* os_types.h */; settings = {ATTRIBUTES = (Public, ); }; }; - 734FB2E70B18B36F00D561D7 /* bitwise.c in Sources */ = {isa = PBXBuildFile; fileRef = 730F236109181A8D00AB638C /* bitwise.c */; }; - 734FB2E80B18B36F00D561D7 /* framing.c in Sources */ = {isa = PBXBuildFile; fileRef = 730F236209181A8D00AB638C /* framing.c */; }; - 8D07F2BE0486CC7A007CD1D0 /* Ogg_Prefix.pch in Headers */ = {isa = PBXBuildFile; fileRef = 32BAE0B70371A74B00C91783 /* Ogg_Prefix.pch */; }; - 8D07F2C00486CC7A007CD1D0 /* InfoPlist.strings in Resources */ = {isa = PBXBuildFile; fileRef = 089C1666FE841158C02AAC07 /* InfoPlist.strings */; }; -/* End PBXBuildFile section */ - -/* Begin PBXFileReference section */ - 089C1667FE841158C02AAC07 /* English */ = {isa = PBXFileReference; fileEncoding = 10; lastKnownFileType = text.plist.strings; name = English; path = English.lproj/InfoPlist.strings; sourceTree = ""; }; - 32BAE0B70371A74B00C91783 /* Ogg_Prefix.pch */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = Ogg_Prefix.pch; sourceTree = ""; }; - 730F236109181A8D00AB638C /* bitwise.c */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.c; name = bitwise.c; path = ../src/bitwise.c; sourceTree = SOURCE_ROOT; }; - 730F236209181A8D00AB638C /* framing.c */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.c; name = framing.c; path = ../src/framing.c; sourceTree = SOURCE_ROOT; }; - 730F236509181ABE00AB638C /* ogg.h */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.h; name = ogg.h; path = ../include/ogg/ogg.h; sourceTree = SOURCE_ROOT; }; - 730F236609181ABE00AB638C /* os_types.h */ = {isa = PBXFileReference; fileEncoding = 30; lastKnownFileType = sourcecode.c.h; name = os_types.h; path = ../include/ogg/os_types.h; sourceTree = SOURCE_ROOT; }; - 734FB2E50B18B33E00D561D7 /* libogg.a */ = {isa = PBXFileReference; explicitFileType = archive.ar; includeInIndex = 0; path = libogg.a; sourceTree = BUILT_PRODUCTS_DIR; }; - 8D07F2C70486CC7A007CD1D0 /* Info.plist */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = text.plist; path = Info.plist; sourceTree = ""; }; - 8D07F2C80486CC7A007CD1D0 /* Ogg.framework */ = {isa = PBXFileReference; explicitFileType = wrapper.framework; includeInIndex = 0; path = Ogg.framework; sourceTree = BUILT_PRODUCTS_DIR; }; -/* End PBXFileReference section */ - -/* Begin PBXFrameworksBuildPhase section */ - 734FB2E30B18B33E00D561D7 /* Frameworks */ = { - isa = PBXFrameworksBuildPhase; - buildActionMask = 2147483647; - files = ( - ); - runOnlyForDeploymentPostprocessing = 0; - }; - 8D07F2C30486CC7A007CD1D0 /* Frameworks */ = { - isa = PBXFrameworksBuildPhase; - buildActionMask = 2147483647; - files = ( - ); - runOnlyForDeploymentPostprocessing = 0; - }; -/* End PBXFrameworksBuildPhase section */ - -/* Begin PBXGroup section */ - 034768DDFF38A45A11DB9C8B /* Products */ = { - isa = PBXGroup; - children = ( - 8D07F2C80486CC7A007CD1D0 /* Ogg.framework */, - 734FB2E50B18B33E00D561D7 /* libogg.a */, - ); - name = Products; - sourceTree = ""; - }; - 0867D691FE84028FC02AAC07 /* Ogg */ = { - isa = PBXGroup; - children = ( - 730F235F09181A3E00AB638C /* Headers */, - 08FB77ACFE841707C02AAC07 /* Source */, - 089C1665FE841158C02AAC07 /* Resources */, - 0867D69AFE84028FC02AAC07 /* External Frameworks and Libraries */, - 034768DDFF38A45A11DB9C8B /* Products */, - ); - name = Ogg; - sourceTree = ""; - }; - 0867D69AFE84028FC02AAC07 /* External Frameworks and Libraries */ = { - isa = PBXGroup; - children = ( - ); - name = "External Frameworks and Libraries"; - sourceTree = ""; - }; - 089C1665FE841158C02AAC07 /* Resources */ = { - isa = PBXGroup; - children = ( - 8D07F2C70486CC7A007CD1D0 /* Info.plist */, - 089C1666FE841158C02AAC07 /* InfoPlist.strings */, - ); - name = Resources; - sourceTree = ""; - }; - 08FB77ACFE841707C02AAC07 /* Source */ = { - isa = PBXGroup; - children = ( - 730F236109181A8D00AB638C /* bitwise.c */, - 730F236209181A8D00AB638C /* framing.c */, - 32BAE0B70371A74B00C91783 /* Ogg_Prefix.pch */, - ); - name = Source; - sourceTree = ""; - }; - 730F235F09181A3E00AB638C /* Headers */ = { - isa = PBXGroup; - children = ( - 730F236509181ABE00AB638C /* ogg.h */, - 730F236609181ABE00AB638C /* os_types.h */, - ); - name = Headers; - sourceTree = ""; - }; -/* End PBXGroup section */ - -/* Begin PBXHeadersBuildPhase section */ - 734FB2E10B18B33E00D561D7 /* Headers */ = { - isa = PBXHeadersBuildPhase; - buildActionMask = 2147483647; - files = ( - ); - runOnlyForDeploymentPostprocessing = 0; - }; - 8D07F2BD0486CC7A007CD1D0 /* Headers */ = { - isa = PBXHeadersBuildPhase; - buildActionMask = 2147483647; - files = ( - 8D07F2BE0486CC7A007CD1D0 /* Ogg_Prefix.pch in Headers */, - 730F236709181ABE00AB638C /* ogg.h in Headers */, - 730F236809181ABE00AB638C /* os_types.h in Headers */, - ); - runOnlyForDeploymentPostprocessing = 0; - }; -/* End PBXHeadersBuildPhase section */ - -/* Begin PBXNativeTarget section */ - 734FB2E40B18B33E00D561D7 /* libogg (static) */ = { - isa = PBXNativeTarget; - buildConfigurationList = 734FB2ED0B18B3B900D561D7 /* Build configuration list for PBXNativeTarget "libogg (static)" */; - buildPhases = ( - 734FB2E10B18B33E00D561D7 /* Headers */, - 734FB2E20B18B33E00D561D7 /* Sources */, - 734FB2E30B18B33E00D561D7 /* Frameworks */, - ); - buildRules = ( - ); - dependencies = ( - ); - name = "libogg (static)"; - productName = ogg; - productReference = 734FB2E50B18B33E00D561D7 /* libogg.a */; - productType = "com.apple.product-type.library.static"; - }; - 8D07F2BC0486CC7A007CD1D0 /* Ogg */ = { - isa = PBXNativeTarget; - buildConfigurationList = 730F235409181A3A00AB638C /* Build configuration list for PBXNativeTarget "Ogg" */; - buildPhases = ( - 8D07F2BD0486CC7A007CD1D0 /* Headers */, - 8D07F2BF0486CC7A007CD1D0 /* Resources */, - 8D07F2C10486CC7A007CD1D0 /* Sources */, - 8D07F2C30486CC7A007CD1D0 /* Frameworks */, - 8D07F2C50486CC7A007CD1D0 /* Rez */, - ); - buildRules = ( - ); - dependencies = ( - ); - name = Ogg; - productInstallPath = "$(HOME)/Library/Frameworks"; - productName = Ogg; - productReference = 8D07F2C80486CC7A007CD1D0 /* Ogg.framework */; - productType = "com.apple.product-type.framework"; - }; -/* End PBXNativeTarget section */ - -/* Begin PBXProject section */ - 0867D690FE84028FC02AAC07 /* Project object */ = { - isa = PBXProject; - buildConfigurationList = 730F235809181A3A00AB638C /* Build configuration list for PBXProject "Ogg" */; - hasScannedForEncodings = 1; - mainGroup = 0867D691FE84028FC02AAC07 /* Ogg */; - productRefGroup = 034768DDFF38A45A11DB9C8B /* Products */; - projectDirPath = ""; - targets = ( - 8D07F2BC0486CC7A007CD1D0 /* Ogg */, - 734FB2E40B18B33E00D561D7 /* libogg (static) */, - ); - }; -/* End PBXProject section */ - -/* Begin PBXResourcesBuildPhase section */ - 8D07F2BF0486CC7A007CD1D0 /* Resources */ = { - isa = PBXResourcesBuildPhase; - buildActionMask = 2147483647; - files = ( - 8D07F2C00486CC7A007CD1D0 /* InfoPlist.strings in Resources */, - ); - runOnlyForDeploymentPostprocessing = 0; - }; -/* End PBXResourcesBuildPhase section */ - -/* Begin PBXRezBuildPhase section */ - 8D07F2C50486CC7A007CD1D0 /* Rez */ = { - isa = PBXRezBuildPhase; - buildActionMask = 2147483647; - files = ( - ); - runOnlyForDeploymentPostprocessing = 0; - }; -/* End PBXRezBuildPhase section */ - -/* Begin PBXSourcesBuildPhase section */ - 734FB2E20B18B33E00D561D7 /* Sources */ = { - isa = PBXSourcesBuildPhase; - buildActionMask = 2147483647; - files = ( - 734FB2E70B18B36F00D561D7 /* bitwise.c in Sources */, - 734FB2E80B18B36F00D561D7 /* framing.c in Sources */, - ); - runOnlyForDeploymentPostprocessing = 0; - }; - 8D07F2C10486CC7A007CD1D0 /* Sources */ = { - isa = PBXSourcesBuildPhase; - buildActionMask = 2147483647; - files = ( - 730F236309181A8D00AB638C /* bitwise.c in Sources */, - 730F236409181A8D00AB638C /* framing.c in Sources */, - ); - runOnlyForDeploymentPostprocessing = 0; - }; -/* End PBXSourcesBuildPhase section */ - -/* Begin PBXVariantGroup section */ - 089C1666FE841158C02AAC07 /* InfoPlist.strings */ = { - isa = PBXVariantGroup; - children = ( - 089C1667FE841158C02AAC07 /* English */, - ); - name = InfoPlist.strings; - sourceTree = ""; - }; -/* End PBXVariantGroup section */ - -/* Begin XCBuildConfiguration section */ - 730F235509181A3A00AB638C /* Debug */ = { - isa = XCBuildConfiguration; - buildSettings = { - COPY_PHASE_STRIP = NO; - DYLIB_COMPATIBILITY_VERSION = 1; - DYLIB_CURRENT_VERSION = 1; - FRAMEWORK_VERSION = A; - GCC_DYNAMIC_NO_PIC = NO; - GCC_ENABLE_FIX_AND_CONTINUE = YES; - GCC_GENERATE_DEBUGGING_SYMBOLS = YES; - GCC_PRECOMPILE_PREFIX_HEADER = YES; - GCC_PREFIX_HEADER = Ogg_Prefix.pch; - INFOPLIST_FILE = Info.plist; - INSTALL_PATH = /Library/Frameworks; - PRODUCT_NAME = Ogg; - WRAPPER_EXTENSION = framework; - ZERO_LINK = YES; - }; - name = Debug; - }; - 730F235609181A3A00AB638C /* Release */ = { - isa = XCBuildConfiguration; - buildSettings = { - COPY_PHASE_STRIP = YES; - DYLIB_COMPATIBILITY_VERSION = 1; - DYLIB_CURRENT_VERSION = 1; - FRAMEWORK_VERSION = A; - GCC_ENABLE_FIX_AND_CONTINUE = NO; - GCC_GENERATE_DEBUGGING_SYMBOLS = NO; - GCC_PRECOMPILE_PREFIX_HEADER = YES; - GCC_PREFIX_HEADER = Ogg_Prefix.pch; - INFOPLIST_FILE = Info.plist; - INSTALL_PATH = /Library/Frameworks; - PRODUCT_NAME = Ogg; - WRAPPER_EXTENSION = framework; - ZERO_LINK = NO; - }; - name = Release; - }; - 730F235909181A3A00AB638C /* Debug */ = { - isa = XCBuildConfiguration; - buildSettings = { - GCC_OPTIMIZATION_LEVEL = 0; - GCC_PREPROCESSOR_DEFINITIONS = __MACOSX__; - SDKROOT = /Developer/SDKs/MacOSX10.4u.sdk; - }; - name = Debug; - }; - 730F235A09181A3A00AB638C /* Release */ = { - isa = XCBuildConfiguration; - buildSettings = { - ARCHS = ( - ppc, - i386, - ); - GCC_OPTIMIZATION_LEVEL = 3; - GCC_PREPROCESSOR_DEFINITIONS = __MACOSX__; - OTHER_CFLAGS = ( - "$(OTHER_CFLAGS)", - "-ffast-math", - "-falign-loops=16", - ); - SDKROOT = /Developer/SDKs/MacOSX10.4u.sdk; - }; - name = Release; - }; - 734FB2EE0B18B3B900D561D7 /* Debug */ = { - isa = XCBuildConfiguration; - buildSettings = { - COPY_PHASE_STRIP = NO; - GCC_DYNAMIC_NO_PIC = NO; - GCC_ENABLE_FIX_AND_CONTINUE = YES; - GCC_GENERATE_DEBUGGING_SYMBOLS = YES; - INSTALL_PATH = /usr/local/lib; - PREBINDING = NO; - PRODUCT_NAME = ogg; - ZERO_LINK = YES; - }; - name = Debug; - }; - 734FB2EF0B18B3B900D561D7 /* Release */ = { - isa = XCBuildConfiguration; - buildSettings = { - COPY_PHASE_STRIP = YES; - GCC_ENABLE_FIX_AND_CONTINUE = NO; - GCC_GENERATE_DEBUGGING_SYMBOLS = NO; - INSTALL_PATH = /usr/local/lib; - PREBINDING = NO; - PRODUCT_NAME = ogg; - ZERO_LINK = NO; - }; - name = Release; - }; -/* End XCBuildConfiguration section */ - -/* Begin XCConfigurationList section */ - 730F235409181A3A00AB638C /* Build configuration list for PBXNativeTarget "Ogg" */ = { - isa = XCConfigurationList; - buildConfigurations = ( - 730F235509181A3A00AB638C /* Debug */, - 730F235609181A3A00AB638C /* Release */, - ); - defaultConfigurationIsVisible = 0; - defaultConfigurationName = Release; - }; - 730F235809181A3A00AB638C /* Build configuration list for PBXProject "Ogg" */ = { - isa = XCConfigurationList; - buildConfigurations = ( - 730F235909181A3A00AB638C /* Debug */, - 730F235A09181A3A00AB638C /* Release */, - ); - defaultConfigurationIsVisible = 0; - defaultConfigurationName = Release; - }; - 734FB2ED0B18B3B900D561D7 /* Build configuration list for PBXNativeTarget "libogg (static)" */ = { - isa = XCConfigurationList; - buildConfigurations = ( - 734FB2EE0B18B3B900D561D7 /* Debug */, - 734FB2EF0B18B3B900D561D7 /* Release */, - ); - defaultConfigurationIsVisible = 0; - defaultConfigurationName = Release; - }; -/* End XCConfigurationList section */ - }; - rootObject = 0867D690FE84028FC02AAC07 /* Project object */; -} diff --git a/ogg/macosx/Ogg_Prefix.pch b/ogg/macosx/Ogg_Prefix.pch deleted file mode 100644 index 05e3af9..0000000 --- a/ogg/macosx/Ogg_Prefix.pch +++ /dev/null @@ -1,5 +0,0 @@ -// -// Prefix header for all source files of the 'Ogg' target in the 'Ogg' project. -// - -#include diff --git a/ogg/ogg-uninstalled.pc.in b/ogg/ogg-uninstalled.pc.in deleted file mode 100644 index 7872cc6..0000000 --- a/ogg/ogg-uninstalled.pc.in +++ /dev/null @@ -1,14 +0,0 @@ -# ogg uninstalled pkg-config file - -prefix= -exec_prefix= -libdir=${pcfiledir}/src -includedir=${pcfiledir}/include - -Name: ogg -Description: ogg is a library for manipulating ogg bitstreams (not installed) -Version: @VERSION@ -Requires: -Conflicts: -Libs: ${libdir}/.libs/libogg.a -Cflags: -I${includedir} diff --git a/ogg/ogg.m4 b/ogg/ogg.m4 deleted file mode 100644 index 77d663b..0000000 --- a/ogg/ogg.m4 +++ /dev/null @@ -1,116 +0,0 @@ -# Configure paths for libogg -# Jack Moffitt 10-21-2000 -# Shamelessly stolen from Owen Taylor and Manish Singh - -dnl XIPH_PATH_OGG([ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]) -dnl Test for libogg, and define OGG_CFLAGS and OGG_LIBS -dnl -AC_DEFUN([XIPH_PATH_OGG], -[dnl -dnl Get the cflags and libraries -dnl -AC_ARG_WITH(ogg,AC_HELP_STRING([--with-ogg=PFX],[Prefix where libogg is installed (optional)]), ogg_prefix="$withval", ogg_prefix="") -AC_ARG_WITH(ogg-libraries,AC_HELP_STRING([--with-ogg-libraries=DIR],[Directory where libogg library is installed (optional)]), ogg_libraries="$withval", ogg_libraries="") -AC_ARG_WITH(ogg-includes,AC_HELP_STRING([--with-ogg-includes=DIR],[Directory where libogg header files are installed (optional)]), ogg_includes="$withval", ogg_includes="") -AC_ARG_ENABLE(oggtest,AC_HELP_STRING([--disable-oggtest],[Do not try to compile and run a test Ogg program]),, enable_oggtest=yes) - - if test "x$ogg_libraries" != "x" ; then - OGG_LIBS="-L$ogg_libraries" - elif test "x$ogg_prefix" = "xno" || test "x$ogg_prefix" = "xyes" ; then - OGG_LIBS="" - elif test "x$ogg_prefix" != "x" ; then - OGG_LIBS="-L$ogg_prefix/lib" - elif test "x$prefix" != "xNONE" ; then - OGG_LIBS="-L$prefix/lib" - fi - - if test "x$ogg_prefix" != "xno" ; then - OGG_LIBS="$OGG_LIBS -logg" - fi - - if test "x$ogg_includes" != "x" ; then - OGG_CFLAGS="-I$ogg_includes" - elif test "x$ogg_prefix" = "xno" || test "x$ogg_prefix" = "xyes" ; then - OGG_CFLAGS="" - elif test "x$ogg_prefix" != "x" ; then - OGG_CFLAGS="-I$ogg_prefix/include" - elif test "x$prefix" != "xNONE"; then - OGG_CFLAGS="-I$prefix/include" - fi - - AC_MSG_CHECKING(for Ogg) - if test "x$ogg_prefix" = "xno" ; then - no_ogg="disabled" - enable_oggtest="no" - else - no_ogg="" - fi - - - if test "x$enable_oggtest" = "xyes" ; then - ac_save_CFLAGS="$CFLAGS" - ac_save_LIBS="$LIBS" - CFLAGS="$CFLAGS $OGG_CFLAGS" - LIBS="$LIBS $OGG_LIBS" -dnl -dnl Now check if the installed Ogg is sufficiently new. -dnl - rm -f conf.oggtest - AC_TRY_RUN([ -#include -#include -#include -#include - -int main () -{ - system("touch conf.oggtest"); - return 0; -} - -],, no_ogg=yes,[echo $ac_n "cross compiling; assumed OK... $ac_c"]) - CFLAGS="$ac_save_CFLAGS" - LIBS="$ac_save_LIBS" - fi - - if test "x$no_ogg" = "xdisabled" ; then - AC_MSG_RESULT(no) - ifelse([$2], , :, [$2]) - elif test "x$no_ogg" = "x" ; then - AC_MSG_RESULT(yes) - ifelse([$1], , :, [$1]) - else - AC_MSG_RESULT(no) - if test -f conf.oggtest ; then - : - else - echo "*** Could not run Ogg test program, checking why..." - CFLAGS="$CFLAGS $OGG_CFLAGS" - LIBS="$LIBS $OGG_LIBS" - AC_TRY_LINK([ -#include -#include -], [ return 0; ], - [ echo "*** The test program compiled, but did not run. This usually means" - echo "*** that the run-time linker is not finding Ogg or finding the wrong" - echo "*** version of Ogg. If it is not finding Ogg, you'll need to set your" - echo "*** LD_LIBRARY_PATH environment variable, or edit /etc/ld.so.conf to point" - echo "*** to the installed location Also, make sure you have run ldconfig if that" - echo "*** is required on your system" - echo "***" - echo "*** If you have an old version installed, it is best to remove it, although" - echo "*** you may also be able to get things to work by modifying LD_LIBRARY_PATH"], - [ echo "*** The test program failed to compile or link. See the file config.log for the" - echo "*** exact error that occured. This usually means Ogg was incorrectly installed" - echo "*** or that you have moved Ogg since it was installed." ]) - CFLAGS="$ac_save_CFLAGS" - LIBS="$ac_save_LIBS" - fi - OGG_CFLAGS="" - OGG_LIBS="" - ifelse([$2], , :, [$2]) - fi - AC_SUBST(OGG_CFLAGS) - AC_SUBST(OGG_LIBS) - rm -f conf.oggtest -]) diff --git a/ogg/ogg.pc.in b/ogg/ogg.pc.in deleted file mode 100644 index 9e84375..0000000 --- a/ogg/ogg.pc.in +++ /dev/null @@ -1,14 +0,0 @@ -# ogg pkg-config file - -prefix=@prefix@ -exec_prefix=@exec_prefix@ -libdir=@libdir@ -includedir=@includedir@ - -Name: ogg -Description: ogg is a library for manipulating ogg bitstreams -Version: @VERSION@ -Requires: -Conflicts: -Libs: -L${libdir} -logg -Cflags: -I${includedir} diff --git a/ogg/releases.sha2 b/ogg/releases.sha2 deleted file mode 100644 index 5cc3aeb..0000000 --- a/ogg/releases.sha2 +++ /dev/null @@ -1,34 +0,0 @@ -c8a4157b0194962aa885e2088cf8561c65ce2eee36a77ca6325c6c36c842b2a9 libogg-1.0beta4.tar.gz -37bec40bf26ba6af8e98f2996051079cd2fbc4c401960fadb15c9e75383f3361 libogg-1.0rc1.tar.gz -c5f5924f25402a59a2586c3d037d3e79dae97de30531b8dd8b8b4abc20d5f036 libogg-1.0rc2.tar.gz -e907b7bc56de5a9dd0c5f062c7b0340a6295671cf2c6ad994d5f62919c9e1b0b libogg-1.0rc3.tar.gz -920fa2a0924d66884825d36a2e843de069cfdf1af01945d05da25999bbd6396c libogg-1.0.tar.gz -269f8f6b11b8ac737cbd8ed8cfa244cc51ca42b6da6683336ba1413d2a00ceb3 libogg-1.1.1.tar.gz -b72f4d716d8e1339469a874962aae5f055ba618772f00f43d3c6d0b543cdfadd libogg-1.1.1.zip -7934f3bf689c6ea0870bc73fcf40b00d5050044b03e558819a1ed333dc3cfadf libogg-1.1.2.tar.gz -01e97dd79336db38b31003ff956c7e29ebcfd8ceef8175cf17cf4f339a8c1a54 libogg-1.1.2.zip -bae29e79fbc50bbedf1235852094b71c8c910a1ef0cd42fe4163b7b545630b65 libogg-1.1.3.tar.gz -11c0202bc8f8e6fa361051a7d2dbc7ec95195b126c0407c5fc851d01c2a2ad6b libogg-1.1.3.zip -253d138b8c062db4d8446be1522162940dd89cad35c8332c3127d2e842850f31 libogg-1.1.4rc1.tar.gz -6bb65e5eafc75cc2ef7ccc37aea81749f1e72e503f7614e6748c06f532c42707 libogg-1.1.4rc1.zip -9354c183fd88417c2860778b60b7896c9487d8f6e58b9fec3fdbf971142ce103 libogg-1.1.4.tar.gz -0e9eb2370ba8d28ee6f6ccf27779c154fbfbd9c5e9d3a09e4419a85112a900ce libogg-1.1.4.zip -01453d561255b5fcb361997904752860e4f8c6b9742f290578a44615fcc94356 libogg-1.1.tar.gz -f30d983e238acd94e80ae551327ea2f83cdc330470b4188564bef28fec59eb69 libogg-1.2.0.tar.gz -6bf8650f0f3651fa4714ab9d03a5f781879e697d85d776f4dabc31877f42a0b2 libogg-1.2.0.zip -da222202be8be48149f0a0668f3d2445a166b1f9f40a25e27cd222bfa9c1d4d4 libogg-1.2.1.tar.bz2 -6858848617bca6eab01e7d8526bc0d2a417e95070a255cbf9c881881365e36c0 libogg-1.2.1.tar.gz -21e0a61e15e9dd294587bcd39d81fbe1998b27b1c525e15ecfaba94344f921b4 libogg-1.2.1.tar.xz -2d799a043865edc030ae56186a44624deb6365d59bcd8b3ae96384ccf613189d libogg-1.2.1.zip -ab000574bc26d5f01284f5b0f50e12dc761d035c429f2e9c70cb2a9487d8cfba libogg-1.2.2.tar.gz -559f1ea72a559520298e518865e488eb9a7185c6b9279f70602b01a87f7defed libogg-1.2.2.tar.xz -3f3bec05106d852da5ae3899ac2047dd14e2009bba872524eeade2d0bda42da0 libogg-1.2.2.zip -a8de807631014615549d2356fd36641833b8288221cea214f8a72750efe93780 libogg-1.3.0.tar.gz -231725029c843492914f24e74085e734bca6f1d6446ac72df39b0c3a9d4bc74b libogg-1.3.0.tar.xz -56db84601e7e855d1b9095ccba73d8ef98f063a2384f2239a7042070a3f1cde3 libogg-1.3.0.zip -4e343f07aa5a1de8e0fa1107042d472186b3470d846b20b115b964eba5bae554 libogg-1.3.1.tar.gz -3a5bad78d81afb78908326d11761c0fb1a0662ee7150b6ad587cc586838cdcfa libogg-1.3.1.tar.xz -131ae1f65f65e0ed70db03fbe3a9d9f2e8c24ac43754ae5e055fc55e6f750bc7 libogg-1.3.1.zip -e19ee34711d7af328cb26287f4137e70630e7261b17cbe3cd41011d73a654692 libogg-1.3.2.tar.gz -3f687ccdd5ac8b52d76328fbbfebc70c459a40ea891dbf3dccb74a210826e79b libogg-1.3.2.tar.xz -957b4168a03932e02853db340cfddd0fa89b6ca80073a54f7c827372c3606350 libogg-1.3.2.zip diff --git a/ogg/src/Makefile.am b/ogg/src/Makefile.am deleted file mode 100644 index 9472626..0000000 --- a/ogg/src/Makefile.am +++ /dev/null @@ -1,28 +0,0 @@ -## Process this file with automake to produce Makefile.in - -AM_CPPFLAGS = -I$(top_srcdir)/include -I$(top_builddir)/include - -lib_LTLIBRARIES = libogg.la - -libogg_la_SOURCES = framing.c bitwise.c -libogg_la_LDFLAGS = -no-undefined -version-info @LIB_CURRENT@:@LIB_REVISION@:@LIB_AGE@ - -# build and run the self tests on 'make check' - -noinst_PROGRAMS = test_bitwise test_framing - -test_bitwise_SOURCES = bitwise.c -test_bitwise_CFLAGS = -D_V_SELFTEST - -test_framing_SOURCES = framing.c -test_framing_CFLAGS = -D_V_SELFTEST - -check: $(noinst_PROGRAMS) - ./test_bitwise$(EXEEXT) - ./test_framing$(EXEEXT) - -debug: - $(MAKE) all CFLAGS="@DEBUG@" - -profile: - $(MAKE) all CFLAGS="@PROFILE@" diff --git a/ogg/src/bitwise.c b/ogg/src/bitwise.c deleted file mode 100644 index fa2b572..0000000 --- a/ogg/src/bitwise.c +++ /dev/null @@ -1,1088 +0,0 @@ -/******************************************************************** - * * - * THIS FILE IS PART OF THE Ogg CONTAINER 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 (C) COPYRIGHT 1994-2014 * - * by the Xiph.Org Foundation http://www.xiph.org/ * - * * - ******************************************************************** - - function: packing variable sized words into an octet stream - last mod: $Id$ - - ********************************************************************/ - -/* We're 'LSb' endian; if we write a word but read individual bits, - then we'll read the lsb first */ - -#include -#include -#include -#include - -#define BUFFER_INCREMENT 256 - -static const unsigned long mask[]= -{0x00000000,0x00000001,0x00000003,0x00000007,0x0000000f, - 0x0000001f,0x0000003f,0x0000007f,0x000000ff,0x000001ff, - 0x000003ff,0x000007ff,0x00000fff,0x00001fff,0x00003fff, - 0x00007fff,0x0000ffff,0x0001ffff,0x0003ffff,0x0007ffff, - 0x000fffff,0x001fffff,0x003fffff,0x007fffff,0x00ffffff, - 0x01ffffff,0x03ffffff,0x07ffffff,0x0fffffff,0x1fffffff, - 0x3fffffff,0x7fffffff,0xffffffff }; - -static const unsigned int mask8B[]= -{0x00,0x80,0xc0,0xe0,0xf0,0xf8,0xfc,0xfe,0xff}; - -void oggpack_writeinit(oggpack_buffer *b){ - memset(b,0,sizeof(*b)); - b->ptr=b->buffer=_ogg_malloc(BUFFER_INCREMENT); - b->buffer[0]='\0'; - b->storage=BUFFER_INCREMENT; -} - -void oggpackB_writeinit(oggpack_buffer *b){ - oggpack_writeinit(b); -} - -int oggpack_writecheck(oggpack_buffer *b){ - if(!b->ptr || !b->storage)return -1; - return 0; -} - -int oggpackB_writecheck(oggpack_buffer *b){ - return oggpack_writecheck(b); -} - -void oggpack_writetrunc(oggpack_buffer *b,long bits){ - long bytes=bits>>3; - if(b->ptr){ - bits-=bytes*8; - b->ptr=b->buffer+bytes; - b->endbit=bits; - b->endbyte=bytes; - *b->ptr&=mask[bits]; - } -} - -void oggpackB_writetrunc(oggpack_buffer *b,long bits){ - long bytes=bits>>3; - if(b->ptr){ - bits-=bytes*8; - b->ptr=b->buffer+bytes; - b->endbit=bits; - b->endbyte=bytes; - *b->ptr&=mask8B[bits]; - } -} - -/* Takes only up to 32 bits. */ -void oggpack_write(oggpack_buffer *b,unsigned long value,int bits){ - if(bits<0 || bits>32) goto err; - if(b->endbyte>=b->storage-4){ - void *ret; - if(!b->ptr)return; - if(b->storage>LONG_MAX-BUFFER_INCREMENT) goto err; - ret=_ogg_realloc(b->buffer,b->storage+BUFFER_INCREMENT); - if(!ret) goto err; - b->buffer=ret; - b->storage+=BUFFER_INCREMENT; - b->ptr=b->buffer+b->endbyte; - } - - value&=mask[bits]; - bits+=b->endbit; - - b->ptr[0]|=value<endbit; - - if(bits>=8){ - b->ptr[1]=(unsigned char)(value>>(8-b->endbit)); - if(bits>=16){ - b->ptr[2]=(unsigned char)(value>>(16-b->endbit)); - if(bits>=24){ - b->ptr[3]=(unsigned char)(value>>(24-b->endbit)); - if(bits>=32){ - if(b->endbit) - b->ptr[4]=(unsigned char)(value>>(32-b->endbit)); - else - b->ptr[4]=0; - } - } - } - } - - b->endbyte+=bits/8; - b->ptr+=bits/8; - b->endbit=bits&7; - return; - err: - oggpack_writeclear(b); -} - -/* Takes only up to 32 bits. */ -void oggpackB_write(oggpack_buffer *b,unsigned long value,int bits){ - if(bits<0 || bits>32) goto err; - if(b->endbyte>=b->storage-4){ - void *ret; - if(!b->ptr)return; - if(b->storage>LONG_MAX-BUFFER_INCREMENT) goto err; - ret=_ogg_realloc(b->buffer,b->storage+BUFFER_INCREMENT); - if(!ret) goto err; - b->buffer=ret; - b->storage+=BUFFER_INCREMENT; - b->ptr=b->buffer+b->endbyte; - } - - value=(value&mask[bits])<<(32-bits); - bits+=b->endbit; - - b->ptr[0]|=value>>(24+b->endbit); - - if(bits>=8){ - b->ptr[1]=(unsigned char)(value>>(16+b->endbit)); - if(bits>=16){ - b->ptr[2]=(unsigned char)(value>>(8+b->endbit)); - if(bits>=24){ - b->ptr[3]=(unsigned char)(value>>(b->endbit)); - if(bits>=32){ - if(b->endbit) - b->ptr[4]=(unsigned char)(value<<(8-b->endbit)); - else - b->ptr[4]=0; - } - } - } - } - - b->endbyte+=bits/8; - b->ptr+=bits/8; - b->endbit=bits&7; - return; - err: - oggpack_writeclear(b); -} - -void oggpack_writealign(oggpack_buffer *b){ - int bits=8-b->endbit; - if(bits<8) - oggpack_write(b,0,bits); -} - -void oggpackB_writealign(oggpack_buffer *b){ - int bits=8-b->endbit; - if(bits<8) - oggpackB_write(b,0,bits); -} - -static void oggpack_writecopy_helper(oggpack_buffer *b, - void *source, - long bits, - void (*w)(oggpack_buffer *, - unsigned long, - int), - int msb){ - unsigned char *ptr=(unsigned char *)source; - - long bytes=bits/8; - long pbytes=(b->endbit+bits)/8; - bits-=bytes*8; - - /* expand storage up-front */ - if(b->endbyte+pbytes>=b->storage){ - void *ret; - if(!b->ptr) goto err; - if(b->storage>b->endbyte+pbytes+BUFFER_INCREMENT) goto err; - b->storage=b->endbyte+pbytes+BUFFER_INCREMENT; - ret=_ogg_realloc(b->buffer,b->storage); - if(!ret) goto err; - b->buffer=ret; - b->ptr=b->buffer+b->endbyte; - } - - /* copy whole octets */ - if(b->endbit){ - int i; - /* unaligned copy. Do it the hard way. */ - for(i=0;iptr,source,bytes); - b->ptr+=bytes; - b->endbyte+=bytes; - *b->ptr=0; - } - - /* copy trailing bits */ - if(bits){ - if(msb) - w(b,(unsigned long)(ptr[bytes]>>(8-bits)),bits); - else - w(b,(unsigned long)(ptr[bytes]),bits); - } - return; - err: - oggpack_writeclear(b); -} - -void oggpack_writecopy(oggpack_buffer *b,void *source,long bits){ - oggpack_writecopy_helper(b,source,bits,oggpack_write,0); -} - -void oggpackB_writecopy(oggpack_buffer *b,void *source,long bits){ - oggpack_writecopy_helper(b,source,bits,oggpackB_write,1); -} - -void oggpack_reset(oggpack_buffer *b){ - if(!b->ptr)return; - b->ptr=b->buffer; - b->buffer[0]=0; - b->endbit=b->endbyte=0; -} - -void oggpackB_reset(oggpack_buffer *b){ - oggpack_reset(b); -} - -void oggpack_writeclear(oggpack_buffer *b){ - if(b->buffer)_ogg_free(b->buffer); - memset(b,0,sizeof(*b)); -} - -void oggpackB_writeclear(oggpack_buffer *b){ - oggpack_writeclear(b); -} - -void oggpack_readinit(oggpack_buffer *b,unsigned char *buf,int bytes){ - memset(b,0,sizeof(*b)); - b->buffer=b->ptr=buf; - b->storage=bytes; -} - -void oggpackB_readinit(oggpack_buffer *b,unsigned char *buf,int bytes){ - oggpack_readinit(b,buf,bytes); -} - -/* Read in bits without advancing the bitptr; bits <= 32 */ -long oggpack_look(oggpack_buffer *b,int bits){ - unsigned long ret; - unsigned long m; - - if(bits<0 || bits>32) return -1; - m=mask[bits]; - bits+=b->endbit; - - if(b->endbyte >= b->storage-4){ - /* not the main path */ - if(b->endbyte > b->storage-((bits+7)>>3)) return -1; - /* special case to avoid reading b->ptr[0], which might be past the end of - the buffer; also skips some useless accounting */ - else if(!bits)return(0L); - } - - ret=b->ptr[0]>>b->endbit; - if(bits>8){ - ret|=b->ptr[1]<<(8-b->endbit); - if(bits>16){ - ret|=b->ptr[2]<<(16-b->endbit); - if(bits>24){ - ret|=b->ptr[3]<<(24-b->endbit); - if(bits>32 && b->endbit) - ret|=b->ptr[4]<<(32-b->endbit); - } - } - } - return(m&ret); -} - -/* Read in bits without advancing the bitptr; bits <= 32 */ -long oggpackB_look(oggpack_buffer *b,int bits){ - unsigned long ret; - int m=32-bits; - - if(m<0 || m>32) return -1; - bits+=b->endbit; - - if(b->endbyte >= b->storage-4){ - /* not the main path */ - if(b->endbyte > b->storage-((bits+7)>>3)) return -1; - /* special case to avoid reading b->ptr[0], which might be past the end of - the buffer; also skips some useless accounting */ - else if(!bits)return(0L); - } - - ret=b->ptr[0]<<(24+b->endbit); - if(bits>8){ - ret|=b->ptr[1]<<(16+b->endbit); - if(bits>16){ - ret|=b->ptr[2]<<(8+b->endbit); - if(bits>24){ - ret|=b->ptr[3]<<(b->endbit); - if(bits>32 && b->endbit) - ret|=b->ptr[4]>>(8-b->endbit); - } - } - } - return ((ret&0xffffffff)>>(m>>1))>>((m+1)>>1); -} - -long oggpack_look1(oggpack_buffer *b){ - if(b->endbyte>=b->storage)return(-1); - return((b->ptr[0]>>b->endbit)&1); -} - -long oggpackB_look1(oggpack_buffer *b){ - if(b->endbyte>=b->storage)return(-1); - return((b->ptr[0]>>(7-b->endbit))&1); -} - -void oggpack_adv(oggpack_buffer *b,int bits){ - bits+=b->endbit; - - if(b->endbyte > b->storage-((bits+7)>>3)) goto overflow; - - b->ptr+=bits/8; - b->endbyte+=bits/8; - b->endbit=bits&7; - return; - - overflow: - b->ptr=NULL; - b->endbyte=b->storage; - b->endbit=1; -} - -void oggpackB_adv(oggpack_buffer *b,int bits){ - oggpack_adv(b,bits); -} - -void oggpack_adv1(oggpack_buffer *b){ - if(++(b->endbit)>7){ - b->endbit=0; - b->ptr++; - b->endbyte++; - } -} - -void oggpackB_adv1(oggpack_buffer *b){ - oggpack_adv1(b); -} - -/* bits <= 32 */ -long oggpack_read(oggpack_buffer *b,int bits){ - long ret; - unsigned long m; - - if(bits<0 || bits>32) goto err; - m=mask[bits]; - bits+=b->endbit; - - if(b->endbyte >= b->storage-4){ - /* not the main path */ - if(b->endbyte > b->storage-((bits+7)>>3)) goto overflow; - /* special case to avoid reading b->ptr[0], which might be past the end of - the buffer; also skips some useless accounting */ - else if(!bits)return(0L); - } - - ret=b->ptr[0]>>b->endbit; - if(bits>8){ - ret|=b->ptr[1]<<(8-b->endbit); - if(bits>16){ - ret|=b->ptr[2]<<(16-b->endbit); - if(bits>24){ - ret|=b->ptr[3]<<(24-b->endbit); - if(bits>32 && b->endbit){ - ret|=b->ptr[4]<<(32-b->endbit); - } - } - } - } - ret&=m; - b->ptr+=bits/8; - b->endbyte+=bits/8; - b->endbit=bits&7; - return ret; - - overflow: - err: - b->ptr=NULL; - b->endbyte=b->storage; - b->endbit=1; - return -1L; -} - -/* bits <= 32 */ -long oggpackB_read(oggpack_buffer *b,int bits){ - long ret; - long m=32-bits; - - if(m<0 || m>32) goto err; - bits+=b->endbit; - - if(b->endbyte+4>=b->storage){ - /* not the main path */ - if(b->endbyte > b->storage-((bits+7)>>3)) goto overflow; - /* special case to avoid reading b->ptr[0], which might be past the end of - the buffer; also skips some useless accounting */ - else if(!bits)return(0L); - } - - ret=b->ptr[0]<<(24+b->endbit); - if(bits>8){ - ret|=b->ptr[1]<<(16+b->endbit); - if(bits>16){ - ret|=b->ptr[2]<<(8+b->endbit); - if(bits>24){ - ret|=b->ptr[3]<<(b->endbit); - if(bits>32 && b->endbit) - ret|=b->ptr[4]>>(8-b->endbit); - } - } - } - ret=((ret&0xffffffffUL)>>(m>>1))>>((m+1)>>1); - - b->ptr+=bits/8; - b->endbyte+=bits/8; - b->endbit=bits&7; - return ret; - - overflow: - err: - b->ptr=NULL; - b->endbyte=b->storage; - b->endbit=1; - return -1L; -} - -long oggpack_read1(oggpack_buffer *b){ - long ret; - - if(b->endbyte >= b->storage) goto overflow; - ret=(b->ptr[0]>>b->endbit)&1; - - b->endbit++; - if(b->endbit>7){ - b->endbit=0; - b->ptr++; - b->endbyte++; - } - return ret; - - overflow: - b->ptr=NULL; - b->endbyte=b->storage; - b->endbit=1; - return -1L; -} - -long oggpackB_read1(oggpack_buffer *b){ - long ret; - - if(b->endbyte >= b->storage) goto overflow; - ret=(b->ptr[0]>>(7-b->endbit))&1; - - b->endbit++; - if(b->endbit>7){ - b->endbit=0; - b->ptr++; - b->endbyte++; - } - return ret; - - overflow: - b->ptr=NULL; - b->endbyte=b->storage; - b->endbit=1; - return -1L; -} - -long oggpack_bytes(oggpack_buffer *b){ - return(b->endbyte+(b->endbit+7)/8); -} - -long oggpack_bits(oggpack_buffer *b){ - return(b->endbyte*8+b->endbit); -} - -long oggpackB_bytes(oggpack_buffer *b){ - return oggpack_bytes(b); -} - -long oggpackB_bits(oggpack_buffer *b){ - return oggpack_bits(b); -} - -unsigned char *oggpack_get_buffer(oggpack_buffer *b){ - return(b->buffer); -} - -unsigned char *oggpackB_get_buffer(oggpack_buffer *b){ - return oggpack_get_buffer(b); -} - -/* Self test of the bitwise routines; everything else is based on - them, so they damned well better be solid. */ - -#ifdef _V_SELFTEST -#include - -static int ilog(unsigned int v){ - int ret=0; - while(v){ - ret++; - v>>=1; - } - return(ret); -} - -oggpack_buffer o; -oggpack_buffer r; - -void report(char *in){ - fprintf(stderr,"%s",in); - exit(1); -} - -void cliptest(unsigned long *b,int vals,int bits,int *comp,int compsize){ - long bytes,i; - unsigned char *buffer; - - oggpack_reset(&o); - for(i=0;i -#include -#include -#include - -/* A complete description of Ogg framing exists in docs/framing.html */ - -int ogg_page_version(const ogg_page *og){ - return((int)(og->header[4])); -} - -int ogg_page_continued(const ogg_page *og){ - return((int)(og->header[5]&0x01)); -} - -int ogg_page_bos(const ogg_page *og){ - return((int)(og->header[5]&0x02)); -} - -int ogg_page_eos(const ogg_page *og){ - return((int)(og->header[5]&0x04)); -} - -ogg_int64_t ogg_page_granulepos(const ogg_page *og){ - unsigned char *page=og->header; - ogg_int64_t granulepos=page[13]&(0xff); - granulepos= (granulepos<<8)|(page[12]&0xff); - granulepos= (granulepos<<8)|(page[11]&0xff); - granulepos= (granulepos<<8)|(page[10]&0xff); - granulepos= (granulepos<<8)|(page[9]&0xff); - granulepos= (granulepos<<8)|(page[8]&0xff); - granulepos= (granulepos<<8)|(page[7]&0xff); - granulepos= (granulepos<<8)|(page[6]&0xff); - return(granulepos); -} - -int ogg_page_serialno(const ogg_page *og){ - return(og->header[14] | - (og->header[15]<<8) | - (og->header[16]<<16) | - (og->header[17]<<24)); -} - -long ogg_page_pageno(const ogg_page *og){ - return(og->header[18] | - (og->header[19]<<8) | - (og->header[20]<<16) | - (og->header[21]<<24)); -} - - - -/* 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 */ - -/* NOTE: - 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: - ogg_page_packets(page) ==1, - ogg_page_continued(page) !=0 - - 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: - ogg_page_packets(page) ==0, - ogg_page_continued(page) !=0 -*/ - -int ogg_page_packets(const ogg_page *og){ - int i,n=og->header[26],count=0; - for(i=0;iheader[27+i]<255)count++; - return(count); -} - - -#if 0 -/* helper to initialize lookup for direct-table CRC (illustrative; we - use the static init below) */ - -static ogg_uint32_t _ogg_crc_entry(unsigned long index){ - int i; - unsigned long r; - - r = index << 24; - for (i=0; i<8; i++) - if (r & 0x80000000UL) - r = (r << 1) ^ 0x04c11db7; /* The same as the ethernet generator - polynomial, although we use an - unreflected alg and an init/final - of 0, not 0xffffffff */ - else - r<<=1; - return (r & 0xffffffffUL); -} -#endif - -static const ogg_uint32_t crc_lookup[256]={ - 0x00000000,0x04c11db7,0x09823b6e,0x0d4326d9, - 0x130476dc,0x17c56b6b,0x1a864db2,0x1e475005, - 0x2608edb8,0x22c9f00f,0x2f8ad6d6,0x2b4bcb61, - 0x350c9b64,0x31cd86d3,0x3c8ea00a,0x384fbdbd, - 0x4c11db70,0x48d0c6c7,0x4593e01e,0x4152fda9, - 0x5f15adac,0x5bd4b01b,0x569796c2,0x52568b75, - 0x6a1936c8,0x6ed82b7f,0x639b0da6,0x675a1011, - 0x791d4014,0x7ddc5da3,0x709f7b7a,0x745e66cd, - 0x9823b6e0,0x9ce2ab57,0x91a18d8e,0x95609039, - 0x8b27c03c,0x8fe6dd8b,0x82a5fb52,0x8664e6e5, - 0xbe2b5b58,0xbaea46ef,0xb7a96036,0xb3687d81, - 0xad2f2d84,0xa9ee3033,0xa4ad16ea,0xa06c0b5d, - 0xd4326d90,0xd0f37027,0xddb056fe,0xd9714b49, - 0xc7361b4c,0xc3f706fb,0xceb42022,0xca753d95, - 0xf23a8028,0xf6fb9d9f,0xfbb8bb46,0xff79a6f1, - 0xe13ef6f4,0xe5ffeb43,0xe8bccd9a,0xec7dd02d, - 0x34867077,0x30476dc0,0x3d044b19,0x39c556ae, - 0x278206ab,0x23431b1c,0x2e003dc5,0x2ac12072, - 0x128e9dcf,0x164f8078,0x1b0ca6a1,0x1fcdbb16, - 0x018aeb13,0x054bf6a4,0x0808d07d,0x0cc9cdca, - 0x7897ab07,0x7c56b6b0,0x71159069,0x75d48dde, - 0x6b93dddb,0x6f52c06c,0x6211e6b5,0x66d0fb02, - 0x5e9f46bf,0x5a5e5b08,0x571d7dd1,0x53dc6066, - 0x4d9b3063,0x495a2dd4,0x44190b0d,0x40d816ba, - 0xaca5c697,0xa864db20,0xa527fdf9,0xa1e6e04e, - 0xbfa1b04b,0xbb60adfc,0xb6238b25,0xb2e29692, - 0x8aad2b2f,0x8e6c3698,0x832f1041,0x87ee0df6, - 0x99a95df3,0x9d684044,0x902b669d,0x94ea7b2a, - 0xe0b41de7,0xe4750050,0xe9362689,0xedf73b3e, - 0xf3b06b3b,0xf771768c,0xfa325055,0xfef34de2, - 0xc6bcf05f,0xc27dede8,0xcf3ecb31,0xcbffd686, - 0xd5b88683,0xd1799b34,0xdc3abded,0xd8fba05a, - 0x690ce0ee,0x6dcdfd59,0x608edb80,0x644fc637, - 0x7a089632,0x7ec98b85,0x738aad5c,0x774bb0eb, - 0x4f040d56,0x4bc510e1,0x46863638,0x42472b8f, - 0x5c007b8a,0x58c1663d,0x558240e4,0x51435d53, - 0x251d3b9e,0x21dc2629,0x2c9f00f0,0x285e1d47, - 0x36194d42,0x32d850f5,0x3f9b762c,0x3b5a6b9b, - 0x0315d626,0x07d4cb91,0x0a97ed48,0x0e56f0ff, - 0x1011a0fa,0x14d0bd4d,0x19939b94,0x1d528623, - 0xf12f560e,0xf5ee4bb9,0xf8ad6d60,0xfc6c70d7, - 0xe22b20d2,0xe6ea3d65,0xeba91bbc,0xef68060b, - 0xd727bbb6,0xd3e6a601,0xdea580d8,0xda649d6f, - 0xc423cd6a,0xc0e2d0dd,0xcda1f604,0xc960ebb3, - 0xbd3e8d7e,0xb9ff90c9,0xb4bcb610,0xb07daba7, - 0xae3afba2,0xaafbe615,0xa7b8c0cc,0xa379dd7b, - 0x9b3660c6,0x9ff77d71,0x92b45ba8,0x9675461f, - 0x8832161a,0x8cf30bad,0x81b02d74,0x857130c3, - 0x5d8a9099,0x594b8d2e,0x5408abf7,0x50c9b640, - 0x4e8ee645,0x4a4ffbf2,0x470cdd2b,0x43cdc09c, - 0x7b827d21,0x7f436096,0x7200464f,0x76c15bf8, - 0x68860bfd,0x6c47164a,0x61043093,0x65c52d24, - 0x119b4be9,0x155a565e,0x18197087,0x1cd86d30, - 0x029f3d35,0x065e2082,0x0b1d065b,0x0fdc1bec, - 0x3793a651,0x3352bbe6,0x3e119d3f,0x3ad08088, - 0x2497d08d,0x2056cd3a,0x2d15ebe3,0x29d4f654, - 0xc5a92679,0xc1683bce,0xcc2b1d17,0xc8ea00a0, - 0xd6ad50a5,0xd26c4d12,0xdf2f6bcb,0xdbee767c, - 0xe3a1cbc1,0xe760d676,0xea23f0af,0xeee2ed18, - 0xf0a5bd1d,0xf464a0aa,0xf9278673,0xfde69bc4, - 0x89b8fd09,0x8d79e0be,0x803ac667,0x84fbdbd0, - 0x9abc8bd5,0x9e7d9662,0x933eb0bb,0x97ffad0c, - 0xafb010b1,0xab710d06,0xa6322bdf,0xa2f33668, - 0xbcb4666d,0xb8757bda,0xb5365d03,0xb1f740b4}; - -/* init the encode/decode logical stream state */ - -int ogg_stream_init(ogg_stream_state *os,int serialno){ - if(os){ - memset(os,0,sizeof(*os)); - os->body_storage=16*1024; - os->lacing_storage=1024; - - os->body_data=_ogg_malloc(os->body_storage*sizeof(*os->body_data)); - os->lacing_vals=_ogg_malloc(os->lacing_storage*sizeof(*os->lacing_vals)); - os->granule_vals=_ogg_malloc(os->lacing_storage*sizeof(*os->granule_vals)); - - if(!os->body_data || !os->lacing_vals || !os->granule_vals){ - ogg_stream_clear(os); - return -1; - } - - os->serialno=serialno; - - return(0); - } - return(-1); -} - -/* async/delayed error detection for the ogg_stream_state */ -int ogg_stream_check(ogg_stream_state *os){ - if(!os || !os->body_data) return -1; - return 0; -} - -/* _clear does not free os, only the non-flat storage within */ -int ogg_stream_clear(ogg_stream_state *os){ - if(os){ - if(os->body_data)_ogg_free(os->body_data); - if(os->lacing_vals)_ogg_free(os->lacing_vals); - if(os->granule_vals)_ogg_free(os->granule_vals); - - memset(os,0,sizeof(*os)); - } - return(0); -} - -int ogg_stream_destroy(ogg_stream_state *os){ - if(os){ - ogg_stream_clear(os); - _ogg_free(os); - } - return(0); -} - -/* Helpers for ogg_stream_encode; this keeps the structure and - what's happening fairly clear */ - -static int _os_body_expand(ogg_stream_state *os,long needed){ - if(os->body_storage-needed<=os->body_fill){ - long body_storage; - void *ret; - if(os->body_storage>LONG_MAX-needed){ - ogg_stream_clear(os); - return -1; - } - body_storage=os->body_storage+needed; - if(body_storagebody_data,body_storage*sizeof(*os->body_data)); - if(!ret){ - ogg_stream_clear(os); - return -1; - } - os->body_storage=body_storage; - os->body_data=ret; - } - return 0; -} - -static int _os_lacing_expand(ogg_stream_state *os,long needed){ - if(os->lacing_storage-needed<=os->lacing_fill){ - long lacing_storage; - void *ret; - if(os->lacing_storage>LONG_MAX-needed){ - ogg_stream_clear(os); - return -1; - } - lacing_storage=os->lacing_storage+needed; - if(lacing_storagelacing_vals,lacing_storage*sizeof(*os->lacing_vals)); - if(!ret){ - ogg_stream_clear(os); - return -1; - } - os->lacing_vals=ret; - ret=_ogg_realloc(os->granule_vals,lacing_storage* - sizeof(*os->granule_vals)); - if(!ret){ - ogg_stream_clear(os); - return -1; - } - os->granule_vals=ret; - os->lacing_storage=lacing_storage; - } - return 0; -} - -/* checksum the page */ -/* Direct table CRC; note that this will be faster in the future if we - perform the checksum simultaneously with other copies */ - -void ogg_page_checksum_set(ogg_page *og){ - if(og){ - ogg_uint32_t crc_reg=0; - int i; - - /* safety; needed for API behavior, but not framing code */ - og->header[22]=0; - og->header[23]=0; - og->header[24]=0; - og->header[25]=0; - - for(i=0;iheader_len;i++) - crc_reg=(crc_reg<<8)^crc_lookup[((crc_reg >> 24)&0xff)^og->header[i]]; - for(i=0;ibody_len;i++) - crc_reg=(crc_reg<<8)^crc_lookup[((crc_reg >> 24)&0xff)^og->body[i]]; - - og->header[22]=(unsigned char)(crc_reg&0xff); - og->header[23]=(unsigned char)((crc_reg>>8)&0xff); - og->header[24]=(unsigned char)((crc_reg>>16)&0xff); - og->header[25]=(unsigned char)((crc_reg>>24)&0xff); - } -} - -/* submit data to the internal buffer of the framing engine */ -int ogg_stream_iovecin(ogg_stream_state *os, ogg_iovec_t *iov, int count, - long e_o_s, ogg_int64_t granulepos){ - - long bytes = 0, lacing_vals; - int i; - - if(ogg_stream_check(os)) return -1; - if(!iov) return 0; - - for (i = 0; i < count; ++i){ - if(iov[i].iov_len>LONG_MAX) return -1; - if(bytes>LONG_MAX-(long)iov[i].iov_len) return -1; - bytes += (long)iov[i].iov_len; - } - lacing_vals=bytes/255+1; - - if(os->body_returned){ - /* advance packet data according to the body_returned pointer. We - had to keep it around to return a pointer into the buffer last - call */ - - os->body_fill-=os->body_returned; - if(os->body_fill) - memmove(os->body_data,os->body_data+os->body_returned, - os->body_fill); - os->body_returned=0; - } - - /* make sure we have the buffer storage */ - if(_os_body_expand(os,bytes) || _os_lacing_expand(os,lacing_vals)) - return -1; - - /* Copy in the submitted packet. Yes, the copy is a waste; this is - the liability of overly clean abstraction for the time being. It - will actually be fairly easy to eliminate the extra copy in the - future */ - - for (i = 0; i < count; ++i) { - memcpy(os->body_data+os->body_fill, iov[i].iov_base, iov[i].iov_len); - os->body_fill += (int)iov[i].iov_len; - } - - /* Store lacing vals for this packet */ - for(i=0;ilacing_vals[os->lacing_fill+i]=255; - os->granule_vals[os->lacing_fill+i]=os->granulepos; - } - os->lacing_vals[os->lacing_fill+i]=bytes%255; - os->granulepos=os->granule_vals[os->lacing_fill+i]=granulepos; - - /* flag the first segment as the beginning of the packet */ - os->lacing_vals[os->lacing_fill]|= 0x100; - - os->lacing_fill+=lacing_vals; - - /* for the sake of completeness */ - os->packetno++; - - if(e_o_s)os->e_o_s=1; - - return(0); -} - -int ogg_stream_packetin(ogg_stream_state *os,ogg_packet *op){ - ogg_iovec_t iov; - iov.iov_base = op->packet; - iov.iov_len = op->bytes; - return ogg_stream_iovecin(os, &iov, 1, op->e_o_s, op->granulepos); -} - -/* Conditionally flush a page; force==0 will only flush nominal-size - pages, force==1 forces us to flush a page regardless of page size - so long as there's any data available at all. */ -static int ogg_stream_flush_i(ogg_stream_state *os,ogg_page *og, int force, int nfill){ - int i; - int vals=0; - int maxvals=(os->lacing_fill>255?255:os->lacing_fill); - int bytes=0; - long acc=0; - ogg_int64_t granule_pos=-1; - - if(ogg_stream_check(os)) return(0); - if(maxvals==0) return(0); - - /* construct a page */ - /* decide how many segments to include */ - - /* If this is the initial header case, the first page must only include - the initial header packet */ - if(os->b_o_s==0){ /* 'initial header page' case */ - granule_pos=0; - for(vals=0;valslacing_vals[vals]&0x0ff)<255){ - vals++; - break; - } - } - }else{ - - /* The extra packets_done, packet_just_done logic here attempts to do two things: - 1) Don't unneccessarily span pages. - 2) Unless necessary, don't flush pages if there are less than four packets on - them; this expands page size to reduce unneccessary overhead if incoming packets - are large. - These are not necessary behaviors, just 'always better than naive flushing' - without requiring an application to explicitly request a specific optimized - behavior. We'll want an explicit behavior setup pathway eventually as well. */ - - int packets_done=0; - int packet_just_done=0; - for(vals=0;valsnfill && packet_just_done>=4){ - force=1; - break; - } - acc+=os->lacing_vals[vals]&0x0ff; - if((os->lacing_vals[vals]&0xff)<255){ - granule_pos=os->granule_vals[vals]; - packet_just_done=++packets_done; - }else - packet_just_done=0; - } - if(vals==255)force=1; - } - - if(!force) return(0); - - /* construct the header in temp storage */ - memcpy(os->header,"OggS",4); - - /* stream structure version */ - os->header[4]=0x00; - - /* continued packet flag? */ - os->header[5]=0x00; - if((os->lacing_vals[0]&0x100)==0)os->header[5]|=0x01; - /* first page flag? */ - if(os->b_o_s==0)os->header[5]|=0x02; - /* last page flag? */ - if(os->e_o_s && os->lacing_fill==vals)os->header[5]|=0x04; - os->b_o_s=1; - - /* 64 bits of PCM position */ - for(i=6;i<14;i++){ - os->header[i]=(unsigned char)(granule_pos&0xff); - granule_pos>>=8; - } - - /* 32 bits of stream serial number */ - { - long serialno=os->serialno; - for(i=14;i<18;i++){ - os->header[i]=(unsigned char)(serialno&0xff); - serialno>>=8; - } - } - - /* 32 bits of page counter (we have both counter and page header - because this val can roll over) */ - if(os->pageno==-1)os->pageno=0; /* because someone called - stream_reset; this would be a - strange thing to do in an - encode stream, but it has - plausible uses */ - { - long pageno=os->pageno++; - for(i=18;i<22;i++){ - os->header[i]=(unsigned char)(pageno&0xff); - pageno>>=8; - } - } - - /* zero for computation; filled in later */ - os->header[22]=0; - os->header[23]=0; - os->header[24]=0; - os->header[25]=0; - - /* segment table */ - os->header[26]=(unsigned char)(vals&0xff); - for(i=0;iheader[i+27]=(unsigned char)(os->lacing_vals[i]&0xff); - - /* set pointers in the ogg_page struct */ - og->header=os->header; - og->header_len=os->header_fill=vals+27; - og->body=os->body_data+os->body_returned; - og->body_len=bytes; - - /* advance the lacing data and set the body_returned pointer */ - - os->lacing_fill-=vals; - memmove(os->lacing_vals,os->lacing_vals+vals,os->lacing_fill*sizeof(*os->lacing_vals)); - memmove(os->granule_vals,os->granule_vals+vals,os->lacing_fill*sizeof(*os->granule_vals)); - os->body_returned+=bytes; - - /* calculate the checksum */ - - ogg_page_checksum_set(og); - - /* done */ - return(1); -} - -/* This will flush remaining packets into a page (returning nonzero), - even if there is not enough data to trigger a flush normally - (undersized page). If there are no packets or partial packets to - flush, ogg_stream_flush returns 0. Note that ogg_stream_flush will - try to flush a normal sized page like ogg_stream_pageout; a call to - ogg_stream_flush does not guarantee that all packets have flushed. - Only a return value of 0 from ogg_stream_flush indicates all packet - data is flushed into pages. - - since ogg_stream_flush will flush the last page in a stream even if - it's undersized, you almost certainly want to use ogg_stream_pageout - (and *not* ogg_stream_flush) unless you specifically need to flush - a page regardless of size in the middle of a stream. */ - -int ogg_stream_flush(ogg_stream_state *os,ogg_page *og){ - return ogg_stream_flush_i(os,og,1,4096); -} - -/* Like the above, but an argument is provided to adjust the nominal - page size for applications which are smart enough to provide their - own delay based flushing */ - -int ogg_stream_flush_fill(ogg_stream_state *os,ogg_page *og, int nfill){ - return ogg_stream_flush_i(os,og,1,nfill); -} - -/* This constructs pages from buffered packet segments. The pointers -returned are to static buffers; do not free. The returned buffers are -good only until the next call (using the same ogg_stream_state) */ - -int ogg_stream_pageout(ogg_stream_state *os, ogg_page *og){ - int force=0; - if(ogg_stream_check(os)) return 0; - - if((os->e_o_s&&os->lacing_fill) || /* 'were done, now flush' case */ - (os->lacing_fill&&!os->b_o_s)) /* 'initial header page' case */ - force=1; - - return(ogg_stream_flush_i(os,og,force,4096)); -} - -/* Like the above, but an argument is provided to adjust the nominal -page size for applications which are smart enough to provide their -own delay based flushing */ - -int ogg_stream_pageout_fill(ogg_stream_state *os, ogg_page *og, int nfill){ - int force=0; - if(ogg_stream_check(os)) return 0; - - if((os->e_o_s&&os->lacing_fill) || /* 'were done, now flush' case */ - (os->lacing_fill&&!os->b_o_s)) /* 'initial header page' case */ - force=1; - - return(ogg_stream_flush_i(os,og,force,nfill)); -} - -int ogg_stream_eos(ogg_stream_state *os){ - if(ogg_stream_check(os)) return 1; - return os->e_o_s; -} - -/* DECODING PRIMITIVES: packet streaming layer **********************/ - -/* This has two layers to place more of the multi-serialno and paging - control in the application's hands. First, we expose a data buffer - using ogg_sync_buffer(). The app either copies into the - buffer, or passes it directly to read(), etc. We then call - ogg_sync_wrote() to tell how many bytes we just added. - - Pages are returned (pointers into the buffer in ogg_sync_state) - by ogg_sync_pageout(). The page is then submitted to - ogg_stream_pagein() along with the appropriate - ogg_stream_state* (ie, matching serialno). We then get raw - packets out calling ogg_stream_packetout() with a - ogg_stream_state. */ - -/* initialize the struct to a known state */ -int ogg_sync_init(ogg_sync_state *oy){ - if(oy){ - oy->storage = -1; /* used as a readiness flag */ - memset(oy,0,sizeof(*oy)); - } - return(0); -} - -/* clear non-flat storage within */ -int ogg_sync_clear(ogg_sync_state *oy){ - if(oy){ - if(oy->data)_ogg_free(oy->data); - memset(oy,0,sizeof(*oy)); - } - return(0); -} - -int ogg_sync_destroy(ogg_sync_state *oy){ - if(oy){ - ogg_sync_clear(oy); - _ogg_free(oy); - } - return(0); -} - -int ogg_sync_check(ogg_sync_state *oy){ - if(oy->storage<0) return -1; - return 0; -} - -char *ogg_sync_buffer(ogg_sync_state *oy, long size){ - if(ogg_sync_check(oy)) return NULL; - - /* first, clear out any space that has been previously returned */ - if(oy->returned){ - oy->fill-=oy->returned; - if(oy->fill>0) - memmove(oy->data,oy->data+oy->returned,oy->fill); - oy->returned=0; - } - - if(size>oy->storage-oy->fill){ - /* We need to extend the internal buffer */ - long newsize=size+oy->fill+4096; /* an extra page to be nice */ - void *ret; - - if(oy->data) - ret=_ogg_realloc(oy->data,newsize); - else - ret=_ogg_malloc(newsize); - if(!ret){ - ogg_sync_clear(oy); - return NULL; - } - oy->data=ret; - oy->storage=newsize; - } - - /* expose a segment at least as large as requested at the fill mark */ - return((char *)oy->data+oy->fill); -} - -int ogg_sync_wrote(ogg_sync_state *oy, long bytes){ - if(ogg_sync_check(oy))return -1; - if(oy->fill+bytes>oy->storage)return -1; - oy->fill+=bytes; - return(0); -} - -/* sync the stream. This is meant to be useful for finding page - boundaries. - - return values for this: - -n) skipped n bytes - 0) page not ready; more data (no bytes skipped) - n) page synced at current location; page length n bytes - -*/ - -long ogg_sync_pageseek(ogg_sync_state *oy,ogg_page *og){ - unsigned char *page=oy->data+oy->returned; - unsigned char *next; - long bytes=oy->fill-oy->returned; - - if(ogg_sync_check(oy))return 0; - - if(oy->headerbytes==0){ - int headerbytes,i; - if(bytes<27)return(0); /* not enough for a header */ - - /* verify capture pattern */ - if(memcmp(page,"OggS",4))goto sync_fail; - - headerbytes=page[26]+27; - if(bytesbodybytes+=page[27+i]; - oy->headerbytes=headerbytes; - } - - if(oy->bodybytes+oy->headerbytes>bytes)return(0); - - /* The whole test page is buffered. Verify the checksum */ - { - /* Grab the checksum bytes, set the header field to zero */ - char chksum[4]; - ogg_page log; - - memcpy(chksum,page+22,4); - memset(page+22,0,4); - - /* set up a temp page struct and recompute the checksum */ - log.header=page; - log.header_len=oy->headerbytes; - log.body=page+oy->headerbytes; - log.body_len=oy->bodybytes; - ogg_page_checksum_set(&log); - - /* Compare */ - if(memcmp(chksum,page+22,4)){ - /* D'oh. Mismatch! Corrupt page (or miscapture and not a page - at all) */ - /* replace the computed checksum with the one actually read in */ - memcpy(page+22,chksum,4); - - /* Bad checksum. Lose sync */ - goto sync_fail; - } - } - - /* yes, have a whole page all ready to go */ - { - unsigned char *page=oy->data+oy->returned; - long bytes; - - if(og){ - og->header=page; - og->header_len=oy->headerbytes; - og->body=page+oy->headerbytes; - og->body_len=oy->bodybytes; - } - - oy->unsynced=0; - oy->returned+=(bytes=oy->headerbytes+oy->bodybytes); - oy->headerbytes=0; - oy->bodybytes=0; - return(bytes); - } - - sync_fail: - - oy->headerbytes=0; - oy->bodybytes=0; - - /* search for possible capture */ - next=memchr(page+1,'O',bytes-1); - if(!next) - next=oy->data+oy->fill; - - oy->returned=(int)(next-oy->data); - return((long)-(next-page)); -} - -/* sync the stream and get a page. Keep trying until we find a page. - Suppress 'sync errors' after reporting the first. - - return values: - -1) recapture (hole in data) - 0) need more data - 1) page returned - - Returns pointers into buffered data; invalidated by next call to - _stream, _clear, _init, or _buffer */ - -int ogg_sync_pageout(ogg_sync_state *oy, ogg_page *og){ - - if(ogg_sync_check(oy))return 0; - - /* all we need to do is verify a page at the head of the stream - buffer. If it doesn't verify, we look for the next potential - frame */ - - for(;;){ - long ret=ogg_sync_pageseek(oy,og); - if(ret>0){ - /* have a page */ - return(1); - } - if(ret==0){ - /* need more data */ - return(0); - } - - /* head did not start a synced page... skipped some bytes */ - if(!oy->unsynced){ - oy->unsynced=1; - return(-1); - } - - /* loop. keep looking */ - - } -} - -/* add the incoming page to the stream state; we decompose the page - into packet segments here as well. */ - -int ogg_stream_pagein(ogg_stream_state *os, ogg_page *og){ - unsigned char *header=og->header; - unsigned char *body=og->body; - long bodysize=og->body_len; - int segptr=0; - - int version=ogg_page_version(og); - int continued=ogg_page_continued(og); - int bos=ogg_page_bos(og); - int eos=ogg_page_eos(og); - ogg_int64_t granulepos=ogg_page_granulepos(og); - int serialno=ogg_page_serialno(og); - long pageno=ogg_page_pageno(og); - int segments=header[26]; - - if(ogg_stream_check(os)) return -1; - - /* clean up 'returned data' */ - { - long lr=os->lacing_returned; - long br=os->body_returned; - - /* body data */ - if(br){ - os->body_fill-=br; - if(os->body_fill) - memmove(os->body_data,os->body_data+br,os->body_fill); - os->body_returned=0; - } - - if(lr){ - /* segment table */ - if(os->lacing_fill-lr){ - memmove(os->lacing_vals,os->lacing_vals+lr, - (os->lacing_fill-lr)*sizeof(*os->lacing_vals)); - memmove(os->granule_vals,os->granule_vals+lr, - (os->lacing_fill-lr)*sizeof(*os->granule_vals)); - } - os->lacing_fill-=lr; - os->lacing_packet-=lr; - os->lacing_returned=0; - } - } - - /* check the serial number */ - if(serialno!=os->serialno)return(-1); - if(version>0)return(-1); - - if(_os_lacing_expand(os,segments+1)) return -1; - - /* are we in sequence? */ - if(pageno!=os->pageno){ - int i; - - /* unroll previous partial packet (if any) */ - for(i=os->lacing_packet;ilacing_fill;i++) - os->body_fill-=os->lacing_vals[i]&0xff; - os->lacing_fill=os->lacing_packet; - - /* make a note of dropped data in segment table */ - if(os->pageno!=-1){ - os->lacing_vals[os->lacing_fill++]=0x400; - os->lacing_packet++; - } - } - - /* are we a 'continued packet' page? If so, we may need to skip - some segments */ - if(continued){ - if(os->lacing_fill<1 || - (os->lacing_vals[os->lacing_fill-1]&0xff)<255 || - os->lacing_vals[os->lacing_fill-1]==0x400){ - bos=0; - for(;segptrbody_data+os->body_fill,body,bodysize); - os->body_fill+=bodysize; - } - - { - int saved=-1; - while(segptrlacing_vals[os->lacing_fill]=val; - os->granule_vals[os->lacing_fill]=-1; - - if(bos){ - os->lacing_vals[os->lacing_fill]|=0x100; - bos=0; - } - - if(val<255)saved=os->lacing_fill; - - os->lacing_fill++; - segptr++; - - if(val<255)os->lacing_packet=os->lacing_fill; - } - - /* set the granulepos on the last granuleval of the last full packet */ - if(saved!=-1){ - os->granule_vals[saved]=granulepos; - } - - } - - if(eos){ - os->e_o_s=1; - if(os->lacing_fill>0) - os->lacing_vals[os->lacing_fill-1]|=0x200; - } - - os->pageno=pageno+1; - - return(0); -} - -/* clear things to an initial state. Good to call, eg, before seeking */ -int ogg_sync_reset(ogg_sync_state *oy){ - if(ogg_sync_check(oy))return -1; - - oy->fill=0; - oy->returned=0; - oy->unsynced=0; - oy->headerbytes=0; - oy->bodybytes=0; - return(0); -} - -int ogg_stream_reset(ogg_stream_state *os){ - if(ogg_stream_check(os)) return -1; - - os->body_fill=0; - os->body_returned=0; - - os->lacing_fill=0; - os->lacing_packet=0; - os->lacing_returned=0; - - os->header_fill=0; - - os->e_o_s=0; - os->b_o_s=0; - os->pageno=-1; - os->packetno=0; - os->granulepos=0; - - return(0); -} - -int ogg_stream_reset_serialno(ogg_stream_state *os,int serialno){ - if(ogg_stream_check(os)) return -1; - ogg_stream_reset(os); - os->serialno=serialno; - return(0); -} - -static int _packetout(ogg_stream_state *os,ogg_packet *op,int adv){ - - /* The last part of decode. We have the stream broken into packet - segments. Now we need to group them into packets (or return the - out of sync markers) */ - - int ptr=os->lacing_returned; - - if(os->lacing_packet<=ptr)return(0); - - if(os->lacing_vals[ptr]&0x400){ - /* we need to tell the codec there's a gap; it might need to - handle previous packet dependencies. */ - os->lacing_returned++; - os->packetno++; - return(-1); - } - - if(!op && !adv)return(1); /* just using peek as an inexpensive way - to ask if there's a whole packet - waiting */ - - /* Gather the whole packet. We'll have no holes or a partial packet */ - { - int size=os->lacing_vals[ptr]&0xff; - long bytes=size; - int eos=os->lacing_vals[ptr]&0x200; /* last packet of the stream? */ - int bos=os->lacing_vals[ptr]&0x100; /* first packet of the stream? */ - - while(size==255){ - int val=os->lacing_vals[++ptr]; - size=val&0xff; - if(val&0x200)eos=0x200; - bytes+=size; - } - - if(op){ - op->e_o_s=eos; - op->b_o_s=bos; - op->packet=os->body_data+os->body_returned; - op->packetno=os->packetno; - op->granulepos=os->granule_vals[ptr]; - op->bytes=bytes; - } - - if(adv){ - os->body_returned+=bytes; - os->lacing_returned=ptr+1; - os->packetno++; - } - } - return(1); -} - -int ogg_stream_packetout(ogg_stream_state *os,ogg_packet *op){ - if(ogg_stream_check(os)) return 0; - return _packetout(os,op,1); -} - -int ogg_stream_packetpeek(ogg_stream_state *os,ogg_packet *op){ - if(ogg_stream_check(os)) return 0; - return _packetout(os,op,0); -} - -void ogg_packet_clear(ogg_packet *op) { - _ogg_free(op->packet); - memset(op, 0, sizeof(*op)); -} - -#ifdef _V_SELFTEST -#include - -ogg_stream_state os_en, os_de; -ogg_sync_state oy; - -void checkpacket(ogg_packet *op,long len, int no, long pos){ - long j; - static int sequence=0; - static int lastno=0; - - if(op->bytes!=len){ - fprintf(stderr,"incorrect packet length (%ld != %ld)!\n",op->bytes,len); - exit(1); - } - if(op->granulepos!=pos){ - fprintf(stderr,"incorrect packet granpos (%ld != %ld)!\n",(long)op->granulepos,pos); - exit(1); - } - - /* packet number just follows sequence/gap; adjust the input number - for that */ - if(no==0){ - sequence=0; - }else{ - sequence++; - if(no>lastno+1) - sequence++; - } - lastno=no; - if(op->packetno!=sequence){ - fprintf(stderr,"incorrect packet sequence %ld != %d\n", - (long)(op->packetno),sequence); - exit(1); - } - - /* Test data */ - for(j=0;jbytes;j++) - if(op->packet[j]!=((j+no)&0xff)){ - fprintf(stderr,"body data mismatch (1) at pos %ld: %x!=%lx!\n\n", - j,op->packet[j],(j+no)&0xff); - exit(1); - } -} - -void check_page(unsigned char *data,const int *header,ogg_page *og){ - long j; - /* Test data */ - for(j=0;jbody_len;j++) - if(og->body[j]!=data[j]){ - fprintf(stderr,"body data mismatch (2) at pos %ld: %x!=%x!\n\n", - j,data[j],og->body[j]); - exit(1); - } - - /* Test header */ - for(j=0;jheader_len;j++){ - if(og->header[j]!=header[j]){ - fprintf(stderr,"header content mismatch at pos %ld:\n",j); - for(j=0;jheader[j]); - fprintf(stderr,"\n"); - exit(1); - } - } - if(og->header_len!=header[26]+27){ - fprintf(stderr,"header length incorrect! (%ld!=%d)\n", - og->header_len,header[26]+27); - exit(1); - } -} - -void print_header(ogg_page *og){ - int j; - fprintf(stderr,"\nHEADER:\n"); - fprintf(stderr," capture: %c %c %c %c version: %d flags: %x\n", - og->header[0],og->header[1],og->header[2],og->header[3], - (int)og->header[4],(int)og->header[5]); - - fprintf(stderr," granulepos: %d serialno: %d pageno: %ld\n", - (og->header[9]<<24)|(og->header[8]<<16)| - (og->header[7]<<8)|og->header[6], - (og->header[17]<<24)|(og->header[16]<<16)| - (og->header[15]<<8)|og->header[14], - ((long)(og->header[21])<<24)|(og->header[20]<<16)| - (og->header[19]<<8)|og->header[18]); - - fprintf(stderr," checksum: %02x:%02x:%02x:%02x\n segments: %d (", - (int)og->header[22],(int)og->header[23], - (int)og->header[24],(int)og->header[25], - (int)og->header[26]); - - for(j=27;jheader_len;j++) - fprintf(stderr,"%d ",(int)og->header[j]); - fprintf(stderr,")\n\n"); -} - -void copy_page(ogg_page *og){ - unsigned char *temp=_ogg_malloc(og->header_len); - memcpy(temp,og->header,og->header_len); - og->header=temp; - - temp=_ogg_malloc(og->body_len); - memcpy(temp,og->body,og->body_len); - og->body=temp; -} - -void free_page(ogg_page *og){ - _ogg_free (og->header); - _ogg_free (og->body); -} - -void error(void){ - fprintf(stderr,"error!\n"); - exit(1); -} - -/* 17 only */ -const int head1_0[] = {0x4f,0x67,0x67,0x53,0,0x06, - 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,0,0,0,0, - 0x15,0xed,0xec,0x91, - 1, - 17}; - -/* 17, 254, 255, 256, 500, 510, 600 byte, pad */ -const int head1_1[] = {0x4f,0x67,0x67,0x53,0,0x02, - 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,0,0,0,0, - 0x59,0x10,0x6c,0x2c, - 1, - 17}; -const int head2_1[] = {0x4f,0x67,0x67,0x53,0,0x04, - 0x07,0x18,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,1,0,0,0, - 0x89,0x33,0x85,0xce, - 13, - 254,255,0,255,1,255,245,255,255,0, - 255,255,90}; - -/* nil packets; beginning,middle,end */ -const int head1_2[] = {0x4f,0x67,0x67,0x53,0,0x02, - 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,0,0,0,0, - 0xff,0x7b,0x23,0x17, - 1, - 0}; -const int head2_2[] = {0x4f,0x67,0x67,0x53,0,0x04, - 0x07,0x28,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,1,0,0,0, - 0x5c,0x3f,0x66,0xcb, - 17, - 17,254,255,0,0,255,1,0,255,245,255,255,0, - 255,255,90,0}; - -/* large initial packet */ -const int head1_3[] = {0x4f,0x67,0x67,0x53,0,0x02, - 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,0,0,0,0, - 0x01,0x27,0x31,0xaa, - 18, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255,255,10}; - -const int head2_3[] = {0x4f,0x67,0x67,0x53,0,0x04, - 0x07,0x08,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,1,0,0,0, - 0x7f,0x4e,0x8a,0xd2, - 4, - 255,4,255,0}; - - -/* continuing packet test */ -const int head1_4[] = {0x4f,0x67,0x67,0x53,0,0x02, - 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,0,0,0,0, - 0xff,0x7b,0x23,0x17, - 1, - 0}; - -const int head2_4[] = {0x4f,0x67,0x67,0x53,0,0x00, - 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF, - 0x01,0x02,0x03,0x04,1,0,0,0, - 0xf8,0x3c,0x19,0x79, - 255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255}; - -const int head3_4[] = {0x4f,0x67,0x67,0x53,0,0x05, - 0x07,0x0c,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,2,0,0,0, - 0x38,0xe6,0xb6,0x28, - 6, - 255,220,255,4,255,0}; - - -/* spill expansion test */ -const int head1_4b[] = {0x4f,0x67,0x67,0x53,0,0x02, - 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,0,0,0,0, - 0xff,0x7b,0x23,0x17, - 1, - 0}; - -const int head2_4b[] = {0x4f,0x67,0x67,0x53,0,0x00, - 0x07,0x10,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,1,0,0,0, - 0xce,0x8f,0x17,0x1a, - 23, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255,255,10,255,4,255,0,0}; - - -const int head3_4b[] = {0x4f,0x67,0x67,0x53,0,0x04, - 0x07,0x14,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,2,0,0,0, - 0x9b,0xb2,0x50,0xa1, - 1, - 0}; - -/* page with the 255 segment limit */ -const int head1_5[] = {0x4f,0x67,0x67,0x53,0,0x02, - 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,0,0,0,0, - 0xff,0x7b,0x23,0x17, - 1, - 0}; - -const int head2_5[] = {0x4f,0x67,0x67,0x53,0,0x00, - 0x07,0xfc,0x03,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,1,0,0,0, - 0xed,0x2a,0x2e,0xa7, - 255, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10}; - -const int head3_5[] = {0x4f,0x67,0x67,0x53,0,0x04, - 0x07,0x00,0x04,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,2,0,0,0, - 0x6c,0x3b,0x82,0x3d, - 1, - 50}; - - -/* packet that overspans over an entire page */ -const int head1_6[] = {0x4f,0x67,0x67,0x53,0,0x02, - 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,0,0,0,0, - 0xff,0x7b,0x23,0x17, - 1, - 0}; - -const int head2_6[] = {0x4f,0x67,0x67,0x53,0,0x00, - 0x07,0x04,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,1,0,0,0, - 0x68,0x22,0x7c,0x3d, - 255, - 100, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255}; - -const int head3_6[] = {0x4f,0x67,0x67,0x53,0,0x01, - 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF, - 0x01,0x02,0x03,0x04,2,0,0,0, - 0xf4,0x87,0xba,0xf3, - 255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255}; - -const int head4_6[] = {0x4f,0x67,0x67,0x53,0,0x05, - 0x07,0x10,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,3,0,0,0, - 0xf7,0x2f,0x6c,0x60, - 5, - 254,255,4,255,0}; - -/* packet that overspans over an entire page */ -const int head1_7[] = {0x4f,0x67,0x67,0x53,0,0x02, - 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,0,0,0,0, - 0xff,0x7b,0x23,0x17, - 1, - 0}; - -const int head2_7[] = {0x4f,0x67,0x67,0x53,0,0x00, - 0x07,0x04,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,1,0,0,0, - 0x68,0x22,0x7c,0x3d, - 255, - 100, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255,255,255, - 255,255,255,255,255,255}; - -const int head3_7[] = {0x4f,0x67,0x67,0x53,0,0x05, - 0x07,0x08,0x00,0x00,0x00,0x00,0x00,0x00, - 0x01,0x02,0x03,0x04,2,0,0,0, - 0xd4,0xe0,0x60,0xe5, - 1, - 0}; - -int compare_packet(const ogg_packet *op1, const ogg_packet *op2){ - if(op1->packet!=op2->packet){ - fprintf(stderr,"op1->packet != op2->packet\n"); - return(1); - } - if(op1->bytes!=op2->bytes){ - fprintf(stderr,"op1->bytes != op2->bytes\n"); - return(1); - } - if(op1->b_o_s!=op2->b_o_s){ - fprintf(stderr,"op1->b_o_s != op2->b_o_s\n"); - return(1); - } - if(op1->e_o_s!=op2->e_o_s){ - fprintf(stderr,"op1->e_o_s != op2->e_o_s\n"); - return(1); - } - if(op1->granulepos!=op2->granulepos){ - fprintf(stderr,"op1->granulepos != op2->granulepos\n"); - return(1); - } - if(op1->packetno!=op2->packetno){ - fprintf(stderr,"op1->packetno != op2->packetno\n"); - return(1); - } - return(0); -} - -void test_pack(const int *pl, const int **headers, int byteskip, - int pageskip, int packetskip){ - unsigned char *data=_ogg_malloc(1024*1024); /* for scripted test cases only */ - long inptr=0; - long outptr=0; - long deptr=0; - long depacket=0; - long granule_pos=7,pageno=0; - int i,j,packets,pageout=pageskip; - int eosflag=0; - int bosflag=0; - - int byteskipcount=0; - - ogg_stream_reset(&os_en); - ogg_stream_reset(&os_de); - ogg_sync_reset(&oy); - - for(packets=0;packetsbyteskip){ - memcpy(next,og.header,byteskipcount-byteskip); - next+=byteskipcount-byteskip; - byteskipcount=byteskip; - } - - byteskipcount+=og.body_len; - if(byteskipcount>byteskip){ - memcpy(next,og.body,byteskipcount-byteskip); - next+=byteskipcount-byteskip; - byteskipcount=byteskip; - } - - ogg_sync_wrote(&oy,next-buf); - - while(1){ - int ret=ogg_sync_pageout(&oy,&og_de); - if(ret==0)break; - if(ret<0)continue; - /* got a page. Happy happy. Verify that it's good. */ - - fprintf(stderr,"(%d), ",pageout); - - check_page(data+deptr,headers[pageout],&og_de); - deptr+=og_de.body_len; - pageout++; - - /* submit it to deconstitution */ - ogg_stream_pagein(&os_de,&og_de); - - /* packets out? */ - while(ogg_stream_packetpeek(&os_de,&op_de2)>0){ - ogg_stream_packetpeek(&os_de,NULL); - ogg_stream_packetout(&os_de,&op_de); /* just catching them all */ - - /* verify peek and out match */ - if(compare_packet(&op_de,&op_de2)){ - fprintf(stderr,"packetout != packetpeek! pos=%ld\n", - depacket); - exit(1); - } - - /* verify the packet! */ - /* check data */ - if(memcmp(data+depacket,op_de.packet,op_de.bytes)){ - fprintf(stderr,"packet data mismatch in decode! pos=%ld\n", - depacket); - exit(1); - } - /* check bos flag */ - if(bosflag==0 && op_de.b_o_s==0){ - fprintf(stderr,"b_o_s flag not set on packet!\n"); - exit(1); - } - if(bosflag && op_de.b_o_s){ - fprintf(stderr,"b_o_s flag incorrectly set on packet!\n"); - exit(1); - } - bosflag=1; - depacket+=op_de.bytes; - - /* check eos flag */ - if(eosflag){ - fprintf(stderr,"Multiple decoded packets with eos flag!\n"); - exit(1); - } - - if(op_de.e_o_s)eosflag=1; - - /* check granulepos flag */ - if(op_de.granulepos!=-1){ - fprintf(stderr," granule:%ld ",(long)op_de.granulepos); - } - } - } - } - } - } - } - _ogg_free(data); - if(headers[pageno]!=NULL){ - fprintf(stderr,"did not write last page!\n"); - exit(1); - } - if(headers[pageout]!=NULL){ - fprintf(stderr,"did not decode last page!\n"); - exit(1); - } - if(inptr!=outptr){ - fprintf(stderr,"encoded page data incomplete!\n"); - exit(1); - } - if(inptr!=deptr){ - fprintf(stderr,"decoded page data incomplete!\n"); - exit(1); - } - if(inptr!=depacket){ - fprintf(stderr,"decoded packet data incomplete!\n"); - exit(1); - } - if(!eosflag){ - fprintf(stderr,"Never got a packet with EOS set!\n"); - exit(1); - } - fprintf(stderr,"ok.\n"); -} - -int main(void){ - - ogg_stream_init(&os_en,0x04030201); - ogg_stream_init(&os_de,0x04030201); - ogg_sync_init(&oy); - - /* Exercise each code path in the framing code. Also verify that - the checksums are working. */ - - { - /* 17 only */ - const int packets[]={17, -1}; - const int *headret[]={head1_0,NULL}; - - fprintf(stderr,"testing single page encoding... "); - test_pack(packets,headret,0,0,0); - } - - { - /* 17, 254, 255, 256, 500, 510, 600 byte, pad */ - const int packets[]={17, 254, 255, 256, 500, 510, 600, -1}; - const int *headret[]={head1_1,head2_1,NULL}; - - fprintf(stderr,"testing basic page encoding... "); - test_pack(packets,headret,0,0,0); - } - - { - /* nil packets; beginning,middle,end */ - const int packets[]={0,17, 254, 255, 0, 256, 0, 500, 510, 600, 0, -1}; - const int *headret[]={head1_2,head2_2,NULL}; - - fprintf(stderr,"testing basic nil packets... "); - test_pack(packets,headret,0,0,0); - } - - { - /* large initial packet */ - const int packets[]={4345,259,255,-1}; - const int *headret[]={head1_3,head2_3,NULL}; - - fprintf(stderr,"testing initial-packet lacing > 4k... "); - test_pack(packets,headret,0,0,0); - } - - { - /* continuing packet test; with page spill expansion, we have to - overflow the lacing table. */ - const int packets[]={0,65500,259,255,-1}; - const int *headret[]={head1_4,head2_4,head3_4,NULL}; - - fprintf(stderr,"testing single packet page span... "); - test_pack(packets,headret,0,0,0); - } - - { - /* spill expand packet test */ - const int packets[]={0,4345,259,255,0,0,-1}; - const int *headret[]={head1_4b,head2_4b,head3_4b,NULL}; - - fprintf(stderr,"testing page spill expansion... "); - test_pack(packets,headret,0,0,0); - } - - /* page with the 255 segment limit */ - { - - const int packets[]={0,10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,10, - 10,10,10,10,10,10,10,50,-1}; - const int *headret[]={head1_5,head2_5,head3_5,NULL}; - - fprintf(stderr,"testing max packet segments... "); - test_pack(packets,headret,0,0,0); - } - - { - /* packet that overspans over an entire page */ - const int packets[]={0,100,130049,259,255,-1}; - const int *headret[]={head1_6,head2_6,head3_6,head4_6,NULL}; - - fprintf(stderr,"testing very large packets... "); - test_pack(packets,headret,0,0,0); - } - - { - /* test for the libogg 1.1.1 resync in large continuation bug - found by Josh Coalson) */ - const int packets[]={0,100,130049,259,255,-1}; - const int *headret[]={head1_6,head2_6,head3_6,head4_6,NULL}; - - fprintf(stderr,"testing continuation resync in very large packets... "); - test_pack(packets,headret,100,2,3); - } - - { - /* term only page. why not? */ - const int packets[]={0,100,64770,-1}; - const int *headret[]={head1_7,head2_7,head3_7,NULL}; - - fprintf(stderr,"testing zero data page (1 nil packet)... "); - test_pack(packets,headret,0,0,0); - } - - - - { - /* build a bunch of pages for testing */ - unsigned char *data=_ogg_malloc(1024*1024); - int pl[]={0, 1,1,98,4079, 1,1,2954,2057, 76,34,912,0,234,1000,1000, 1000,300,-1}; - int inptr=0,i,j; - ogg_page og[5]; - - ogg_stream_reset(&os_en); - - for(i=0;pl[i]!=-1;i++){ - ogg_packet op; - int len=pl[i]; - - op.packet=data+inptr; - op.bytes=len; - op.e_o_s=(pl[i+1]<0?1:0); - op.granulepos=(i+1)*1000; - - for(j=0;j0)error(); - - /* Test fractional page inputs: incomplete fixed header */ - memcpy(ogg_sync_buffer(&oy,og[1].header_len),og[1].header+3, - 20); - ogg_sync_wrote(&oy,20); - if(ogg_sync_pageout(&oy,&og_de)>0)error(); - - /* Test fractional page inputs: incomplete header */ - memcpy(ogg_sync_buffer(&oy,og[1].header_len),og[1].header+23, - 5); - ogg_sync_wrote(&oy,5); - if(ogg_sync_pageout(&oy,&og_de)>0)error(); - - /* Test fractional page inputs: incomplete body */ - - memcpy(ogg_sync_buffer(&oy,og[1].header_len),og[1].header+28, - og[1].header_len-28); - ogg_sync_wrote(&oy,og[1].header_len-28); - if(ogg_sync_pageout(&oy,&og_de)>0)error(); - - memcpy(ogg_sync_buffer(&oy,og[1].body_len),og[1].body,1000); - ogg_sync_wrote(&oy,1000); - if(ogg_sync_pageout(&oy,&og_de)>0)error(); - - memcpy(ogg_sync_buffer(&oy,og[1].body_len),og[1].body+1000, - og[1].body_len-1000); - ogg_sync_wrote(&oy,og[1].body_len-1000); - if(ogg_sync_pageout(&oy,&og_de)<=0)error(); - - fprintf(stderr,"ok.\n"); - } - - /* Test fractional page inputs: page + incomplete capture */ - { - ogg_page og_de; - fprintf(stderr,"Testing sync on 1+partial inputs... "); - ogg_sync_reset(&oy); - - memcpy(ogg_sync_buffer(&oy,og[1].header_len),og[1].header, - og[1].header_len); - ogg_sync_wrote(&oy,og[1].header_len); - - memcpy(ogg_sync_buffer(&oy,og[1].body_len),og[1].body, - og[1].body_len); - ogg_sync_wrote(&oy,og[1].body_len); - - memcpy(ogg_sync_buffer(&oy,og[1].header_len),og[1].header, - 20); - ogg_sync_wrote(&oy,20); - if(ogg_sync_pageout(&oy,&og_de)<=0)error(); - if(ogg_sync_pageout(&oy,&og_de)>0)error(); - - memcpy(ogg_sync_buffer(&oy,og[1].header_len),og[1].header+20, - og[1].header_len-20); - ogg_sync_wrote(&oy,og[1].header_len-20); - memcpy(ogg_sync_buffer(&oy,og[1].body_len),og[1].body, - og[1].body_len); - ogg_sync_wrote(&oy,og[1].body_len); - if(ogg_sync_pageout(&oy,&og_de)<=0)error(); - - fprintf(stderr,"ok.\n"); - } - - /* Test recapture: garbage + page */ - { - ogg_page og_de; - fprintf(stderr,"Testing search for capture... "); - ogg_sync_reset(&oy); - - /* 'garbage' */ - memcpy(ogg_sync_buffer(&oy,og[1].body_len),og[1].body, - og[1].body_len); - ogg_sync_wrote(&oy,og[1].body_len); - - memcpy(ogg_sync_buffer(&oy,og[1].header_len),og[1].header, - og[1].header_len); - ogg_sync_wrote(&oy,og[1].header_len); - - memcpy(ogg_sync_buffer(&oy,og[1].body_len),og[1].body, - og[1].body_len); - ogg_sync_wrote(&oy,og[1].body_len); - - memcpy(ogg_sync_buffer(&oy,og[2].header_len),og[2].header, - 20); - ogg_sync_wrote(&oy,20); - if(ogg_sync_pageout(&oy,&og_de)>0)error(); - if(ogg_sync_pageout(&oy,&og_de)<=0)error(); - if(ogg_sync_pageout(&oy,&og_de)>0)error(); - - memcpy(ogg_sync_buffer(&oy,og[2].header_len),og[2].header+20, - og[2].header_len-20); - ogg_sync_wrote(&oy,og[2].header_len-20); - memcpy(ogg_sync_buffer(&oy,og[2].body_len),og[2].body, - og[2].body_len); - ogg_sync_wrote(&oy,og[2].body_len); - if(ogg_sync_pageout(&oy,&og_de)<=0)error(); - - fprintf(stderr,"ok.\n"); - } - - /* Test recapture: page + garbage + page */ - { - ogg_page og_de; - fprintf(stderr,"Testing recapture... "); - ogg_sync_reset(&oy); - - memcpy(ogg_sync_buffer(&oy,og[1].header_len),og[1].header, - og[1].header_len); - ogg_sync_wrote(&oy,og[1].header_len); - - memcpy(ogg_sync_buffer(&oy,og[1].body_len),og[1].body, - og[1].body_len); - ogg_sync_wrote(&oy,og[1].body_len); - - memcpy(ogg_sync_buffer(&oy,og[2].header_len),og[2].header, - og[2].header_len); - ogg_sync_wrote(&oy,og[2].header_len); - - memcpy(ogg_sync_buffer(&oy,og[2].header_len),og[2].header, - og[2].header_len); - ogg_sync_wrote(&oy,og[2].header_len); - - if(ogg_sync_pageout(&oy,&og_de)<=0)error(); - - memcpy(ogg_sync_buffer(&oy,og[2].body_len),og[2].body, - og[2].body_len-5); - ogg_sync_wrote(&oy,og[2].body_len-5); - - memcpy(ogg_sync_buffer(&oy,og[3].header_len),og[3].header, - og[3].header_len); - ogg_sync_wrote(&oy,og[3].header_len); - - memcpy(ogg_sync_buffer(&oy,og[3].body_len),og[3].body, - og[3].body_len); - ogg_sync_wrote(&oy,og[3].body_len); - - if(ogg_sync_pageout(&oy,&og_de)>0)error(); - if(ogg_sync_pageout(&oy,&og_de)<=0)error(); - - fprintf(stderr,"ok.\n"); - } - - /* Free page data that was previously copied */ - { - for(i=0;i<5;i++){ - free_page(&og[i]); - } - } - } - - return(0); -} - -#endif diff --git a/ogg/symbian/bld.inf b/ogg/symbian/bld.inf deleted file mode 100644 index 47132c3..0000000 --- a/ogg/symbian/bld.inf +++ /dev/null @@ -1,35 +0,0 @@ -/* - Copyright (C) 2003 Commonwealth Scientific and Industrial Research - Organisation (CSIRO) Australia - - 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 CSIRO Australia 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 ORGANISATION 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. -*/ - -PRJ_MMPFILES - -ogg.mmp diff --git a/ogg/symbian/ogg.mmp b/ogg/symbian/ogg.mmp deleted file mode 100644 index 13b553d..0000000 --- a/ogg/symbian/ogg.mmp +++ /dev/null @@ -1,39 +0,0 @@ -/* - Copyright (C) 2003 Commonwealth Scientific and Industrial Research - Organisation (CSIRO) Australia - - 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 CSIRO Australia 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 ORGANISATION 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. -*/ - -TARGET ogg.lib -TARGETTYPE lib -UID 0 -SOURCEPATH ..\src -SOURCE bitwise.c framing.c -USERINCLUDE . -SYSTEMINCLUDE \epoc32\include \epoc32\include\libc ..\include . diff --git a/ogg/win32/.gitignore b/ogg/win32/.gitignore deleted file mode 100644 index 2655daf..0000000 --- a/ogg/win32/.gitignore +++ /dev/null @@ -1,21 +0,0 @@ -# Visual Studio ignores -[Dd]ebug/ -[Dd]ebugPublic/ -[Rr]elease/ -[Rr]eleases/ -*.manifest -*.lastbuildstate -*.exe -*.log -*.idb -*.ipdb -*.ilk -*.iobj -*.obj -*.pdb -*.sdf -*.suo -*.tlog -*.vcxproj.user -*.vc.db -*.vc.opendb diff --git a/ogg/win32/VS2015/libogg_dynamic.sln b/ogg/win32/VS2015/libogg_dynamic.sln deleted file mode 100644 index be96c40..0000000 --- a/ogg/win32/VS2015/libogg_dynamic.sln +++ /dev/null @@ -1,26 +0,0 @@ - -Microsoft Visual Studio Solution File, Format Version 11.00 -# Visual Studio 2010 -Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "libogg", "libogg_dynamic.vcxproj", "{15CBFEFF-7965-41F5-B4E2-21E8795C9159}" -EndProject -Global - GlobalSection(SolutionConfigurationPlatforms) = preSolution - Debug|Win32 = Debug|Win32 - Debug|x64 = Debug|x64 - Release|Win32 = Release|Win32 - Release|x64 = Release|x64 - EndGlobalSection - GlobalSection(ProjectConfigurationPlatforms) = postSolution - {15CBFEFF-7965-41F5-B4E2-21E8795C9159}.Debug|Win32.ActiveCfg = Debug|Win32 - {15CBFEFF-7965-41F5-B4E2-21E8795C9159}.Debug|Win32.Build.0 = Debug|Win32 - {15CBFEFF-7965-41F5-B4E2-21E8795C9159}.Debug|x64.ActiveCfg = Debug|x64 - {15CBFEFF-7965-41F5-B4E2-21E8795C9159}.Debug|x64.Build.0 = Debug|x64 - {15CBFEFF-7965-41F5-B4E2-21E8795C9159}.Release|Win32.ActiveCfg = Release|Win32 - {15CBFEFF-7965-41F5-B4E2-21E8795C9159}.Release|Win32.Build.0 = Release|Win32 - {15CBFEFF-7965-41F5-B4E2-21E8795C9159}.Release|x64.ActiveCfg = Release|x64 - {15CBFEFF-7965-41F5-B4E2-21E8795C9159}.Release|x64.Build.0 = Release|x64 - EndGlobalSection - GlobalSection(SolutionProperties) = preSolution - HideSolutionNode = FALSE - EndGlobalSection -EndGlobal diff --git a/ogg/win32/VS2015/libogg_dynamic.vcxproj b/ogg/win32/VS2015/libogg_dynamic.vcxproj deleted file mode 100644 index c620cd8..0000000 --- a/ogg/win32/VS2015/libogg_dynamic.vcxproj +++ /dev/null @@ -1,187 +0,0 @@ - - - - - Debug - Win32 - - - Debug - x64 - - - Release - Win32 - - - Release - x64 - - - - libogg - {15CBFEFF-7965-41F5-B4E2-21E8795C9159} - libogg - Win32Proj - - - - DynamicLibrary - Unicode - true - v120 - - - DynamicLibrary - Unicode - v120 - - - DynamicLibrary - Unicode - true - v120 - - - DynamicLibrary - Unicode - v120 - - - - - - - - - - - - - - - - - - - <_ProjectFileVersion>10.0.30319.1 - $(SolutionDir)$(Platform)\$(Configuration)\ - $(SolutionName)\$(Platform)\$(Configuration)\ - $(SolutionDir)$(Platform)\$(Configuration)\ - $(Platform)\$(Configuration)\ - $(SolutionDir)$(Platform)\$(Configuration)\ - $(SolutionName)\$(Platform)\$(Configuration)\ - $(SolutionDir)$(Platform)\$(Configuration)\ - $(Platform)\$(Configuration)\ - - - - Disabled - ..\..\include;%(AdditionalIncludeDirectories) - WIN32;_DEBUG;_WINDOWS;_USRDLL;LIBOGG_EXPORTS;%(PreprocessorDefinitions) - true - EnableFastChecks - MultiThreadedDebugDLL - - - Level4 - ProgramDatabase - CompileAsC - Cdecl - - - ..\ogg.def - - - - - X64 - - - Disabled - ..\..\include;%(AdditionalIncludeDirectories) - WIN32;_DEBUG;_WINDOWS;_USRDLL;LIBOGG_EXPORTS;%(PreprocessorDefinitions) - true - EnableFastChecks - MultiThreadedDebugDLL - - - Level4 - ProgramDatabase - CompileAsC - Cdecl - - - ..\ogg.def - - - - - MaxSpeed - AnySuitable - true - Speed - ..\..\include;%(AdditionalIncludeDirectories) - WIN32;NDEBUG;_WINDOWS;_USRDLL;LIBOGG_EXPORTS;%(PreprocessorDefinitions) - true - - - MultiThreadedDLL - false - - - Level4 - - - CompileAsC - 4244;%(DisableSpecificWarnings) - Cdecl - - - ..\ogg.def - - - - - X64 - - - MaxSpeed - AnySuitable - true - Speed - ..\..\include;%(AdditionalIncludeDirectories) - WIN32;NDEBUG;_WINDOWS;_USRDLL;LIBOGG_EXPORTS;%(PreprocessorDefinitions) - true - - - MultiThreadedDLL - false - - - Level4 - - - CompileAsC - 4244;%(DisableSpecificWarnings) - Cdecl - - - ..\ogg.def - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/ogg/win32/VS2015/libogg_static.sln b/ogg/win32/VS2015/libogg_static.sln deleted file mode 100644 index f62ba92..0000000 --- a/ogg/win32/VS2015/libogg_static.sln +++ /dev/null @@ -1,26 +0,0 @@ - -Microsoft Visual Studio Solution File, Format Version 11.00 -# Visual Studio 2010 -Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "libogg_static", "libogg_static.vcxproj", "{15CBFEFF-7965-41F5-B4E2-21E8795C9159}" -EndProject -Global - GlobalSection(SolutionConfigurationPlatforms) = preSolution - Debug|Win32 = Debug|Win32 - Debug|x64 = Debug|x64 - Release|Win32 = Release|Win32 - Release|x64 = Release|x64 - EndGlobalSection - GlobalSection(ProjectConfigurationPlatforms) = postSolution - {15CBFEFF-7965-41F5-B4E2-21E8795C9159}.Debug|Win32.ActiveCfg = Debug|Win32 - {15CBFEFF-7965-41F5-B4E2-21E8795C9159}.Debug|Win32.Build.0 = Debug|Win32 - {15CBFEFF-7965-41F5-B4E2-21E8795C9159}.Debug|x64.ActiveCfg = Debug|x64 - {15CBFEFF-7965-41F5-B4E2-21E8795C9159}.Debug|x64.Build.0 = Debug|x64 - {15CBFEFF-7965-41F5-B4E2-21E8795C9159}.Release|Win32.ActiveCfg = Release|Win32 - {15CBFEFF-7965-41F5-B4E2-21E8795C9159}.Release|Win32.Build.0 = Release|Win32 - {15CBFEFF-7965-41F5-B4E2-21E8795C9159}.Release|x64.ActiveCfg = Release|x64 - {15CBFEFF-7965-41F5-B4E2-21E8795C9159}.Release|x64.Build.0 = Release|x64 - EndGlobalSection - GlobalSection(SolutionProperties) = preSolution - HideSolutionNode = FALSE - EndGlobalSection -EndGlobal diff --git a/ogg/win32/VS2015/libogg_static.vcxproj b/ogg/win32/VS2015/libogg_static.vcxproj deleted file mode 100644 index b2b99a8..0000000 --- a/ogg/win32/VS2015/libogg_static.vcxproj +++ /dev/null @@ -1,174 +0,0 @@ - - - - - Debug - Win32 - - - Debug - x64 - - - Release - Win32 - - - Release - x64 - - - - {15CBFEFF-7965-41F5-B4E2-21E8795C9159} - libogg - Win32Proj - - - - StaticLibrary - Unicode - true - v140 - - - StaticLibrary - Unicode - v140 - - - StaticLibrary - Unicode - true - v140 - - - StaticLibrary - Unicode - v140 - - - - - - - - - - - - - - - - - - - <_ProjectFileVersion>10.0.30319.1 - $(SolutionDir)$(Platform)\$(Configuration)\ - $(SolutionName)\$(Platform)\$(Configuration)\ - $(SolutionDir)$(Platform)\$(Configuration)\ - $(Platform)\$(Configuration)\ - $(SolutionDir)$(Platform)\$(Configuration)\ - $(SolutionName)\$(Platform)\$(Configuration)\ - $(SolutionDir)$(Platform)\$(Configuration)\ - $(Platform)\$(Configuration)\ - - - - Disabled - ..\..\include;%(AdditionalIncludeDirectories) - WIN32;_DEBUG;_WINDOWS;_USRDLL;LIBOGG_EXPORTS;%(PreprocessorDefinitions) - true - EnableFastChecks - MultiThreadedDebug - - - Level4 - EditAndContinue - CompileAsC - Cdecl - - - - - X64 - - - Disabled - ..\..\include;%(AdditionalIncludeDirectories) - WIN32;_DEBUG;_WINDOWS;_USRDLL;LIBOGG_EXPORTS;%(PreprocessorDefinitions) - true - EnableFastChecks - MultiThreadedDebug - - - Level4 - ProgramDatabase - CompileAsC - Cdecl - - - - - MaxSpeed - AnySuitable - true - Speed - ..\..\include;%(AdditionalIncludeDirectories) - WIN32;NDEBUG;_WINDOWS;_USRDLL;LIBOGG_EXPORTS;%(PreprocessorDefinitions) - true - - - MultiThreaded - false - - - Level4 - - - CompileAsC - 4244;%(DisableSpecificWarnings) - Cdecl - - - - - X64 - - - MaxSpeed - AnySuitable - true - Speed - ..\..\include;%(AdditionalIncludeDirectories) - WIN32;NDEBUG;_WINDOWS;_USRDLL;LIBOGG_EXPORTS;%(PreprocessorDefinitions) - true - - - MultiThreaded - false - - - Level4 - - - CompileAsC - 4244;%(DisableSpecificWarnings) - Cdecl - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/ogg/win32/ogg.def b/ogg/win32/ogg.def deleted file mode 100644 index 250e4ba..0000000 --- a/ogg/win32/ogg.def +++ /dev/null @@ -1,80 +0,0 @@ -; $Id$ -; -; ogg.def -; -LIBRARY -EXPORTS -; -oggpack_writeinit -oggpack_writetrunc -oggpack_writealign -oggpack_writecopy -oggpack_reset -oggpack_writeclear -oggpack_readinit -oggpack_write -oggpack_look -oggpack_look1 -oggpack_adv -oggpack_adv1 -oggpack_read -oggpack_read1 -oggpack_bytes -oggpack_bits -oggpack_get_buffer -; -oggpackB_writeinit -oggpackB_writetrunc -oggpackB_writealign -oggpackB_writecopy -oggpackB_reset -oggpackB_writeclear -oggpackB_readinit -oggpackB_write -oggpackB_look -oggpackB_look1 -oggpackB_adv -oggpackB_adv1 -oggpackB_read -oggpackB_read1 -oggpackB_bytes -oggpackB_bits -oggpackB_get_buffer -; -ogg_stream_packetin -ogg_stream_pageout -ogg_stream_flush -; -ogg_sync_init -ogg_sync_clear -ogg_sync_reset -ogg_sync_destroy -ogg_sync_buffer -ogg_sync_wrote -ogg_sync_pageseek -ogg_sync_pageout -ogg_stream_pagein -ogg_stream_packetout -ogg_stream_packetpeek -; -ogg_stream_init -ogg_stream_clear -ogg_stream_reset -ogg_stream_reset_serialno -ogg_stream_destroy -ogg_stream_eos -ogg_stream_pageout_fill -ogg_stream_flush_fill -; -ogg_page_checksum_set -ogg_page_version -ogg_page_continued -ogg_page_bos -ogg_page_eos -ogg_page_granulepos -ogg_page_serialno -ogg_page_pageno -ogg_page_packets -ogg_packet_clear - - -- cgit v1.1