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/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/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/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/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/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 Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1850Inconsistent types for bitstream serial number2017-08-26T14:29:54ZAndrew ChurchInconsistent types for bitstream serial numberDifferent types are used in different places to store an Ogg bitstream serial number: at least int, long, and ogg_uint32_t. The use of int may cause incorrect behavior in environments where int is 16 bits, and the mix of signed and unsi...Different types are used in different places to store an Ogg bitstream serial number: at least int, long, and ogg_uint32_t. The use of int may cause incorrect behavior in environments where int is 16 bits, and the mix of signed and unsigned types is the root cause of issue 1838.
I can see a couple of approaches here:
- Unify everything to "long", and replace the hack in Tremor that mixed 32-bit and 64-bit values with a separate flag variable (which IMHO would be a good idea in any case).
- Unify everything to "ogg_int32_t". This would probably be significantly more invasive, and would break binary compatibility for the ogg_stream_state structure in environments with 64-bit longs. I don't currently know enough about the Ogg/Vorbis code to say whether the latter point is a problem in practice.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1674OGG RFCs in libogg package don't meet Debian DFSG2017-08-26T14:29:54ZMonty MontgomeryOGG RFCs in libogg package don't meet Debian DFSGDebian strips the Ogg RFCs out of the Deb packages due to the RFCs not meeting DFSG.
relevant info:
http://wiki.debian.org/NonFreeIETFDocuments
Debian strips the Ogg RFCs out of the Deb packages due to the RFCs not meeting DFSG.
relevant info:
http://wiki.debian.org/NonFreeIETFDocuments
Monty MontgomeryMonty Montgomery