Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2018-01-21T13:05:27Zhttps://gitlab.xiph.org/xiph/speex/-/issues/570speex header location, .pc file and backward compatibility2018-01-21T13:05:27ZGitlab Botspeex header location, .pc file and backward compatibility```
trying to compile gstreamer speex plug-in with speex 1.1.6, i had the bad
experience to see that headers were moved.
the good point was that now speex uses a .pc file
the bad point is that the include path in it is bad
in order tha...```
trying to compile gstreamer speex plug-in with speex 1.1.6, i had the bad
experience to see that headers were moved.
the good point was that now speex uses a .pc file
the bad point is that the include path in it is bad
in order that program using speex won't have to change all their includes but
only their configure.ac file, it should be better to change the following :
Cflags: -I${includedir} => Cflags: -I${includedir}/speex
i suppose it is the same for speex 1.0.4 (i did not check this one)
```Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/speex/-/issues/571speex.m4 : syntax error2018-01-21T13:05:27ZGitlab Botspeex.m4 : syntax error```
autoconf 1.8 is stricter than older revisions. it warns about a syntax error :
/usr/share/aclocal/speex.m4:10: warning: underquoted definition of XIPH_PATH_SPEEX
AC_DEFUN(XIPH_PATH_SPEEX, => AC_DEFUN([XIPH_PATH_SPEEX],
would fix i...```
autoconf 1.8 is stricter than older revisions. it warns about a syntax error :
/usr/share/aclocal/speex.m4:10: warning: underquoted definition of XIPH_PATH_SPEEX
AC_DEFUN(XIPH_PATH_SPEEX, => AC_DEFUN([XIPH_PATH_SPEEX],
would fix it
```Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/vorbis/-/issues/572alloca() is not portable2017-04-08T10:58:44Zjohnathanalloca() is not portable```
All calls to function "alloca()" should be removed as this function is machine
specific and not supported on all platforms or all compilers (ie. MPW for
Macintosh does not support this functionality). Even the man page for alloca()
...```
All calls to function "alloca()" should be removed as this function is machine
specific and not supported on all platforms or all compilers (ie. MPW for
Macintosh does not support this functionality). Even the man page for alloca()
states that use of this function is inadvisable.
Thanks.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/577[PATCH] segfault in ov_time_seek()2017-04-08T10:59:27Zi.danihelka[PATCH] segfault in ov_time_seek()```
There seems to be bug in libvorbisfile.
The bug is in lib/vorbisfile.c in function ov_time_seek().
The variable "link" can have value -1 when is passed to expression
"vf->vi[link].rate".
The for cycle ends when (link == -1) or (seco...```
There seems to be bug in libvorbisfile.
The bug is in lib/vorbisfile.c in function ov_time_seek().
The variable "link" can have value -1 when is passed to expression
"vf->vi[link].rate".
The for cycle ends when (link == -1) or (seconds >= time_total).
This could leaves variable link with value -1.
This happends when functions is called with seconds = 0.0
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/578Encoding large number of files in one go crashes system2007-06-17T08:51:57ZGitlab BotEncoding large number of files in one go crashes system```
I am running Windows XP with Service Pack 2 and the Vorbis 1.0.1 Tools.
When I was trying to run a large batch query converting standard WAV files (14
GB in 255 Files (21 CDs) in a single directory) to Vorbis using OggDropXP
(Qual...```
I am running Windows XP with Service Pack 2 and the Vorbis 1.0.1 Tools.
When I was trying to run a large batch query converting standard WAV files (14
GB in 255 Files (21 CDs) in a single directory) to Vorbis using OggDropXP
(Quality: 6, no special options), the whole system reproducibly froze (3x) after
approximately 1 GB of source data had been processed.
Suspecting OggDrop, I generated a batch file that individually called oggenc for
each one of the remaining 200 files. Running the batch file in turn reproducibly
led (4x) to a blue screen (IRQL_NOT_LESS_OR_EQUAL variety). The crash once again
occured after about 1 GB of source data.
I have just finished encoding all files by dropping the remaining 100 files into
OggDrop *one CD at a time* without incident.
I do not think that the actual file content has anything to do with the problem,
as the files affected by crashes were all handled without problems when I
subsequently resumed encoding with the exact same file.
My system is stable and I think I can rule out completely unrelated causes for
the crashes, which occurred exactly, and only, when I used OggDrop/OggEnc. I had
extensively used OggDrop before without any problems, but only for one CD at a
time.
Of course, it is possible or even probable that the actual fault does not lie
with OggEnc/OggDrop, but the Windows Kernel/Explorer and was merely triggered
through the interaction with OggEnc. Still, I find my system's behavior quite
bizarre. While I could at least in principle imagine how a large number of files
could crash OggDrop, I have no idea why OggEnc should be affected by being run
50 times in a row.
I know this bug report is only partially helpful - if I can reproduce the blue
screen one more time, I will add the detailed information (especially which
module caused it).
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/580divide by zero error2017-04-08T10:58:44Zjohnhdivide by zero error```
Encountered div by zero exception in bark_noise_hybridmp() in PSY.C caused by
the statement: D = tN * tXX - tX * tX; (don't know which one, there are 4
instances). When I prevented R = (A + x * B) / D; from being calculated if D ==
0...```
Encountered div by zero exception in bark_noise_hybridmp() in PSY.C caused by
the statement: D = tN * tXX - tX * tX; (don't know which one, there are 4
instances). When I prevented R = (A + x * B) / D; from being calculated if D ==
0, all was ok & the resultant OGG file could still be played (used winAmp).
Built v1.1 of ogg, vorbis, vorbisenc & vorbisfile with borland c++ builder v6 &
tested with builds of oggenc & oggdec on this dev. platform. Have emailed the
offending WAV file to Mike Smith - was generated by using directSound (v9) audio
capture api. Problem also occurred on a WAV decoded from an MP3 using LAME.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/581configure script ignores all the --with-ogg* options2017-04-08T10:58:44Zgorlikconfigure script ignores all the --with-ogg* options```
If there is a ogg version on the system configure will find it and ignore the --
with-ogg , --with-ogg-includes , --with-ogg-libraries options.
This prevents cross compiling on any system that has native ogg installed.
system detail...```
If there is a ogg version on the system configure will find it and ignore the --
with-ogg , --with-ogg-includes , --with-ogg-libraries options.
This prevents cross compiling on any system that has native ogg installed.
system details:
debian testing kernel 2.6.8-alpha and 2.6.9-i386
libvorbis-1.1.0
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/582[PATCH] Problem during book initialisation2017-04-08T10:58:44ZFelix Leder[PATCH] Problem during book initialisation```
The following situation can occur in _vds_shared_init (block.c) at line 224.
When calling vorbis_book_init_decode (sharedbook.c, l. 318) with a
static_codebook which has all lengthlist = 0, blocks with a size of 0 bytes are
allocated...```
The following situation can occur in _vds_shared_init (block.c) at line 224.
When calling vorbis_book_init_decode (sharedbook.c, l. 318) with a
static_codebook which has all lengthlist = 0, blocks with a size of 0 bytes are
allocated. The behaviour of malloc/calloc in that case is "implementation
dependant".
Most "implementations" return a pointer. Then everything works fine. BUT if you
have an implementation (e.g. TI DSPs) that returns NULL in case of a
calloc/malloc(0) either a segmentation fault is produced or data from memory
position 0 on is overwritten. Neither is wanted.
This overwriting happens in _book_unquantize (sharedbook.c, l. 183) in line 215
and possibly in line 235.
A fix is to replace lines 204 & 225 in this file:
< if((sparsemap && b->lengthlist[j]) || !sparsemap){
------------------
> if(b->lengthlist[j]){
This bug may be related to bug #340
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/583Compiling libvorbis-1.1.0 with gcc-4.0.0 causes bitrate / filesize increase2017-04-08T10:59:08ZGitlab BotCompiling libvorbis-1.1.0 with gcc-4.0.0 causes bitrate / filesize increase```
Using libvorbis-1.1.0 compiled with gcc-4.0.0 (20041107 snapshot) gives an
encoded file which is about 35% larger than the same file encoded using the same
libvorbis release but compiled with gcc-3.3.2. (For the gcc-4.0.0 version, I...```
Using libvorbis-1.1.0 compiled with gcc-4.0.0 (20041107 snapshot) gives an
encoded file which is about 35% larger than the same file encoded using the same
libvorbis release but compiled with gcc-3.3.2. (For the gcc-4.0.0 version, I
get around 270kbps for a -q6 encode). Other than the bitrate / filesize
increase, the encoded files sound the same.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/ogg/-/issues/586[PATCH] ogg2-arc does not compile wiht mingw322009-04-19T21:13:43Zj[PATCH] ogg2-arc does not compile wiht mingw32ogg2-arc from svn branches/ogg2-arc does not compile on mingw32,
since #include <_G_config.h> fails.
it should work as it is done in libogg/trunk - http://svn.xiph.org/trunk/ogg/include/ogg/os_types.h
```
# if defined(__CYGWIN__)
# ...ogg2-arc from svn branches/ogg2-arc does not compile on mingw32,
since #include <_G_config.h> fails.
it should work as it is done in libogg/trunk - http://svn.xiph.org/trunk/ogg/include/ogg/os_types.h
```
# if defined(__CYGWIN__)
# include <_G_config.h>
typedef _G_int64_t ogg_int64_t;
typedef _G_int32_t ogg_int32_t;
typedef _G_uint32_t ogg_uint32_t;
typedef _G_int16_t ogg_int16_t;
typedef _G_uint16_t ogg_uint16_t;
# elif defined(__MINGW32__)
typedef short ogg_int16_t;
typedef unsigned short ogg_uint16_t;
typedef int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef long long ogg_int64_t;
typedef unsigned long long ogg_uint64_t;
```Arc RileyArc Rileyhttps://gitlab.xiph.org/xiph/theora/-/issues/587finish libtheora api changes2007-11-07T08:03:57ZGitlab Botfinish libtheora api changesapi changes need to be finished for next theora releaseapi changes need to be finished for next theora releasehttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/588Updated fr.po file2005-07-11T10:42:54ZGitlab BotUpdated fr.po fileUpdated fr.po file for vorbis-tools-1.0.1 (never used trac before, how can I
attach my patch ?)Updated fr.po file for vorbis-tools-1.0.1 (never used trac before, how can I
attach my patch ?)Manuel LoraManuel Lorahttps://gitlab.xiph.org/xiph/theora/-/issues/589full Theora I decode support needed2007-08-30T19:09:38ZGhost Userfull Theora I decode support neededthe reference implementation does not support non-VP3 quant matricies or per-block qi switching. Support needs to be added to the reference decoder.the reference implementation does not support non-VP3 quant matricies or per-block qi switching. Support needs to be added to the reference decoder.https://gitlab.xiph.org/xiph/icecast-server/-/issues/590Credits does not work2018-03-06T12:50:21ZGitlab BotCredits does not workHello
http://downloads.us.xiph.org/releases/icecast/icecast2_win32_2.2.0RC1_setup.exe
About -> Credits
does not work for me
WinXP Pro SP2 German;
AMD XP 2000+Hello
http://downloads.us.xiph.org/releases/icecast/icecast2_win32_2.2.0RC1_setup.exe
About -> Credits
does not work for me
WinXP Pro SP2 German;
AMD XP 2000+Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/591Bandwidth stats2023-01-03T19:11:54ZGitlab BotBandwidth statsIn icecast1 it was possible to fetch the current used/maximum bandwidth on the server. It seems like these stats got lost in the icecast2 rewrite, and it would be neat to have them back.
It's not anything critical, but it's good to be ab...In icecast1 it was possible to fetch the current used/maximum bandwidth on the server. It seems like these stats got lost in the icecast2 rewrite, and it would be neat to have them back.
It's not anything critical, but it's good to be able to see how much bandwidth the server uses.Icecast 2.6Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/Infrastructure/-/issues/592no way to not select Milestone TheoraBeta12017-04-07T21:40:28ZGitlab Botno way to not select Milestone TheoraBeta1adding a new ticket to trac, there is no way to
not select Milestone TheoraBeta1, thats broken.adding a new ticket to trac, there is no way to
not select Milestone TheoraBeta1, thats broken.https://gitlab.xiph.org/xiph/icecast-server/-/issues/593Tracking mountpoint bandwidth usage (from mailing list)2023-01-03T10:28:03ZAaron PaulleyTracking mountpoint bandwidth usage (from mailing list)Karl asked me to submit this to trac.xiph.org, from the mailing list.
I exclusively use mountpoints to setup my clients' streams. What would be absolutely amazing is if Icecast could log bandwidth usage per mountpoint, so I can better s...Karl asked me to submit this to trac.xiph.org, from the mailing list.
I exclusively use mountpoints to setup my clients' streams. What would be absolutely amazing is if Icecast could log bandwidth usage per mountpoint, so I can better see which mountpoints are using more or less of the bandwidth. I'm using mrtg to monitor the whole server, but it, and every stats program I've tried, has no way of differentiating the various mountpoints.
Thanks!Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/594ices return value of 1 on successful startup2019-04-19T11:32:52ZGitlab Botices return value of 1 on successful startupint main in ices.c says it will end in ices_setup_shutdown by calling exit(0), however this
actually calls exit(1) <setup.c, line136>. This causes startup scripts that use the daemon
command within fedora core 1,2,3 and redhat 9 to rep...int main in ices.c says it will end in ices_setup_shutdown by calling exit(0), however this
actually calls exit(1) <setup.c, line136>. This causes startup scripts that use the daemon
command within fedora core 1,2,3 and redhat 9 to report a failure starting ices. I know it is
trivial, but it is very annoying in ices-0.4Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/595fallback management in /admin/ interface2018-06-15T21:35:14ZMike Altrionfallback management in /admin/ interfaceIt would be nice to see and manage in the admin interface what fallback mountpoint was configured for a given mountpoint.It would be nice to see and manage in the admin interface what fallback mountpoint was configured for a given mountpoint.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/597Missing auth.xsl file in Win32 version of icecast2.22018-03-06T12:50:21ZpemMissing auth.xsl file in Win32 version of icecast2.2The auth.xsl file seems to be missing in the Win32 install of icecast2.2
If such a feature could not be used in Win32, it could be nice to specify it in the doc.The auth.xsl file seems to be missing in the Win32 install of icecast2.2
If such a feature could not be used in Win32, it could be nice to specify it in the doc.Michael SmithMichael Smith