Ogg issueshttps://gitlab.xiph.org/xiph/ogg/-/issues2017-08-26T14:29:54Zhttps://gitlab.xiph.org/xiph/ogg/-/issues/1581segfault in _oggz_comment_add_byname2017-08-26T14:29:54Zkeelerdasegfault in _oggz_comment_add_bynameoggz_comments_decode calls _oggz_comment_add_byname with "value" as NULL under certain situations. This can then sometimes cause _oggz_comment_add_byname to try to run strcmp on NULL, which fails.oggz_comments_decode calls _oggz_comment_add_byname with "value" as NULL under certain situations. This can then sometimes cause _oggz_comment_add_byname to try to run strcmp on NULL, which fails.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1574assertion failure in oggz_close at oggz.c:218 when scanning corrupted file2018-08-08T17:46:51Zkeelerdaassertion failure in oggz_close at oggz.c:218 when scanning corrupted fileoggz-scan exits with "Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed." when scanning a corrupted file.
oggz-scan exits with "Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed." when scanning a corrupted file.
conradconradhttps://gitlab.xiph.org/xiph/ogg/-/issues/1484[libogg] _os_body_expand uses realloc2017-08-26T14:29:54Zps790809[libogg] _os_body_expand uses reallocrealloc takes too much time when os->body_data is big, because of copying memory.
static void _os_body_expand(ogg_stream_state *os,int needed){
if(os->body_storage<=os-...realloc takes too much time when os->body_data is big, because of copying memory.
static void _os_body_expand(ogg_stream_state *os,int needed){
if(os->body_storage<=os->body_fill+needed){
os->body_storage+=(needed+1024);
os->body_data=_ogg_realloc(os->body_data,os->body_storage*sizeof(*os->body_data));
}
}
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1459libogg configure script - SPARC / Solaris 9 / -mv82017-08-26T14:29:54Ztwigathylibogg configure script - SPARC / Solaris 9 / -mv8When compiling libogg on Solaris 9 SPARC, I found that the configure script would quit halfway through, complaining about a lack of 16 bit types:
"configure: error: No 16 bit type found on this platform!"
Clearly this is a bit crazy.
...When compiling libogg on Solaris 9 SPARC, I found that the configure script would quit halfway through, complaining about a lack of 16 bit types:
"configure: error: No 16 bit type found on this platform!"
Clearly this is a bit crazy.
I had a look at the configure log and found that the -mv8 switch no longer exists. Removing it allowed the configure to complete and the compile to run through cleanly.https://gitlab.xiph.org/xiph/ogg/-/issues/1454Failed to build libogg on OpenSolaris2017-08-26T14:29:54Zbrian.luFailed to build libogg on OpenSolarisFailed to build libogg on OpenSolarisFailed to build libogg on OpenSolarisMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1450fail to build liboggplay on OpenSolaris2017-08-26T14:29:54Zbrian.lufail to build liboggplay on OpenSolarisFailed to build liboggplay on OpenSolarisFailed to build liboggplay on OpenSolarishttps://gitlab.xiph.org/xiph/ogg/-/issues/1433libogg crashes when out of memory2017-08-26T14:29:54Zmgoldlibogg crashes when out of memorylibogg uses pointers returned by malloc, realloc, etc. without checking whether they're null, which will happen when there's no memory available. This causes the application using libogg to segfault; for example,
```
$ ulimit -S -v 11000...libogg uses pointers returned by malloc, realloc, etc. without checking whether they're null, which will happen when there's no memory available. This causes the application using libogg to segfault; for example,
```
$ ulimit -S -v 11000 -c hard
$ vcut vcut-test-tones.ogg a b +1.05
```
segfaults at a memcpy call in ogg_stream_packetin on my system.
Functions should return an error code if they can't allocate memory, so the application can handle this in an appropriate way. Unfortunately, not all functions that allocate memory internally can return error codes, so it may be impossible to fix this in a backwards-compatible way.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1400configure wants C++ although not needed2017-08-26T14:29:54ZGitlab Botconfigure wants C++ although not neededliboggs (1.1.3 tarball from website) configure wants a working C++ compiler installed, but libogg has no parts written in C++. Therefore it's a useless dependency which should be removed.
By patching configure script not to exit if it c...liboggs (1.1.3 tarball from website) configure wants a working C++ compiler installed, but libogg has no parts written in C++. Therefore it's a useless dependency which should be removed.
By patching configure script not to exit if it can't find a C++ compiler (it actually fails the "sanity check", which none can ever pass), I was able to make it build and running. As my autoconf installation is broken I had no chance to cleanly fix this in the source files.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1371[PATCH] libogg-1.1.3 to support building on Haiku2017-08-26T14:29:55Zscottmc2[PATCH] libogg-1.1.3 to support building on HaikuThis patch masks out BeOS workarounds that are not needed for Haiku. Since Haiku also defines !__BEOS!__ we need to mask them out by also checking for !__HAIKU!__
This patch masks out BeOS workarounds that are not needed for Haiku. Since Haiku also defines !__BEOS!__ we need to mask them out by also checking for !__HAIKU!__
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1358libogg-1.1.3 won't build universal dylibs on OS X2017-08-26T14:29:55ZGitlab Botlibogg-1.1.3 won't build universal dylibs on OS XThe libtool created by libogg-1.1.3 doesn't include LTCFLAGS, so it only builds dylibs for the current platform. The libvorbis configure creates a libtool that builds universal binaries properly.
I can build a universal binary my naviga...The libtool created by libogg-1.1.3 doesn't include LTCFLAGS, so it only builds dylibs for the current platform. The libvorbis configure creates a libtool that builds universal binaries properly.
I can build a universal binary my navigating to the src directory after the make is finished and executing:
gcc -dynamiclib -o .libs/libogg.0.5.3.dylib .libs/framing.o .libs/bitwise.o -install_name /usr/local/lib/libogg.0.dylib -compatibility_version 6 -current_version 6.3 -arch i386 -arch ppc -arch ppc64 -arch x86_64
file .libs/libogg.0.5.3.dylib
The initial configure is: (Which s the same that I used for libvorbis)
./configure --disable-dependency-tracking CFLAGS="-arch i386 -arch ppc -arch ppc64 -arch x86_64"Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1353Discordant playback with Watershed2017-08-26T14:29:55ZplmDiscordant playback with WatershedEncoded K.D Lang's Watershed CD to OGG format at a quality setting of 8.1 using the Winamp 5.53 and the Ogg-Vorbis 1.1 encoder. Playback under Windows Winamp 5.53 sounds find. The same audio files playing back under Linux libogg 1.1.3-74...Encoded K.D Lang's Watershed CD to OGG format at a quality setting of 8.1 using the Winamp 5.53 and the Ogg-Vorbis 1.1 encoder. Playback under Windows Winamp 5.53 sounds find. The same audio files playing back under Linux libogg 1.1.3-74 with ogg123, xmms, amorok, etc, the playback is incredibly distorted. (Note this is same computer, same speakers, volume..)
Encoding the audio under Linux with Grip or KaudioCreator results in the same discord when played.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1329BITWISE.C integer types , bugs when compiling, typedef's2017-08-26T14:29:55ZGitlab BotBITWISE.C integer types , bugs when compiling, typedef'sFrom BITWISE.C:
```
/* Read in bits without advancing the bitptr; bits <= 32 */
long oggpackB_look(oggpack_buffer *b,int bits){
unsigned long ret;
int m=32-bits;
bits+=b->endbit;
if(b->endbyte+4>=b->storage){
/* not the ma...From BITWISE.C:
```
/* Read in bits without advancing the bitptr; bits <= 32 */
long oggpackB_look(oggpack_buffer *b,int bits){
unsigned long ret;
int m=32-bits;
bits+=b->endbit;
if(b->endbyte+4>=b->storage){
/* not the main path */
if(b->endbyte*8+bits>b->storage*8)return(-1);
}
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);
}
```
```
/* bits <= 32 */
long oggpackB_read(oggpack_buffer *b,int bits){
long ret;
long m=32-bits;
bits+=b->endbit;
if(b->endbyte+4>=b->storage){
/* not the main path */
ret=-1L;
if(b->endbyte*8+bits>b->storage*8)goto overflow;
}
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);
overflow:
b->ptr+=bits/8;
b->endbyte+=bits/8;
b->endbit=bits&7;
return(ret);
}
```
The stuff seems to be very unstable ... in works with some compilers but not with other ones (fails self-test) :-(
1. Why does the upper function use UNSIGNED, but the lower one SIGNED INT32 for "ret" ? Wouldn't all integers UNSIGNED do the job better ? In my tests YES ...
2. Why do the bit counters (seem to allow values 0...32 only) use an SIGNED INT32 rather than an UINT8 ?
3. What is the difference between "long" and "int" ? Why aren't the TYPEDEF's from OS_TYPES.H used ?
```
typedef short ogg_int16_t;
typedef unsigned short ogg_uint16_t;
typedef int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef __int64 ogg_int64_t;
```
4. "ret&0xffffffffUL" vs "ret&0xffffffff" (no "UL") - intentional ?
5. x=(a>>b)>>c can be done better: x=a>>(b+c) ... except for b=c=16 ... but then 0 is returned :-( Is it useful to pick 0 bits ? If for some reason YES, it might be better to "short-circuit" return 0 for 0 bits, rather than process the complete magic.
6. What exactly is it supposed to do ? Some more detailed comments would be appreciated, "endbit" meaning ... Seems the sophisticated stuff does not do much more than just ONE (!) ASM instruction SHLD/SHRD ;-) So I could replace it with cca 5 lines of inline ASM.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1311Ogg Container Format Wastes Memory2017-08-26T14:29:55Zjoe_somebodyOgg Container Format Wastes MemoryCurrently the maximum page size is 65307 determined by a limit of 255 page segments, times 255 bytes ...
I propose that the page_segments/segment table is replaced by a 16 bit unsigned integer, which won't be any larger in the case of s...Currently the maximum page size is 65307 determined by a limit of 255 page segments, times 255 bytes ...
I propose that the page_segments/segment table is replaced by a 16 bit unsigned integer, which won't be any larger in the case of small pages, but will be smaller in all cases where a page size exceeds 254 bytes. It will also allow a page size of up to 65535 bytes. Maybe this could be internally identified as ogg2?
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1280[PATCH] ogg.m4 is not friendly to disabling2017-08-26T14:29:55Zvapier[PATCH] ogg.m4 is not friendly to disablingsome projects have optional ogg support. like a good project, they just use the ogg.m4 that is provided by libogg. that's when they get screwed :).
ogg.m4 does not provide a way for the user to explicitly state "i do not want ogg supp...some projects have optional ogg support. like a good project, they just use the ogg.m4 that is provided by libogg. that's when they get screwed :).
ogg.m4 does not provide a way for the user to explicitly state "i do not want ogg support". i've cleaned up the ogg.m4 so that if you do --without-ogg, you get the expected behavior. i've also fixed the case where doing --with-ogg causes broken -I/-L flags to get added (yes/lib and yes/include)Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1264autogen version checking broken2017-08-26T14:29:55ZGitlab Botautogen version checking brokenI am runnign Debian etch, and have Automake version 1.10 and aclocal version 1.10. The autogen.sh scripts for ogg in trunk fail to correctly determine the version because VERSIONGREP only looks for a single digit number after the decima...I am runnign Debian etch, and have Automake version 1.10 and aclocal version 1.10. The autogen.sh scripts for ogg in trunk fail to correctly determine the version because VERSIONGREP only looks for a single digit number after the decimal point. The test therefore fails.
This may affect other autogen.sh scripts - I haven't checked.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1235No implementation due to poor documentation2017-08-26T14:29:55ZGitlab BotNo implementation due to poor documentationHi,
I have tried opening a OGG container with FLAC content in many players on Linux, Mac OS, and WinAmp on Windows. There is almost no support what so ever for this file type. Most players fail to recognize metadata (NEED STANDARD!!) in...Hi,
I have tried opening a OGG container with FLAC content in many players on Linux, Mac OS, and WinAmp on Windows. There is almost no support what so ever for this file type. Most players fail to recognize metadata (NEED STANDARD!!) in the FLAC codec, and some fail to playback the file all together.
Tried most recent version of Amarok, Banshee, VLC, MPlayer, Xine, iTunes + XiphQT, WinAmp...
I think this is due to poor documentation on the Xiph website. FLAC's site does OK, but I do think it should be made more promontant in the OGG spesifications how FLAC, Vorbis, and other codecs works. Should be mentioned in the Vorbis documentation that OGG is a container format, and can contain other formats as well.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1219debian/rules has syntax error2017-08-26T14:29:55Zsamyboy1debian/rules has syntax errorI Cannot create a .deb package.
### Actual Result
```
$pkg-buildpackage -rfakeroot
[...]
/bin/sh: -c: line 3: syntax error near unexpected token `fi'
/bin/sh: -c: line 3: `fi'
make: *** [clean] Error 2
```
### Expected result
Creatin...I Cannot create a .deb package.
### Actual Result
```
$pkg-buildpackage -rfakeroot
[...]
/bin/sh: -c: line 3: syntax error near unexpected token `fi'
/bin/sh: -c: line 3: `fi'
make: *** [clean] Error 2
```
### Expected result
Creating a debian package
### How to solve
Uncomment line 87 of debian/rulesMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1120calling _clear functions with already cleared structures results in crash2017-08-26T14:29:55ZGitlab Botcalling _clear functions with already cleared structures results in crashWhen _clear functions (from all ogg libraries, not just libogg) are called with already cleared ogg structures they crash.
It would be very good if i could call, for example, theora_info_clear() with an already cleared theora_info struc...When _clear functions (from all ogg libraries, not just libogg) are called with already cleared ogg structures they crash.
It would be very good if i could call, for example, theora_info_clear() with an already cleared theora_info structure. It simplifies the creation of code paths for error handling, presence or not of certain logic bitstreams and probably other reasons.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1118libogg Version: 1.1.3-2ubuntu1 crash when decoding fuzzed file2007-05-28T08:28:38Zensoniclibogg Version: 1.1.3-2ubuntu1 crash when decoding fuzzed fileAs sam pointed out in his blog
http:||sam.zoy.org/blog/2007-01-16-exposing-file-parsing-vulnerabilities
there is a crash when decoding a fuzzed ogg file in gstreamer.
The related gstreamer report is at
http:||bugzilla.gnome.org/show_bug...As sam pointed out in his blog
http:||sam.zoy.org/blog/2007-01-16-exposing-file-parsing-vulnerabilities
there is a crash when decoding a fuzzed ogg file in gstreamer.
The related gstreamer report is at
http:||bugzilla.gnome.org/show_bug.cgi?id=397229
Unfortunately I don't get a decent backtrace here. The last function called is
ogg_stream_pagein()
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/924Incorrect Headers for Cygwin2006-06-03T22:30:33ZmdmkolbeIncorrect Headers for CygwinThe libogg header [trunk/ogg/include/ogg/os_types.h#11505](../tree/master/trunk/ogg/include/ogg/os_types.h#11505) will not compile on Cygwin because they reference _G_config.h which does not exist on a standard Cygwin install.The libogg header [trunk/ogg/include/ogg/os_types.h#11505](../tree/master/trunk/ogg/include/ogg/os_types.h#11505) will not compile on Cygwin because they reference _G_config.h which does not exist on a standard Cygwin install.Monty MontgomeryMonty Montgomery