xiph/ogg

Reference implementation of the Ogg media container

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

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

mkdir build
cd build
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

Testing

This package includes a collection of automated tests. Running them is not part of building nor installation but optional.

Unix-like System or MinGW

If build under automake:

make check

If build under CMake:

make test

or:

ctest

Windows with MSBuild

If build with configuration type "Debug", then:

ctest -C Debug

If build with configuration type "Release", then:

ctest -C Release

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-2019 by the Xiph.Org Foundation https://www.xiph.org/

ogg's Issues

ogg.m4 is useless

everything in the title

Version info in ogg.h

Many other projects (zlib, png, SDL2, ...) embed version info in header file. I think ogg could also benefit from that. Yes, I'm aware of version info in pc files but that's not an option on Windows.

MD5SUMS on releases FTP doesn't contain an entry for v1.3.3

As the title says the https://ftp.osuosl.org/pub/xiph/releases/ogg/MD5SUMS file doesn't contain any entry for the libogg v1.3.3 release.

New release?

When is the next libogg release planned?

The latest release of libFLAC (1.3.3) seems to be incompatible to the latest release of libogg (1.3.4).
The problem apparently has been fixed in the master branch (see also https://gitlab.xiph.org/xiph/ogg/-/issues/1747).

missing ogg_uint64_t in configuration generated by cmake

include/ogg/config_types.h:24:10: error: ‘ogg_uint64_t’ does not name a type; did you mean ‘ogg_int64_t’?
 typedef  ogg_uint64_t;
          ^~~~~~~~~~~~
          ogg_int64_t

I am getting this error on linux, gcc with cmake generated project.
Has the unsigned type been removed?

build system: add meson build system

Hello

meson has some advantages over cmake:

• a bit faster
• a lot nicer syntax, close to python
• better and simpler cross platform support
• Windows support is better
• wrap system for dependencies

Please do not rewrite public history

I'm aware that this github repo is only mirror for git.xiph.org/ogg.git and they had diverged a bit. But it's really bad idea to rewrite history instead of merging.

simplification of code and build system: require C99 and use the [u]int*_t types

What about using C99 standard and its types, instead of checking for all the possible values ? C99 was 23 years old and one can consider that the compilers support it on all the needed platforms

CMake issue when linking ogg library into vorbis

So, first I was struggling with finding Ogg Package. In my project, that is builded with CMake, I have both Ogg and Vorbis repositories as submodules:

/deps/ogg/<ogg repository>
/deps/vorbis/<vorbis repository>
CMakeLists.txt

Alongside others dependencies, I have these two sections dedicated to include Ogg and Vorbis in my CMakeLists.txt

(...)
# OGG
add_subdirectory("deps/ogg")
list( APPEND LINK_LIBRARIES ogg )

# Vorbis
set( OGG_ROOT ${PROJECT_SOURCE_DIR}/deps/ogg )
set( OGG_LIBRARY ogg )
add_subdirectory("deps/vorbis")
list( APPEND LINK_LIBRARIES vorbisfile )
(...)

I took a look at FindOgg.cmake (Vorbis repo) to find out that I should hint OGG_ROOT, but should I have defined OGG_LIBRARY as well? I'm kinda new to CMake so that was a bit confusing to me, since I thought that the point with find_package(Ogg) was to define OGG_LIBRARY. If I don't define OGG_LIBRARY, find_package(Ogg) fails.

Anyway, from here everything works fine until linking stage. I got it working after editing Vorbis's CMakeLists.txt:

(...)
    target_link_libraries(vorbis
        PUBLIC Ogg::ogg
        PRIVATE $<$<BOOL:${HAVE_LIBM}>:m>
    )
(...)

Ogg::ogg was being included simply as "ogg", i.e.:
/usr/bin/g++-9 -g (.....) deps/ogg/libogg.a deps/vorbis/lib/libvorbisfile.a deps/vorbis/lib/libvorbis.a ogg (....)
Is this somehow related to how I defined OGG_LIBRARY? I managed to fix it by changing Ogg::ogg to ${OGG_LIBRARY}:

(...)
    target_link_libraries(vorbis
        PUBLIC ${OGG_LIBRARY}
        PRIVATE $<$<BOOL:${HAVE_LIBM}>:m>
    )
(...)

gcc 7.x warns about overflowing an object's maximum size

In function ‘_os_lacing_expand’,
    inlined from ‘ogg_stream_pagein.constprop’ at framing.c:814:6:
framing.c:215:8: warning: argument 2 range [18446744073709551484, 18446744073709551612] exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
     ret=_ogg_realloc(os->lacing_vals,lacing_storage*sizeof(*os->lacing_vals));
     ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


In file included from framing.c:26:0:
framing.c: In function ‘ogg_stream_pagein.constprop’:
/usr/include/stdlib.h:549:14: note: in a call to allocation function ‘realloc’ declared here
 extern void *realloc (void *__ptr, size_t __size)
              ^~~~~~~

In function ‘_os_lacing_expand’,
    inlined from ‘ogg_stream_pagein.constprop’ at framing.c:814:6:
framing.c:221:8: warning: argument 2 range [18446744073709551352, 18446744073709551608] exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=]
     ret=_ogg_realloc(os->granule_vals,lacing_storage*
     ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                      sizeof(*os->granule_vals));
                      ~~~~~~~~~~~~~~~~~~~~~~~~~~

Feel free to add -Wall -pedantic CFLAGS to help catch these if they're not showing up. Cheers.

OggConfig.cmake.in uses wrong case for OggFound

It should be "Ogg_FOUND" not "OGG_FOUND"

Clang's static code analysis flagged three warnings against the latest master branch

https://github.com/dreamer/dosbox-staging/commit/3a219326b6e01175316ff461d41ec3d4ab556572/checks#step:6:110

2019-09-26T07:58:23.6518222Z analyze-build: INFO: /home/runner/work/dosbox-staging/dosbox-staging/src/libs/decoders/internal/ogg/src/bitwise.c:98:12: warning: Array access (via field 'ptr') results in a null pointer dereference
2019-09-26T07:58:23.6519776Z analyze-build: INFO:   b->ptr[0]|=value<<b->endbit;
2019-09-26T07:58:23.6520495Z analyze-build: INFO:      ~~~   ^
2019-09-26T07:58:23.6521232Z analyze-build: INFO: /home/runner/work/dosbox-staging/dosbox-staging/src/libs/decoders/internal/ogg/src/bitwise.c:209:7: warning: 2nd function call argument is an uninitialized value
2019-09-26T07:58:23.6521886Z analyze-build: INFO:       w(b,(unsigned long)(ptr[i]),8);
2019-09-26T07:58:23.6522659Z analyze-build: INFO:       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2019-09-26T07:58:23.6523468Z analyze-build: INFO: /home/runner/work/dosbox-staging/dosbox-staging/src/libs/decoders/internal/ogg/src/bitwise.c:223:7: warning: 2nd function call argument is an uninitialized value
2019-09-26T07:58:23.6524092Z analyze-build: INFO:       w(b,(unsigned long)(ptr[bytes]),bits);
2019-09-26T07:58:23.6524658Z analyze-build: INFO:       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2019-09-26T07:58:23.6525200Z analyze-build: INFO: 3 warnings generated.

CMake support

Dear All,

since I found no online IRC client to contact the devs of multiple projects, this is my entry point.

I am a user of SFML, a cross-platform GUI project that has an audio module that heavily depends on Xiph.org projects. Since I am an HPC GPGPU developer living on Windows but targeting linux clusters, CMake is the bread and butter for my life, as is for most cross-platform developers. If you are not familiar with it, consider taking a look. I tend to use always the latest unreleased versions of MSVC I need to build most of my own dependencies from source.

SFML has nice CMake support, but it's dependencies do not. While Xiph.org projects do provide some outdated Visual Studio solution files, moving to CMake has a meta-makefile would make life easier on your part too. Creating installer packages with (CPack) and creating unit tests (CTest) or getting distributed build automation (CDash) comes at a few lines of scripting only. CMake is not easily mastered, but pays off in the long run.

I would be willing to conitrubte to CMakeifying libOGG and libFLAC, and based on it other Xiph.org projects could adopt the build system easily. I have been using CMake for a while now for my own projects, and feel that I could put together PROPER CMake support. If you could give me a jump-start as to what platform-specific things are done by the current machinery, I could get started with a prototype, if you see fit.

I am a heavily overburdened person, so the speed at which I could work on this is not much, but I would like to contribute to the greater good.

No CMakeLists inside release archive

The current v1.3.3 release archive doesn't contain the CMake build system.

SUM files update

Hi, please can you update the sum files with new versions of ogg?
https://ftp.osuosl.org/pub/xiph/releases/ogg/ ← MD5SUMS is missing the latest release
Thanks in advance.

Support NUGET

Install-Package ogg-msvc14-x64
Install-Package ogg-msvc14-x86

REF: #24
https://www.nuget.org/packages/ogg-msvc14-x64
https://www.nuget.org/packages/ogg-msvc14-x86

Webp support for thumbnails

Webp is currently a more compact format than jpeg when on lossy compression, same with PNG and lossless compression:
https://github.com/webmproject/libwebp/

Is it possible and viable to implement it for usage on thumbnails with the ogg container, either video or audio?

Tag v1.3.4 release

@tmatth asked me to make a new release. I'm slowly going through the accumulated PRs and issues to get things ready to go.

If you haven't tested the ogg development tree recently, now is a good time!

Gitlab down?

VCPKG is using the gitlab instance to download the latest version. However gitlab returns a 500 see: https://gitlab.xiph.org/xiph/ogg/-/archive/v1.3.5/ogg-v1.3.5.tar.gz

VCPKG ticket: microsoft/vcpkg#31930
microsoft/vcpkg#31927

CMake installs Makefiles in docs directory

Using CMake you get Makefile.* in target docs directory

Tested on FreeBSD 13
vorbis master branch, commit 4e1155cc77a2c672f3dd18f9a32dbf1404693289

simplifications in configure.ac (obsolecent macros)

From the autoconf doc https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html the following macros are obsolecent

• AC_FUNC_MEMCMP
• AC_HEADER_STDC
• AC_C_CONST

GNU Autotools install doesn't place OggConfig.cmake in place

So the problem here is a package maintainer for a distro or some system may not use the CMake build when making their packages, and instead base their process on the Autotools or other build. When this happens, the OggConfig.cmake file will not be in place, and in turn using find_package in other CMake projects in such system won't work.

Also a new release with the recent CMake improvements would be welcome.

ogg.def problem with mingw-w64

when compile with cmake/mingw64 with msys2 shell
ogg.def is used
LIBRARY must be set to libogg, and then the executables will looking for libogg.dll, and not ogg.dll like now

flac and opus don't use a .def, and it works fine
is it necessary to use ogg.def for win32?

install msys2 from msys2.org
install mingw64 toolchain, mingw64 cmake

git clone opus in a dir ......src/opus

cd build/opus
export CFLAGS="-D_FORTIFY_SOURCE=0"
cmake -G "MinGW Makefiles" -DCMAKE_MAKE_PROGRAM=mingw32-make -DWITH_STACK_PROTECTOR=OFF 
-DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=ON -DWITH_OGG=ON  ../../src/opus

if you build libsndfile for example, it will lookfor ogg.dll and not libogg.dll
if you set LIBRARY libogg it will be OK

but it would be simpler to make like flac or opus, withiut a def file

library prefix in MSVC files.

Hello,

currently the MSVC project files define a lib prefix for the ogg library, leading to a libogg.dll shared library, a libogg.lib import library and a libogg_static.lib static library. This is inconsistent with the output generated by CMake, which in the current configuration creates a ogg.dll shared library, a ogg.lib import library and a ogg.lib static library.

But how to fix this? It's possible to change the MSVC projects or to set the prefix in the CMake configuration. The lib prefix isn't removed by the linker during runtime linking so one would always need to link against libogg on windows, making it inconsistent across platforms where you link against ogg, making cross platform builds a bit harder (eg. you would need to update the CMakelists.txt of the vorbis project to search for libogg too instead of just searching for ogg). On the other hand it would break compatibility in the sense that clients who use libogg in their project file, causing link error until the linker dependency is changed from libogg.lib to ogg.lib.

Is there a TODO list in ogg repo?

New feature or function impovement in TODO List. I think it's a good way to attract more developer.