Ogg issueshttps://gitlab.xiph.org/xiph/ogg/-/issues2023-09-21T14:30:47Zhttps://gitlab.xiph.org/xiph/ogg/-/issues/2304Bump required CMake version to 3.52023-09-21T14:30:47ZJan Niklas HasseBump required CMake version to 3.5I'm consuming libogg via CMake and get the following warning with the latest CMake:
```
CMake Deprecation Warning at .../libogg/c9aea783bbaf472344144d3f98fb679be58b9eb0/CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMa...I'm consuming libogg via CMake and get the following warning with the latest CMake:
```
CMake Deprecation Warning at .../libogg/c9aea783bbaf472344144d3f98fb679be58b9eb0/CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.
```
Can the version be bumped to `3.5` or the line be changed to `cmake_minimum_required(VERSION 3.0...3.5)`?https://gitlab.xiph.org/xiph/ogg/-/issues/2302cwd autogen broken2021-08-17T08:18:26Zcjhih456cwd autogen brokenHello. I was using ogg install with my program.
So I was install with cwd child process.
But this error has been come.
```
configure.ac:5: installing './compile'
configure.ac:5: installing './config.guess'
configure.ac:5: installing './...Hello. I was using ogg install with my program.
So I was install with cwd child process.
But this error has been come.
```
configure.ac:5: installing './compile'
configure.ac:5: installing './config.guess'
configure.ac:5: installing './config.sub'
configure.ac:9: installing './install-sh'
configure.ac:5: error: required file './ltmain.sh' not found
configure.ac:9: installing './missing'
src/Makefile.am: installing './depcomp'
autoreconf: automake failed with exit status: 1
```
My project's informations.
- langauge: Nodejs
- child process function : exec
- os: Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-53-generic x86_64)
succeed pc
- langauge: Nodejs
- child process function : exec
- os: Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-50-generic x86_64)https://gitlab.xiph.org/xiph/ogg/-/issues/2301[feature request] add (or switch to) meson build system2021-04-14T16:44:43Zvtorri[feature request] add (or switch to) meson build systemWhat do you think of adding the meson build system i see several advantages :
a lot faster than autotools
cross compilation is also easy
syntax a lot nicer than cmake one
honor CFLAGS and LDFLAGS contraryto cmake
regards
Vincent TorriWhat do you think of adding the meson build system i see several advantages :
a lot faster than autotools
cross compilation is also easy
syntax a lot nicer than cmake one
honor CFLAGS and LDFLAGS contraryto cmake
regards
Vincent Torrihttps://gitlab.xiph.org/xiph/ogg/-/issues/2300Check for overflow on growing buffer2020-08-09T22:44:22ZClément BœschCheck for overflow on growing bufferHi,
I came across this code while debugging an issue in libshout (https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2318), and it looked pretty unsafe to me: [0001-framing-check-for-overflow-on-growing-buffer.patch](/uploads/376286...Hi,
I came across this code while debugging an issue in libshout (https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2318), and it looked pretty unsafe to me: [0001-framing-check-for-overflow-on-growing-buffer.patch](/uploads/376286b5321247d4934f85e924bdb2be/0001-framing-check-for-overflow-on-growing-buffer.patch).
One could check that the `oy->storage<0` and similar checks are enough, but I still believe it's safer not to assign the invalid value in the first place.https://gitlab.xiph.org/xiph/ogg/-/issues/2299Invalid shift in oggpack_read()2020-01-29T15:17:19ZMichael NiedermayerInvalid shift in oggpack_read()ossfuzz of ffmpeg - libvorbis (which uses libogg) possibly found a bug in libogg
```
bitwise.c:396:23: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
#0 0x7f3378 in oggpack_read /src/ogg/src/bitwise...ossfuzz of ffmpeg - libvorbis (which uses libogg) possibly found a bug in libogg
```
bitwise.c:396:23: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
#0 0x7f3378 in oggpack_read /src/ogg/src/bitwise.c:396:23
#1 0x7cb1eb in _vorbis_unpack_info /src/vorbis/lib/info.c:212:15
#2 0x7cb0f5 in vorbis_synthesis_headerin /src/vorbis/lib/info.c:409:16
#3 0x4c2d82 in oggvorbis_decode_init /src/ffmpeg/libavcodec/libvorbisdec.c:108:12
```
The code is possibly in need of a cast to unsigned but i have not looked deeply into it.
The full report and 2 testcases are at the link below (this is possible not publically accessible but i can give access to this to anyone from xiph or libogg who wants to look into it). The testcase would require ffmpeg+ossfuzz+libvorbis+libogg in a bloated docker image though sadly, so iam not sure how useful that testcase would be. For me it does not reproduce outside docker.
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18710https://gitlab.xiph.org/xiph/ogg/-/issues/2298include file wrong on macOS2020-11-14T23:54:53ZHelmut K. C. Tessarekinclude file wrong on macOSThe following change in `os_types.h` from ogg **1.3.3**
```
#elif (defined(__APPLE__) && defined(__MACH__)) /* MacOS X Framework build */
# include <inttypes.h>
```
to **1.3.4**
```
#elif (defined(__APPLE__) && defined(__MACH__)) /* M...The following change in `os_types.h` from ogg **1.3.3**
```
#elif (defined(__APPLE__) && defined(__MACH__)) /* MacOS X Framework build */
# include <inttypes.h>
```
to **1.3.4**
```
#elif (defined(__APPLE__) && defined(__MACH__)) /* MacOS X Framework build */
# include <sys/types.h>
```
causes other libs to error out during compile:
eg. for vorbis:
```
CC synthesis.lo
In file included from analysis.c:20:
In file included from /Users/Shared/ffmpeg/sw/include/ogg/ogg.h:24:
/Users/Shared/ffmpeg/sw/include/ogg/os_types.h:75:12: error: unknown type name 'uint16_t'
typedef uint16_t ogg_uint16_t;
^
/Users/Shared/ffmpeg/sw/include/ogg/os_types.h:77:12: error: unknown type name 'uint32_t'
typedef uint32_t ogg_uint32_t;
^
/Users/Shared/ffmpeg/sw/include/ogg/os_types.h:79:12: error: unknown type name 'uint64_t'
typedef uint64_t ogg_uint64_t;
^
CC psy.lo
CC info.lo
3 errors generated.
```
I changed the include file to `stdint.h` and all is fine again.
I'm not sure why someone changed it in the first place, but it broke compiling on macOS.https://gitlab.xiph.org/xiph/ogg/-/issues/2297framing.c: overflow on left shift2019-03-06T21:34:00ZTristan Matthewsframing.c: overflow on left shiftThere's a regression since commit bc82844df068429d209e909da47b1f730b53b689:
```framing.c:239:19: runtime error: left shift of 211 by 24 places cannot be represented in type 'int'```
I found this while generating the corpus for speex wit...There's a regression since commit bc82844df068429d209e909da47b1f730b53b689:
```framing.c:239:19: runtime error: left shift of 211 by 24 places cannot be represented in type 'int'```
I found this while generating the corpus for speex with oss-fuzz:
```
git clone git@github.com:tmatth/oss-fuzz.git
cd oss-fuzz
python infra/helper.py build_image speex
python infra/helper.py build_fuzzers --sanitizer undefined speex
```https://gitlab.xiph.org/xiph/ogg/-/issues/2296docs for ogg_stream_state have wrong type on `pageno` field2019-08-13T15:58:40ZSpencer Russelldocs for ogg_stream_state have wrong type on `pageno` fieldIn the [header file](https://gitlab.xiph.org/xiph/ogg/blob/0acd32d7cabf7e41cc29ea7c2bbffde969ff1ba0/include/ogg/ogg.h#L76) the `pageno` field is a `long`, but in the [docs](https://gitlab.xiph.org/xiph/ogg/blob/0acd32d7cabf7e41cc29ea7c2b...In the [header file](https://gitlab.xiph.org/xiph/ogg/blob/0acd32d7cabf7e41cc29ea7c2bbffde969ff1ba0/include/ogg/ogg.h#L76) the `pageno` field is a `long`, but in the [docs](https://gitlab.xiph.org/xiph/ogg/blob/0acd32d7cabf7e41cc29ea7c2bbffde969ff1ba0/doc/libogg/ogg_stream_state.html#L52) it is listed as an `int`.https://gitlab.xiph.org/xiph/ogg/-/issues/2295ogg double free issue2019-08-14T02:08:40Zniugxogg double free issuethere is an issue in ogg_sync_clear when set the second parameter of ogg_sync_buffer to 1.
test code:
modify line 161 of test/write_read.c of libvorbis-1.3.6 as following:
buffer = ogg_sync_buffer(&oy, 1);there is an issue in ogg_sync_clear when set the second parameter of ogg_sync_buffer to 1.
test code:
modify line 161 of test/write_read.c of libvorbis-1.3.6 as following:
buffer = ogg_sync_buffer(&oy, 1);https://gitlab.xiph.org/xiph/ogg/-/issues/2292Granulepos corruption with large/numerous packets (with test case)2018-08-08T17:39:26ZstenyakGranulepos corruption with large/numerous packets (with test case)I'm having issues when dealing with oggz streams that have certain amount of packets and/or certain packet size.
I have attached a test case.
I have reproduced the problem with:
- msvs2015 compiler
- both 32 and 64 bit
- both libog...I'm having issues when dealing with oggz streams that have certain amount of packets and/or certain packet size.
I have attached a test case.
I have reproduced the problem with:
- msvs2015 compiler
- both 32 and 64 bit
- both liboggz v1.1.1 (git `70b58a45`, from 2010-04-29) and the head of master (git `f49574ed` from 2014-04-24). Repo URL: https://git.xiph.org/liboggz.git
In the attached test case, the file writing phase seems to go OK, at least no errors are returned anywhere.
[main.cpp](/uploads/466511c90df23933511eeb891b507af7/main.cpp)
The writer code is based on the example found here: https://xiph.org/oggz/doc/group__force__feed.html#details
The reading phase is more problematic:
- Passing the file through oggz-validate.exe (as downloaded from https://xiph.org/oggz ) crashes with an Out of Memory error
- Using oggz-dump.exe instead, it seems to read all packets correctly, and output the expected granule positions
- The attached source code is unable to finish without errors though.
To verify the problem, follow these steps:
1. Compile the code as-is, in debug mode (to run all asserts). Everything should go ok. The resulting file `foo.oggz` will be around 160 megs.
2. Set `FAIL = true`, compile and run. An assert will fail, around packet #491. The granule position is corrupted now.
3. Decrease packetSize 1 byte (setting it to `packetSize = 163388`), compile and run. Granule position will be okay again, all asserts will pass.
So it seems that both amount of packets and size of packets can contribute to the corrupted granulepos.
If you need any help reproducing the issue, please let me know.https://gitlab.xiph.org/xiph/ogg/-/issues/2290liboggplay mishandles live ogg streams in Firefox2020-11-06T04:06:07ZMilesliboggplay mishandles live ogg streams in Firefox(speculation)
See the following bug on Mozilla's tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=611519
Seems pretty likely the bug is actually in liboggplay. When an audio element points to a live stream and it is played in the...(speculation)
See the following bug on Mozilla's tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=611519
Seems pretty likely the bug is actually in liboggplay. When an audio element points to a live stream and it is played in the browser, it works fine for roughly 20 minutes before severe stutter sets in. Pressing play also tends to play permanently cached audio instead of the actual stream. Is liboggplay perhaps treating this case as an infinitely large file transfer instead of a live stream?Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/2260Buffer overflow in liboggz, httpdate.c, function httpdate_parse2018-08-08T17:44:41ZhannoBuffer overflow in liboggz, httpdate.c, function httpdate_parseThe function httpdate_parse writes 4 bytes to the three byte variables wday and month. These are supposed to store a 3 byte string, however that misses that the string needs a null terminating byte. Making the variables 4 bytes fixes thi...The function httpdate_parse writes 4 bytes to the three byte variables wday and month. These are supposed to store a 3 byte string, however that misses that the string needs a null terminating byte. Making the variables 4 bytes fixes this.
Also the parser string should limit the size of the month string. See attached patch.
This bug was found with the help of address sanitizer. Can be reproduced by compiling liboggz with -fsanitize=address in CFLAGS+LDFLAGS and running make check.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/2228vorbisfile.c function ov_pcm_total add const to OggVorbis_File *2017-08-26T14:29:54Zirov13vorbisfile.c function ov_pcm_total add const to OggVorbis_File *subjsubjMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/2197Ten off by one errors ?2019-08-13T16:56:04ZDavid BindermanTen off by one errors ?[timespec.c:123]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it.
[timespec.c:127]: (error) Width 16 given in format string (no. 1) is larger than dest...[timespec.c:123]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it.
[timespec.c:127]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it.
[timespec.c:131]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it.
[timespec.c:135]:
timespec.c:139
timespec.c:143
timespec.c:147
timespec.c:151
timespec.c:155Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/2043ogg-index produces multiple fisbones with the same name and role, where the i...2020-11-06T04:02:56ZNick Burchogg-index produces multiple fisbones with the same name and role, where the input has several video or audio streamsIf you use OggIndex on a file without a Skeleton stream, which has one Vorbis and one Theora stream in it, the resultant Skeleton fisbones will be correct. However, if you use it on a file with multiple Theora or Vorbis streams, it will ...If you use OggIndex on a file without a Skeleton stream, which has one Vorbis and one Theora stream in it, the resultant Skeleton fisbones will be correct. However, if you use it on a file with multiple Theora or Vorbis streams, it will generate incorrect fisbones for the second and subsequent streams of the type, as it hard codes the name and role
Instead, OggIndex should check which stream this is of a given type, and use that to assign sequential names (eg audio_1, audio_2) rather than hardcoded (eg audio_1 for everything), and flag subsequent streams of a type as alternate ones (rather than hard coded as the main one)https://gitlab.xiph.org/xiph/ogg/-/issues/2042ogg-index fails with an unhelpful error message if the file contains Speex or...2020-11-06T04:03:32ZNick Burchogg-index fails with an unhelpful error message if the file contains Speex or Opus streamsIf you try running ogg-index on a file which contains Opus or Speex streams (eg a Theora + Opus file), then you get a rather unfriendly error such as
`FAIL: Unhandled stream type, serialno=478384172 aborting indexing!`
Where the stream...If you try running ogg-index on a file which contains Opus or Speex streams (eg a Theora + Opus file), then you get a rather unfriendly error such as
`FAIL: Unhandled stream type, serialno=478384172 aborting indexing!`
Where the stream number is that of the Speex or Opus stream
Assuming it's not trivial to add support for those formats, it would be nice if ogg-index could instead give a more helpful message such as _Opus not supported (stream serialno=478384172) - aborting indexing! _https://gitlab.xiph.org/xiph/ogg/-/issues/2041ogg-index sets incorrect fisbone message header offset in the skeleton stream2020-11-06T04:05:16ZNick Burchogg-index sets incorrect fisbone message header offset in the skeleton streamAccording to http://svn.annodex.net/standards/draft-pfeiffer-oggskeleton-current.txt , in the skeleton fisbone,
> Offset to message header fields: 4 Byte unsigned integer that
> contains the number of Bytes used in this packet before t...According to http://svn.annodex.net/standards/draft-pfeiffer-oggskeleton-current.txt , in the skeleton fisbone,
> Offset to message header fields: 4 Byte unsigned integer that
> contains the number of Bytes used in this packet before the
> message header fields. For the version of the skeleton
> bitstream described in this document this number is fixed to 44.
The skeleton stream generated by things like ffmpeg2theora and speexenc set the message header offset to be 44, which is the position less the fisbone\0 header
However, ogg-index creates fisbones where the message header offset is 0x2c=52, which is the offset including the fisbone\0 header, which (based on the docs) seems to be incorrect
Note that it is only the offset that is wrong, the message headers start in the expected place at 44 bytes after the fisbone header / 52 bytes after the start of the fisbone packet datahttps://gitlab.xiph.org/xiph/ogg/-/issues/1970build fails using libtool2020-11-06T03:58:06ZJohn T. Vonachenbuild fails using libtoolWhile building libogg for use with sox, build for libogg version 1.3.1 failed with the following output:
make all-recursive
make[1]: Entering directory `/root/kalebmusic/libogg-1.3.1'
Making all in src
make[2]: Entering directory `/roo...While building libogg for use with sox, build for libogg version 1.3.1 failed with the following output:
make all-recursive
make[1]: Entering directory `/root/kalebmusic/libogg-1.3.1'
Making all in src
make[2]: Entering directory `/root/kalebmusic/libogg-1.3.1/src'
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT framing.lo -MD -MP -MF .deps/framing.Tpo -c -o framing.lo framing.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT framing.lo -MD -MP -MF .deps/framing.Tpo -c framing.c -fPIC -DPIC -o .libs/framing.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT framing.lo -MD -MP -MF .deps/framing.Tpo -c framing.c -o framing.o >/dev/null 2>&1
mv -f .deps/framing.Tpo .deps/framing.Plo
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT bitwise.lo -MD -MP -MF .deps/bitwise.Tpo -c -o bitwise.lo bitwise.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT bitwise.lo -MD -MP -MF .deps/bitwise.Tpo -c bitwise.c -fPIC -DPIC -o .libs/bitwise.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT bitwise.lo -MD -MP -MF .deps/bitwise.Tpo -c bitwise.c -o bitwise.o >/dev/null 2>&1
mv -f .deps/bitwise.Tpo .deps/bitwise.Plo
/bin/bash ../libtool --tag=CC --mode=link gcc -O20 -Wall -ffast-math -fsigned-char -g -O2 -no-undefined -version-info 8:1:8 -o libogg.la -rpath /usr/local/lib framing.lo bitwise.lo
../libtool: eval: line 6444: unexpected EOF while looking for matching `''
../libtool: eval: line 6445: syntax error: unexpected end of file
make[2]: *** [libogg.la] Error 2
make[2]: Leaving directory `/root/kalebmusic/libogg-1.3.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/kalebmusic/libogg-1.3.1'
make: *** [all] Error 2Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1921Build with automake-1.13 broken2019-08-13T16:36:06ZMarko LindqvistBuild with automake-1.13 brokenAutomake-1.13 removed long obsolete AM_CONFIG_HEADER completely ( http://lists.gnu.org/archive/html/automake/2012-12/msg00038.html ) and errors out upon seeing it.
Attached patch replaces it with proper AC_CONFIG_HEADERS.Automake-1.13 removed long obsolete AM_CONFIG_HEADER completely ( http://lists.gnu.org/archive/html/automake/2012-12/msg00038.html ) and errors out upon seeing it.
Attached patch replaces it with proper AC_CONFIG_HEADERS.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1917ogg.m4 sets OGG_LIBS to incorrect path on some 64-bit distros2017-08-26T14:29:54ZAdam Spiersogg.m4 sets OGG_LIBS to incorrect path on some 64-bit distrosSome distros such as openSUSE use /usr/lib64 rather than /usr/lib, but ogg.m4 does not allow for this. I notice that whoever packaged ogg.m4 for openSUSE opted for hacking a patch into the spec file which is only applied on x86_64:
htt...Some distros such as openSUSE use /usr/lib64 rather than /usr/lib, but ogg.m4 does not allow for this. I notice that whoever packaged ogg.m4 for openSUSE opted for hacking a patch into the spec file which is only applied on x86_64:
https://build.opensuse.org/package/view_file?expand=1&file=libogg.spec&package=libogg&project=openSUSE%3AFactory
https://build.opensuse.org/package/view_file?expand=1&file=lib64.dif&package=libogg&project=openSUSE%3AFactory
Personally it's better if ogg.m4 itself is fixed, because then it works even when not building rpms. I'll attach a suggested patch ...
Monty MontgomeryMonty Montgomery