Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2006-06-12T11:13:55Zhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/72Unable to compile vorbis-tools due to problems with libgetopt2006-06-12T11:13:55ZelifarleyUnable to compile vorbis-tools due to problems with libgetopt```
I'm using MacOS X 10.1
cc -fno-common -O4 -Wall -fsigned-char -ffast-math -o oggenc oggenc.o audio.o
encode.o platform.o -L/usr/local/lib -lvorbisenc -lvorbis -lm -logg
../share/libutf8.a ../share/libgetopt.a
/usr/bin/ld: multiple ...```
I'm using MacOS X 10.1
cc -fno-common -O4 -Wall -fsigned-char -ffast-math -o oggenc oggenc.o audio.o
encode.o platform.o -L/usr/local/lib -lvorbisenc -lvorbis -lm -logg
../share/libutf8.a ../share/libgetopt.a
/usr/bin/ld: multiple definitions of symbol _getopt
/usr/lib/libm.dylib(getopt.o) definition of _getopt
../share/libgetopt.a(getopt.o) definition of _getopt in section (__TEXT,__text)
/usr/bin/ld: multiple definitions of symbol _optarg
/usr/lib/libm.dylib(getopt.o) definition of _optarg
../share/libgetopt.a(getopt.o) definition of _optarg in section (__DATA,__common)
/usr/bin/ld: multiple definitions of symbol _opterr
/usr/lib/libm.dylib(getopt.o) definition of _opterr
../share/libgetopt.a(getopt.o) definition of _opterr in section (__DATA,__data)
/usr/bin/ld: multiple definitions of symbol _optind
/usr/lib/libm.dylib(getopt.o) definition of _optind
../share/libgetopt.a(getopt.o) definition of _optind in section (__DATA,__data)
/usr/bin/ld: multiple definitions of symbol _optopt
/usr/lib/libm.dylib(getopt.o) definition of _optopt
../share/libgetopt.a(getopt.o) definition of _optopt in section (__DATA,__data)
make[2]: *** [oggenc] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2386Unable to disable SSL build in libshout-2.4.32020-10-01T18:33:57ZNight GryphonUnable to disable SSL build in libshout-2.4.3./configure --without-openssl
still do ssl tests and add
#define HAVE_OPENSSL 1
to config.h which cause tls.c and other unwanted ssl stuff to build in to library./configure --without-openssl
still do ssl tests and add
#define HAVE_OPENSSL 1
to config.h which cause tls.c and other unwanted ssl stuff to build in to libraryhttps://gitlab.xiph.org/xiph/xiph-qt/-/issues/1077Unable to play H.264 video from ogg2007-03-24T00:48:54ZGitlab BotUnable to play H.264 video from oggI've used VirtualDubMod and x264 codec to create video file. Mac QuickTime (10.4.7 PPC) opens the file, but doesn't play it - movie appears to be empty ('movie properties' shows one empty stream (0kbs, N/A, N/A... etc.))
File works fine...I've used VirtualDubMod and x264 codec to create video file. Mac QuickTime (10.4.7 PPC) opens the file, but doesn't play it - movie appears to be empty ('movie properties' shows one empty stream (0kbs, N/A, N/A... etc.))
File works fine in MPlayerOSX and VLC.
Arek KorbikArek Korbikhttps://gitlab.xiph.org/xiph/Infrastructure/-/issues/108Unable to select libao 0.8.2 on bug submission page2017-04-07T12:17:40ZgshangUnable to select libao 0.8.2 on bug submission page```
In the pulldown menu for version on the audio core library bug submit page, the highest version one can select is 0.8.1.
``````
In the pulldown menu for version on the audio core library bug submit page, the highest version one can select is 0.8.1.
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/vorbis/-/issues/77unaligned access on 64-bit platform2019-07-01T08:51:48Zchouserunaligned access on 64-bit platform```
I was getting the following error when playing some (not all) ogg vorbis streams:
Unaligned access pid=54825 <ogg123> va=0x11fff96b4 pc=0x3ffbffe9ba0
ra=0x3ff801b4b68 inst=0xa6100000
Segmentation fault (core dumped)
The crash is ha...```
I was getting the following error when playing some (not all) ogg vorbis streams:
Unaligned access pid=54825 <ogg123> va=0x11fff96b4 pc=0x3ffbffe9ba0
ra=0x3ff801b4b68 inst=0xa6100000
Segmentation fault (core dumped)
The crash is happening in icomp(), lib/floor1.c. I tracked it down to the qsort
that calls icomp() passing an incorrect size argument. It uses sizeof(int) when
it means sizeof(int*). This only shows up on machines where a pointer is begger
than an int, that is generally 64-bit platforms.
Here is a patch for 1.0rc2 -- I couldn't determine if you've already fixed this
problem because I wasn't able to get anon cvs working.
--- lib/floor1.c.orig Mon Aug 13 07:33:39 2001
+++ lib/floor1.c Fri Nov 9 15:29:56 2001
@@ -226,7 +226,7 @@
/* also store a sorted position index */
for(i=0;i<n;i++)sortpointer[i]=info->postlist+i;
- qsort(sortpointer,n,sizeof(int),icomp);
+ qsort(sortpointer,n,sizeof(int*),icomp);
/* points from sort order back to range number */
for(i=0;i<n;i++)look->forward_index[i]=sortpointer[i]-info->postlist;
--Chouser
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2329Unbreak shout.pc (on non-GNU systems)2021-04-16T12:46:56ZMoritz GrimmUnbreak shout.pc (on non-GNU systems)The pkgconfig file shout.pc contains a list of requirements starting with an empty value:
`Requires.private: , ogg, vorbis, theora, speex, libssl`
This is not well-formed and doesn't work with pkgconfig on OpenBSD (for example). Since ...The pkgconfig file shout.pc contains a list of requirements starting with an empty value:
`Requires.private: , ogg, vorbis, theora, speex, libssl`
This is not well-formed and doesn't work with pkgconfig on OpenBSD (for example). Since libogg is a must-have dependency, the simple fix is to just start the list with it.
Patch: [libshout_proper_shout_pc.diff](/uploads/5cf7acd7e02ea62a9712a79375a6b663/libshout_proper_shout_pc.diff)https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/185Unconditional include of stdint.h2005-05-01T22:24:56ZnickUnconditional include of stdint.h```
I think stdint.h is a linux-ism, and certainly in the configure script,
including of this file is conditional, as follows:
#include <sys/types.h>
#ifdef HAVE_STDINT_H
# include <stdint.h>
#elif defined (HAVE_INTTYPES_H)
# include ...```
I think stdint.h is a linux-ism, and certainly in the configure script,
including of this file is conditional, as follows:
#include <sys/types.h>
#ifdef HAVE_STDINT_H
# include <stdint.h>
#elif defined (HAVE_INTTYPES_H)
# include <inttypes.h>
#endif
Although, as always, I'm never sure if this is because autoconf/libtool is
outta date on my system. I'm pretty sure they dont generally touch the contents
of .c files, so I think this is a valid bug.
Nick
```Segher BoessenkoolSegher Boessenkoolhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2322Uncontrolled alloca() in oggenc which may lead to a remote code execution in ...2018-09-17T19:57:06ZJaeseung ChoiUncontrolled alloca() in oggenc which may lead to a remote code execution in 32-bit environmentDuring a fuzz testing, I found a program-crashing bug in the latest version of `oggenc`. When a malicious AIFF audio file is provided as an input, segmentation fault or remote code execution may occur.
I downloaded http://downloads.xiph...During a fuzz testing, I found a program-crashing bug in the latest version of `oggenc`. When a malicious AIFF audio file is provided as an input, segmentation fault or remote code execution may occur.
I downloaded http://downloads.xiph.org/releases/vorbis/vorbis-tools-1.4.0.tar.gz file, and compiled it with clang 3.8.
In `aiff_open()` function of `oggenc/audio.c` file, size argument of alloca() call is not checked tightly, and therefore a large size of memory can be requested.
```
if(!find_aiff_chunk(in, "COMM", &len))
{
fprintf(stderr, _("Warning: No common chunk found in AIFF file\n"));
return 0; /* EOF before COMM chunk */
}
if(len < 18)
{
fprintf(stderr, _("Warning: Truncated common chunk in AIFF header\n"));
return 0; /* Weird common chunk */
}
buffer = alloca(len);
if(fread(buffer,1,len,in) < len)
{
fprintf(stderr, _("Warning: Unexpected EOF in reading AIFF header\n"));
return 0;
}
```
In 64-bit environment, this will simply make the program to crash, but in 32-bit environment this bug can lead to a remote code execution. If a malicious attacker requests a large size of memory (e.g. alloca(0xffffff00)), this will **lift up** the stack pointer (%esp register) instead of correctly allocating a stack buffer. Then, the subsequent fread() call will overwrite the stack and corrupt the saved return address.
I attach the PoC input file to reproduce this bug.
[poc](/uploads/ab90d639d90d2fca08ddbb6e787f8522/poc)
```
jason@debian-stretch:~/ground/vorbis-tools-1.4.0$ gdb oggenc/oggenc -q
Reading symbols from oggenc/oggenc...done.
(gdb) run ~/poc
Starting program: /home/jason/ground/vorbis-tools-1.4.0/oggenc/oggenc ~/poc
Warning: Unexpected EOF in reading AIFF header
Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
(gdb) info reg $eip
eip 0x41414141 0x41414141
```https://gitlab.xiph.org/xiph/vorbis/-/issues/327Undefined variable used in high level residue decode pseudo code2017-04-08T11:08:16ZjripleyUndefined variable used in high level residue decode pseudo code```
Under "Audio packet decode and synthesis - residue decode":
[channels_in_bundle] isn't defined anywhere, and it should most likely be [ch].
``````
Under "Audio packet decode and synthesis - residue decode":
[channels_in_bundle] isn't defined anywhere, and it should most likely be [ch].
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1140unhelpful underrun messages on stderr (stdout?)2010-01-28T11:53:45ZGitlab Botunhelpful underrun messages on stderr (stdout?)When using a program which links in libao, messages like these are common:
`ALSA: underrun, at leaast 0ms`
The problems with these messages are:
1. The program creating the message is not identified
2. The library creating the mes...When using a program which links in libao, messages like these are common:
`ALSA: underrun, at leaast 0ms`
The problems with these messages are:
1. The program creating the message is not identified
2. The library creating the message is not identified
3. The library is creating these messages without the linking program's permission
4. The program may have a graphical interface, or a network interface, and thus standard out/error are the wrong place for informational messages.
5. This occurs during normal operation, when there is no error
* The system may not even have sound output enabled, making this extra-useless.
6. Can you get a negative time underrun?
#### Suggestions
Small improvement::
Clearly label this message as coming from libao, so that it can be identified.
Nicer improvement::
Label this message as coming form libao, but also identify the process generating the message. The program name would be nice, but just the PID would be a start.
Best improvement::
Unless this library is built or initialized in a special debug manner, do not print these messages at all, anywhere. They typically appear on terminals in active use by other programs, and even appear when the programmer of a tool has provided a -q for quiet mode and has carefully avoided sending any output to standard output or error, only to have her or his goals broken by libao, perhaps multiple libraries away.
Optionally, if you think sending them somewhere by default is really important, please provide some way users of programs (not developers against the library!) can specify where these messages are sent. EG. export LIBAO_WARNINGS_LOGFILE=/dev/null
Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2396Unifiy <xsl:output>-settings for web/ and admin/2020-10-09T16:38:28ZPhilipp SchafftUnifiy <xsl:output>-settings for web/ and admin/`<xsl:output>`-settings must match web/ and admin/ as they share some templates.`<xsl:output>`-settings must match web/ and admin/ as they share some templates.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/theora/-/issues/1336uninitialised theora_info values2008-10-14T20:50:18ZGitlab Botuninitialised theora_info valuesOpening a ticket, just in case this problem was forgotten:
http://lists.xiph.org/pipermail/theora-dev/2008-January/003519.htmlOpening a ticket, just in case this problem was forgotten:
http://lists.xiph.org/pipermail/theora-dev/2008-January/003519.htmlhttps://gitlab.xiph.org/xiph/theora/-/issues/1168Uninitialized variable might be used in the idct_short__c (idct.c file)2007-05-28T07:55:46ZGitlab BotUninitialized variable might be used in the idct_short__c (idct.c file)Here is some code from the idct.c found in the libtheora-1.0alpha7 sources:
static void idct_short__c ( ogg_int16_t * InputData, ogg_int16_t * OutputData ) {
ogg_int32_t t[8], r;
ogg_int16_t *y = InputData;
ogg_int16_t *x = OutputD...Here is some code from the idct.c found in the libtheora-1.0alpha7 sources:
static void idct_short__c ( ogg_int16_t * InputData, ogg_int16_t * OutputData ) {
ogg_int32_t t[8], r;
ogg_int16_t *y = InputData;
ogg_int16_t *x = OutputData;
t[0] = y[0] + y[4];
t[0] &= 0xffff;
t[0] = (xC4S4 * t[0]) >> 16;
t[1] = y[0] - y[4];
t[1] &= 0xffff;
t[1] = (xC4S4 * t[1]) >> 16;
t[2] = ((xC6S2 * t[2]) >> 16) - ((xC2S6 * y[6]) >> 16);
It seems that in the last line the t[2] value is initialized using its original, uninitialized one.https://gitlab.xiph.org/xiph/vorbis/-/issues/453uninitialized variables in lib/psy.c:bark_noise_hybridmp()2017-04-08T10:58:44Zko6pc7k02uninitialized variables in lib/psy.c:bark_noise_hybridmp()```
floats A, B and D are not initialized to 0.0 (would 0.0 be OK value, anyways?).
when I initialized them to 0.0 in the beginning of bark_noise_hybridmp,
libvorbis produces different output from the same input.
I can't hear much diffe...```
floats A, B and D are not initialized to 0.0 (would 0.0 be OK value, anyways?).
when I initialized them to 0.0 in the beginning of bark_noise_hybridmp,
libvorbis produces different output from the same input.
I can't hear much difference, but there is a difference.
for example, encoding fatboy.wav with quality 5.0:
-rw-rw---- 1 safari safari 153883 2003-09-14 03:26:55.000000000 +0300
fat-q5-psy.ogg
-rw-rw---- 1 safari safari 153900 2003-09-14 03:25:34.000000000 +0300
fat-q5.ogg
(-psy is the version with A, B, D initialized...)
$ cmp -l fat-q5.wav fat-q5-psy.wav
23619 63 62
23623 44 42
23627 235 232
23631 370 367
23635 215 217
23639 153 160
23643 357 367
23647 244 252
23651 254 255
23655 333 324
23659 262 243
...
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/1103unnamespaced global symbols in libao2010-01-30T14:31:15ZGitlab Botunnamespaced global symbols in libaojorton@jolt:~$ rpm -qf /usr/lib/libao.so.2
libao-0.8.6-3.i386
jorton@jolt:~$ nm -D /usr/lib/libao.so.2
...
41068d30 T read_config_file
41068e70 T read_config_files
buys you these collisions with other FC6 libraries:
Clashes for /usr/li...jorton@jolt:~$ rpm -qf /usr/lib/libao.so.2
libao-0.8.6-3.i386
jorton@jolt:~$ nm -D /usr/lib/libao.so.2
...
41068d30 T read_config_file
41068e70 T read_config_files
buys you these collisions with other FC6 libraries:
Clashes for /usr/lib/libao.so.2.1.3:
with /usr/lib/libsnmp.so.10.0.1 => read_config_files
with /usr/lib/libnetsnmp.so.10.0.1 => read_config_files
I fixed it by adding "-export-symbols-regex '^ao_.*'" to LDFLAGS in src/Makefile.{in,am}.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1399unpredictable corruption in multichannel Ogg vorbis files2017-04-08T10:59:08Zrobunpredictable corruption in multichannel Ogg vorbis filesHas anyone else created Vorbis files with more than 6 channels? I'm a game developer trying to use multichannel Ogg Vorbis files for a PS3 and XBOX 360 title. Using the latest release libs and tools, I've created a Mac application that...Has anyone else created Vorbis files with more than 6 channels? I'm a game developer trying to use multichannel Ogg Vorbis files for a PS3 and XBOX 360 title. Using the latest release libs and tools, I've created a Mac application that weaves up to 8 stereo AIFF files into one 16 channel Ogg file. What I'm finding is that if anything more than 3 stereo files (corresponding to a 5.1 audio file) are encoded, then the encoded output becomes unstable. I hear vocoder like artifacts and garbled output on some of the stereo pairs. It should be noted that I'm using a linear permutation matrix, so that the output file maintains the original stereo pairs, ie 16 channels in -> 16 channels out.
I've built Universal Binary versions of the latest Ogg and Vorbis libs available for download, and meticulously tested my sample_read callback, and everything is doing the right thing. I've even built raw and AIFF versions of a 16 track file, verified the integrity of the data, and run them through the readily available command line encoders for PC and Unix. The output corruption is identical to what I experience on my own encoder.
Its incredibly frustrating, and seems to be content dependent. In some file groupings, it performs brilliantly (I love the sound of Vorbis much more than MP3) for 3 minutes, and then goes to crap. In others, the corruption is evident much earlier. It always appears at the same place for each file group, no matter what the encoding settings.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/tremor/-/issues/1594unrecognized options: --enable-maintainer-mode2017-09-02T15:25:02ZGitlab Botunrecognized options: --enable-maintainer-modelast line of
http://svn.xiph.org/trunk/vorbis/autogen.sh
$srcdir/configure --enable-maintainer-mode "$@" && echo
which causes:
configure: WARNING: unrecognized options: --enable-maintainer-mode
last line of
http://svn.xiph.org/trunk/vorbis/autogen.sh
$srcdir/configure --enable-maintainer-mode "$@" && echo
which causes:
configure: WARNING: unrecognized options: --enable-maintainer-mode
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2072Update default SSL cipher list to be more secure2018-03-06T12:49:47ZThomas B. RückerUpdate default SSL cipher list to be more secureCurrently: "ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM"
Proposed: "ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:
DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS"
This was taken from: https://...Currently: "ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM"
Proposed: "ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:
DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS"
This was taken from: https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/#fnref2 (scroll up 2 lines)
I've tested this successfully against https://www.ssllabs.com/ssltest/ in combination with the patch for #2071. The only OS/Browser combination failing is: IE 6 / XPIcecast 2.4.1Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/theora/-/issues/1402Update of theora from 1.0alpha7 to 1.0beta3 lead to play ogg mosaic.2008-10-30T15:46:14Zwendy.huUpdate of theora from 1.0alpha7 to 1.0beta3 lead to play ogg mosaic.When I installed theora(version 1.0alpha7) on sparc (snv_91), totem
displays ogg format video normally. But after installing theora version 1.0beta3, totem displays ogg video mosaic. So the update of theora from 1.0alpha7 to 1.0beta3 lea...When I installed theora(version 1.0alpha7) on sparc (snv_91), totem
displays ogg format video normally. But after installing theora version 1.0beta3, totem displays ogg video mosaic. So the update of theora from 1.0alpha7 to 1.0beta3 lead to playing ogg video mosaic.
The ogg format video at http://gstreamer.freedesktop.org/media/incoming/, i.e.https://gitlab.xiph.org/xiph/icecast-server/-/issues/620Update Shoutcast Directory...2018-03-06T12:50:21ZIan PulverUpdate Shoutcast Directory...Why don't we enable Icecast users who are streaming MP3 to list themselves in the Shoutcast directory? Is this good or bad behaviour?
It'd be great in that the Shoutcast directory gets a lot more traffic than the XIPH one, so it supp...Why don't we enable Icecast users who are streaming MP3 to list themselves in the Shoutcast directory? Is this good or bad behaviour?
It'd be great in that the Shoutcast directory gets a lot more traffic than the XIPH one, so it supports the goal of Broadcasters to reach as wide of an audience as possible. Not so great in that it is arguably bad behaviour and we're taking advantage of AOL/Nullsoft.
It is true however that any WinAmp user (at least after 3.x) will be able to connect to the Ogg or MP3 streams of Icecast servers, so that's not a limitation.
One thing's for sure is it'll draw a lot more traffic to IceCasters and that's always good.
-Ian.Icecast 2.3Karl HeyesKarl Heyes