Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2023-01-28T20:46:15Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1973Allow standard HTTP method instead of non-standard "STATS" for opening stats ...2023-01-28T20:46:15ZjA_cOpAllow standard HTTP method instead of non-standard "STATS" for opening stats streamMany HTTP libraries don't support using non-standard HTTP methods, so this can be a blocking issue.
Many HTTP libraries don't support using non-standard HTTP methods, so this can be a blocking issue.
Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/libao/-/issues/1976libao / OSS on illumos2017-11-03T10:00:01ZGabriele Bulfonlibao / OSS on illumosHi, we're working on a new distro based on illumos (Solaris fork).
While trying to work out xmms2, we had to build and package libao,
required for xmms2 / OSS on Solaris brands.
It works for many simple audio files, but not for many hig...Hi, we're working on a new distro based on illumos (Solaris fork).
While trying to work out xmms2, we had to build and package libao,
required for xmms2 / OSS on Solaris brands.
It works for many simple audio files, but not for many high quality
mp3 or so, because libao seems not to support 32 bit samples in
this configuration:
ao_oss ERROR: Unsupported number of bits: 32.ao_oss
Is there anything we can do to make it work?
Gabriele.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/theora/-/issues/1987Ancient config.guess fails to work on 64-bit MIPS platforms2023-10-22T05:50:04ZMark H WeaverAncient config.guess fails to work on 64-bit MIPS platformsThe 'config.guess' file that you distribute with your most recent
libtheora tarballs (including 1.2.0alpha1) is from 2003. It fails to
work properly on 64-bit MIPS systems such as Loongson.
As it says in the comments of any recent 'con...The 'config.guess' file that you distribute with your most recent
libtheora tarballs (including 1.2.0alpha1) is from 2003. It fails to
work properly on 64-bit MIPS systems such as Loongson.
As it says in the comments of any recent 'config.guess' (e.g. from a
recent GCC release):
You can get the latest version of this script from:
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
Thanks!
Mark
https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1988ogg123 doesn't play flac files with ID3 tags, no useful error given2018-01-22T04:18:26Zmyxalogg123 doesn't play flac files with ID3 tags, no useful error givenHi.
I'm the reporter of ubuntu bug 1250618: https://bugs.launchpad.net/ubuntu/+source/vorbis-tools/+bug/1250618
I've since gone through the FLAC FAQs on the main site, noticing that files with id3 tags are unsupported, and users should n...Hi.
I'm the reporter of ubuntu bug 1250618: https://bugs.launchpad.net/ubuntu/+source/vorbis-tools/+bug/1250618
I've since gone through the FLAC FAQs on the main site, noticing that files with id3 tags are unsupported, and users should not expext these to work.
I'd like to disagree with this and voice my concern that such a semi-common file format is not supported. I can understand not supporting a different format of tagging, but (I think) this should not interfere with playback itself. If playback of these files is not possible with the tags, then at least a more informative error message would be welcome. I took me quite a while to even figure out what the problem was, as the "flac" program showed no error or warning on testing or analyzing the file, and other programs (mplayer, VLC...) had no issue with the files in the first place.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/opus/-/issues/2001Opus encoder produces 40/60ms CBR packets with excess padding2017-10-21T19:37:03ZMark HarrisOpus encoder produces 40/60ms CBR packets with excess paddingThe packets produced by `opus_multistream_encode()` when encoding 40ms or 60ms CELT or Hybrid packets for a single stream contain 4 to 6 bytes of padding, which could have been used to add 1 or 2 bytes to each frame.
For example:
```
$ ...The packets produced by `opus_multistream_encode()` when encoding 40ms or 60ms CELT or Hybrid packets for a single stream contain 4 to 6 bytes of padding, which could have been used to add 1 or 2 bytes to each frame.
For example:
```
$ opusenc --hard-cbr --bitrate 31.5 --framesize 60 comp48s.wav out.opus
Encoding using libopus 1.1-42-ge1f8462 (audio)
-----------------------------------------------------
Input: 48kHz 2 channels
Output: 2 channels (2 coupled)
60ms packets, 31.5kbit/sec CBR
Preskip: 312
Encoding complete
-----------------------------------------------------
Encoded: 1 minute and 30.84 seconds
Runtime: 2 seconds
(45.42x realtime)
Wrote: 362224 bytes, 1514 packets, 97 pages
Bitrate: 31.4667kbit/s (without overhead)
Instant rates: 31.4667kbit/s to 31.4667kbit/s
(236 to 236 bytes per packet)
Overhead: 1.36% (container+metadata)
$
```
The above command produces 236-byte packets (31.467 kb/s), each containing the 2 bytes required for a code 3 packet, three 76-byte frames, and 6 bytes of padding (including the padding length byte). Instead of the 6 bytes of padding, each frame could have contained 78 bytes of data.
If the multistream API is not used, `opus_encode()` does produce packets containing three 78-byte frames for this same bitrate and frame size. However, for some reason it also adds 1 byte of padding to each packet, which causes it to slightly exceed the target bitrate.
```
$ opus_demo audio 48000 2 31500 -cbr -framesize 60 comp48s.pcm out.pcm
libopus 1.1-42-ge1f8462
Encoding 48000 Hz input at 31.500 kb/s in auto mode with 2880-sample frames.
average bitrate: 31.613 kb/s
maximum bitrate: 31.600 kb/s
active bitrate: 31.600 kb/s
bitrate standard deviation: 0.000 kb/s
$
```Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2003refbuf should be replaced2018-10-18T08:03:57ZPhilipp Schafftrefbuf should be replacedrefbuf is a type of objected used to store binary data. As the name suggest it has an internal reference counter that allows it to be freed automatically when no longer in use.
the old refbuf objects aren't well designed and allow direc...refbuf is a type of objected used to store binary data. As the name suggest it has an internal reference counter that allows it to be freed automatically when no longer in use.
the old refbuf objects aren't well designed and allow direct access to internal data structures. This became abused.
The new object type MUST:
* be well designed,
* not allow access to internal data structures,
* have a well designed API to access the object's content in a secure way.Icecast 2.6Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2004calls to abort() should be removed and checks for memory allocation failture ...2018-10-18T08:03:57ZPhilipp Schafftcalls to abort() should be removed and checks for memory allocation failture to be addedicecast calls abort() 3 times. All 3 times are related to memory allocation. It is used to avoid the need to handle errors on memory allocation. In many other places memory allocation is not checked to be successful.
* all calls to abor...icecast calls abort() 3 times. All 3 times are related to memory allocation. It is used to avoid the need to handle errors on memory allocation. In many other places memory allocation is not checked to be successful.
* all calls to abort() should be removed.
* all calls to malloc(), calloc() and realloc() should be checked handling errors correctly.
* There should be a policy on what happens on memory allocation failure (icecast dropping clients/resources OR dieing?)
* icecast should (at high/all cost) try to inform the user about this problem.
* memory failure can have many reasons. Not just the system being out of memory.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/libao/-/issues/2006libao: 24-bit ALSA playback is broken2017-11-03T10:00:01ZAndrew Ekstedtlibao: 24-bit ALSA playback is brokenALSA requires 24-bit samples to be padded to 32 bits.
> The 24-bit linear samples use 32-bit physical space, but the sample is stored in the lower three bytes.
> http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html#pcm_formats
Libao ...ALSA requires 24-bit samples to be padded to 32 bits.
> The 24-bit linear samples use 32-bit physical space, but the sample is stored in the lower three bytes.
> http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html#pcm_formats
Libao used to do this correctly, but changeset r18883 (which made it in to libao 1.2) rewrote the padding code to also handle upconverting arbitrary sample sizes, by filling the low bytes with zeros. Unfortunately, ALSA's 24-bit padding works the other way around - the _high_ byte is supposed to be zero-filled. Needless to say, padding the wrong end doesn't work very well.
https://gitlab.xiph.org/xiph/opus/-/issues/2026Opus DTX issue report2017-10-21T19:37:03ZgmarianoOpus DTX issue reportHello:
We noticed that opus reconstructed noise is pulsing with a 400ms pattern when dtx is enabled in silk mode. This is independent of the background noise level and is found with speech + non-speech period test files, as well as vari...Hello:
We noticed that opus reconstructed noise is pulsing with a 400ms pattern when dtx is enabled in silk mode. This is independent of the background noise level and is found with speech + non-speech period test files, as well as variable level noise-only test files. This issue can be easirly reproduced with opus v1.1 using this command:
./opus_demo voip 16000 1 25000 –dtx input.bin output.bin
We have attached a .wav file with the first channel as the input reference noise signal and the second channel as the opus codec output using the opus_demo application. It does not look like this has been reported already. We would like your feedback.
Thank you,
Gonzalo Mariano and Pascal Huart
Cisco Systems
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2030Incorrect bark() formula in floor0 specification2017-11-01T04:49:44ZAndrew ChurchIncorrect bark() formula in floor0 specificationIn the current version of the Vorbis I specification, the bark() function used by floor 0 is defined as:
bark(x) = 13.1 arctan(.00074x) + 2.24 arctan(.0000000185x^2 + .0001x)
However, the formula actually used by libvorbis is:
bark(x)...In the current version of the Vorbis I specification, the bark() function used by floor 0 is defined as:
bark(x) = 13.1 arctan(.00074x) + 2.24 arctan(.0000000185x^2 + .0001x)
However, the formula actually used by libvorbis is:
bark(x) = 13.1 arctan(.00074x) + 2.24 arctan(.0000000185x^2) + .0001x
(note that the .0001x is not part of the arctan argument).
Since floor 0 seems to be considered obsolete, I suggest changing the specification to reflect the formula actually used by libvorbis.https://gitlab.xiph.org/xiph/libao/-/issues/2034release 1.2.0 was not announced and is not linked on the downloads page2017-11-03T10:00:01Zjohn_spencerrelease 1.2.0 was not announced and is not linked on the downloads pagedespite it being available on the ftp since several weeksdespite it being available on the ftp since several weeksMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/libao/-/issues/2035libao 1.2.0 differing behaviour for 8bit audio2017-11-03T10:00:01Zjohn_spencerlibao 1.2.0 differing behaviour for 8bit audiolibao 1.1.0 behaves as expected: the amplitude is unsigned (0..255)
libao 1.2.0 behaves differently: the amplitude is signed (-128..127)
noticed when trying to mute a stream by using 0 for the samples
for 1.2.0 you have to pass 127 to m...libao 1.1.0 behaves as expected: the amplitude is unsigned (0..255)
libao 1.2.0 behaves differently: the amplitude is signed (-128..127)
noticed when trying to mute a stream by using 0 for the samples
for 1.2.0 you have to pass 127 to mute.
```
#include <unistd.h>
#include <ao/ao.h>
#include <stdlib.h>
#include <string.h>
struct AoWriter {
ao_device *device;
ao_sample_format format;
int aodriver;
};
int AoWriter_init(struct AoWriter *self) {
ao_initialize();
memset(self, 0, sizeof(*self));
self->format.bits = 8;
self->format.channels = 1;
self->format.rate = 11025;
self->format.byte_format = AO_FMT_LITTLE;
self->aodriver = ao_default_driver_id();
self->device = ao_open_live(self->aodriver, &self->format, NULL);
return self->device != NULL;
}
int AoWriter_write(struct AoWriter *self, void* buffer, size_t bufsize) {
return ao_play(self->device, buffer, bufsize);
}
int AoWriter_close(struct AoWriter *self) {
return ao_close(self->device);
}
static unsigned char blip[] = {0x52, 0x51, 0x51, 0x51, 0xC4, 0x4C, 0xF4, 0xF4, 0xF3,0xEF};
static int blip_frame(int idx) {
idx = idx % (2*sizeof(blip));
if(idx>=sizeof(blip)) idx=(2*sizeof(blip))-idx;
return blip[idx];
}
static void generate_blip(unsigned char* data, size_t bufsize, double volume) {
int i;
for(i=0;i<bufsize;i++)
/* libao 1.1.0 behaves as expected: the amplitude is unsigned (0..255)
libao 1.2.0 behaves differently: the amplitude is signed (-128..127) */
#if 1
data[i] = (blip_frame(i)-128)*volume+127;
#else
data[i] = blip_frame(i)*volume;
#endif
}
#define DEFAULT_VOLUME 0.02
int main() {
struct AoWriter ao;
AoWriter_init(&ao);
unsigned char buf[100];
generate_blip(buf, sizeof(buf), DEFAULT_VOLUME);
unsigned passed = 0;
while(1) {
usleep(1000);
passed++;
if(passed >= 200) {
passed=0;
AoWriter_write(&ao, buf, sizeof buf);
}
}
AoWriter_close(&ao);
return 0;
}
```
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/OggIndex/-/issues/4ogg-index sets incorrect fisbone message header offset in the skeleton stream2020-11-06T04:04:59ZNick 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/OggIndex/-/issues/3ogg-index fails with an unhelpful error message if the file contains Speex or...2020-11-06T04:03:14ZNick 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/OggIndex/-/issues/2ogg-index produces multiple fisbones with the same name and role, where the i...2020-11-06T04:02:50ZNick 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/opusfile/-/issues/2046opusfile library for Windows is not helpful to Windows developers2018-07-04T14:02:14Zjon Wopusfile library for Windows is not helpful to Windows developersThere are three bugs in the Opusfile library for windows (version 0.6, built 6/11/2014):
1) It does not include .lib link libraries for Visual Studio, thus cutting out about 99.9% of all Windows developers (that number may be an under-e...There are three bugs in the Opusfile library for windows (version 0.6, built 6/11/2014):
1) It does not include .lib link libraries for Visual Studio, thus cutting out about 99.9% of all Windows developers (that number may be an under-estimate). GCC-generated .a linkable libraries are not useable from Visual Studio, and cannot be converted to Visual Studio .lib format using included MSSDK tools like "dumpbin" or "lib" or "link."
There are free-as-in-beer versions of Visual C++ Express, so cost should not be an impediment to solving this.
2) The included opusfile.h header is not sufficient to use the library -- it also includes files ogg/ogg.h and opus_multistream.h, which are not included.
3) The includes of files relative to opusfile.h are done with <> brackets, not "" quotes. This means that you expect the ogg.h and opus_multistream.h headers to be part of the standard system includes, which is not generally true on Windows systems. Instead, this file should include those header files with "" includes, to signal that the include path is relative to wherever opusfile.h is located, which would enable a self-contained download of this library to be created.
(Note that opusfile.h itself can be included with relative includes, with #include "opusfile-0.6-win32/opusfile.h", or with some other mechanism -- you should not assume opusfile.h is installed in the system include path.
Separately, the build instructions say "build doing ./configure and make," which is not at all helpful to 99.9% (or more) of Windows developers. If you want to support Windows, please actually do so. Else, just drop the support. The current library is not helpful and is just bad marketing for the opusfile library.
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/libao/-/issues/2051non-blocking ao_play() and associated ao_wait()2017-11-03T10:00:01ZPeter Billamnon-blocking ao_play() and associated ao_wait()Greetings. I've been exploring libao, but for what I want to do I need a non-blocking ao_play(), so I can then do processing in real-time, then an ao_wait to get to the end of the previous buffer, then play my new buffer and loop.
It lo...Greetings. I've been exploring libao, but for what I want to do I need a non-blocking ao_play(), so I can then do processing in real-time, then an ao_wait to get to the end of the previous buffer, then play my new buffer and loop.
It looks like this has not been implemented, perhaps because it's not portable enough :-(
Suggestions gratefully received...
Regards, PeterMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2055Changing relay on-demand settings messes things up2018-03-06T12:49:38ZMarvin ScholzChanging relay on-demand settings messes things upIf a relay is configure in Icecast like the following:
```
<relay>
<server>stream.server.de</server>
<port>8000</port>
<mount>/24.mp3</mount>
<local-mount>/diff.mp3</local-mount>
<relay-shoutcast...If a relay is configure in Icecast like the following:
```
<relay>
<server>stream.server.de</server>
<port>8000</port>
<mount>/24.mp3</mount>
<local-mount>/diff.mp3</local-mount>
<relay-shoutcast-metadata>0</relay-shoutcast-metadata>
<on-demand>1</on-demand>
</relay>
```
and the `on-demand` value is changed to 0 and config re-read with SIGHUP, it will still show as on-demand in the stats and the whole relay mount will disappear and reappear quite randomly.
When initially 0 and changed to 1 it seems to have no effect at all.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2056On-demand relay mount vanishes shortly right after last player disconnects2023-02-27T11:40:50ZMarvin ScholzOn-demand relay mount vanishes shortly right after last player disconnectsIf a on demand relay is configured, and the last listener disconnects, it vanishes from the stats for a short period of time.
This is because in `source.c` the `source_shutdown()` function deletes the source stats:
```
stats_event(so...If a on demand relay is configured, and the last listener disconnects, it vanishes from the stats for a short period of time.
This is because in `source.c` the `source_shutdown()` function deletes the source stats:
```
stats_event(source->mount, NULL, NULL);
```
There would be different approaches to fix this:
1. Do not fix it at all
2. If it is a on-demand mount, only remove the data that will probably change
3. Remove all data and trigger immediate refresh of mount data (inefficient?)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2062Simplify render_point2017-11-01T04:49:44ZSven EberhardtSimplify render_pointThe render_point function seems to fit a linear function through (x0,y0) and (x1,y1) and then finds y(x) on that line. It does some special case handling for y0>y1 vs y0<y1, which, as far as I can see, is unnecessary. I.e., the current c...The render_point function seems to fit a linear function through (x0,y0) and (x1,y1) and then finds y(x) on that line. It does some special case handling for y0>y1 vs y0<y1, which, as far as I can see, is unnecessary. I.e., the current code:
int dy=y1-y0;
int adx=x1-x0;
int ady=abs(dy);
int err=ady*(x-x0);
int off=err/adx;
if(dy<0)return(y0-off);
return(y0+off);
should be equivalent to this:
return (x - x0) * (y1 - y0) / (x1 - x0) + y0;
The only difference would be in some integer overflow cases, which cannot happen in this place anyway. I've tried the replacement and found no difference when encoding a test file.Monty MontgomeryMonty Montgomery