Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2020-11-06T04:03:14Zhttps://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/icecast-server/-/issues/2402Auth url webhooks not working2020-11-14T16:56:42ZJohn MidsonAuth url webhooks not workingHi guys,
Sorry if I'm missing something obvious, but I really can't make authentication url working.
I have Icecast configs:
```
<mount>
<mount-name>/aac_high</mount-name>
<authentication type="url">
<option...Hi guys,
Sorry if I'm missing something obvious, but I really can't make authentication url working.
I have Icecast configs:
```
<mount>
<mount-name>/aac_high</mount-name>
<authentication type="url">
<option name="listener_add" value="http://localhost:3000/api/v1/listeners/add"/>
<option name="listener_remove" value="http://localhost:3000/api/v1/listeners/remove"/>
<option name="auth_header" value="icecast-auth-user: 1"/>
</authentication>
</mount>
```
By calling `/aac_hight` I got 401 despite server is configured to return correct header:
```
$ curl http://localhost:8000/aac_high
<?xml version="1.0"?>
<report xmlns="http://icecast.org/specs/reportxml-0.0.1" version="0.0.1"><incident><state definition="25387198-0643-4577-9139-7c4f24f59d4a"><text>You need to authenticate</text></state></incident><extension application="http://icecast.org/specs/legacy-icestats"><icestats xmlns="http://icecast.org/specs/legacystats-0.0.1"><modules/></icestats></extension></report>
```
In Icecast's `error.log` I'm getting:
```
[2020-11-05 11:44:02] INFO auth/queue_auth_client auth on /aac_high has 1 pending
[2020-11-05 11:44:02] INFO auth_url/url_add_client client auth (http://localhost:3000/api/v1/listeners/add) failed with ""
[2020-11-05 11:44:02] WARN reportxml/reportxml_database_build_report No matching definition for "25387198-0643-4577-9139-7c4f24f59d4a"
```
So, looks like it is trying to reach `http://localhost:3000/api/v1/listeners/add` but in server logs I don't see any incoming request at all.
Callback on localhost:3000 working fine:
```
$ curl -v -X POST http://localhost:3000/api/v1/listeners/add
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 3000 (#0)
> POST /api/v1/listeners/add HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< icecast-auth-user: 1
< Server: Dominion
< Date: Thu, 05 Nov 2020 12:19:24 GMT
< Connection: keep-alive
< Content-Length: 0
<
* Connection #0 to host localhost left intact
```
Icecast is built from master branch, additional info:
```
$ ./icecast -v
Icecast 2.4.99.2
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.3 LTS (Bionic Beaver)"
```
Will appreciate any hint what is going wrong. Thanks!https://gitlab.xiph.org/xiph/opus/-/issues/2345shared description of public API headers2020-10-27T16:09:01ZRalph Gilesshared description of public API headersWe have a shared list of source files in `*_sources.mk` which are used by all the build systems to reduce the maintenance burden. However, there is no such list of headers, so each build system maintains its own list of files defining th...We have a shared list of source files in `*_sources.mk` which are used by all the build systems to reduce the maintenance burden. However, there is no such list of headers, so each build system maintains its own list of files defining the public API.
In the discussion of !13 it was suggested that we create such a shared definition. @tmp volunteered to propose an implementation.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2400global stats key listeners incorrect after client got dropped from pending_tr...2021-03-22T23:22:29ZPhilipp Schafftglobal stats key listeners incorrect after client got dropped from pending_tree for max_listenersThe global stats key `listeners` is incorrect after a client is dropped from the `pending_tree` as the mount is full. this happens on client move (as per admin request or fallback).
The code can be found looking in source.c for:
```
...The global stats key `listeners` is incorrect after a client is dropped from the `pending_tree` as the mount is full. this happens on client move (as per admin request or fallback).
The code can be found looking in source.c for:
```
ICECAST_LOG_INFO("Client deleted, exceeding maximum listeners for this "
"mountpoint (%s).", source->mount);
```https://gitlab.xiph.org/xiph/theora/-/issues/2312Decoding frames is slow if telemetry options are explicitly set to 02020-10-22T15:52:21ZZebediah FiguraDecoding frames is slow if telemetry options are explicitly set to 0GStreamer's "theoradec" element exposes libtheoradec telemetry options to the user, but if none are set it still calls th_decode_ctl(), setting the relevant options to 0. This causes the "telemetry" path to be enabled, such that we still...GStreamer's "theoradec" element exposes libtheoradec telemetry options to the user, but if none are set it still calls th_decode_ctl(), setting the relevant options to 0. This causes the "telemetry" path to be enabled, such that we still create a Cairo image and perform YUV/RGB translation, which is very slow.
I'm not sure this is a *bug* per se, but it seems like an optimization worth performing to only create a Cairo image if any telemetry options are actually enabled (i.e. nonzero).
The following patch resolves this issue. I would submit it as a merge request, but I seem to be unable to create a fork of this repository.
[0001-Avoid-creating-a-Cairo-buffer-if-all-telemetry-optio.patch](/uploads/267910230558612b179c9dbf895d97d6/0001-Avoid-creating-a-Cairo-buffer-if-all-telemetry-optio.patch)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2399Crash Icecast 2.4.4 on CentOS 7.52020-10-19T17:28:24ZMediaKCrash Icecast 2.4.4 on CentOS 7.5Linked from previous report `https://gitlab.xiph.org/xiph/icecast-server/-/issues/2344`
My radio stream service exits on minimal load.
I'm using Icecast 2.4.4
OpenSSL 1.0.2k-fips 26 Jan 2017
On CentOs 7.8
WHM/CPANEL: v90.0.15
`Oct 18 ...Linked from previous report `https://gitlab.xiph.org/xiph/icecast-server/-/issues/2344`
My radio stream service exits on minimal load.
I'm using Icecast 2.4.4
OpenSSL 1.0.2k-fips 26 Jan 2017
On CentOs 7.8
WHM/CPANEL: v90.0.15
`Oct 18 02:18:33 server1 kernel: traps: icecast[16512] general protection ip:7f2327a88c09 sp:7ffdab32ab80 error:0 in libssl.so.1.0.2k[7f2327a5c000+67000]
`
With added errors
`Oct 18 02:18:33 server1 systemd: icecast.service: main process exited, code=killed, status=11/SEGV
Oct 18 02:18:33 server1 systemd: Unit icecast.service entered failed state.
Oct 18 02:18:33 server1 systemd: icecast.service failed.`
How can this be resolved?https://gitlab.xiph.org/xiph/icecast-server/-/issues/2398Handling of GET request on admin/ should be updated2020-10-15T15:24:33ZPhilipp SchafftHandling of GET request on admin/ should be updatedCurrently GET request are handled alike POST request. This should be changed to the following:
In operation mode `legacy`: \
Keep as is.
In operation mode `normal`: \
Write a warning about such clients.
In operation mode `strict`: \
R...Currently GET request are handled alike POST request. This should be changed to the following:
In operation mode `legacy`: \
Keep as is.
In operation mode `normal`: \
Write a warning about such clients.
In operation mode `strict`: \
Reject the request.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/opus/-/issues/2344unexpected result using inbandfec in cbr mode.2020-10-12T16:47:40Zwumasterunexpected result using inbandfec in cbr mode.when I use this command:
`voip 16000 1 32000 -framesize 40 -loss 20 -inbandfec -cbr es01_l_16k.pcm out.pcm`
[es01_l_16k.pcm](/uploads/57c337058263bb3f0dafd897c55f82ee/es01_l_16k.pcm)
[out.pcm](/uploads/9ee13b2557c37a0a33470d7360025817/ou...when I use this command:
`voip 16000 1 32000 -framesize 40 -loss 20 -inbandfec -cbr es01_l_16k.pcm out.pcm`
[es01_l_16k.pcm](/uploads/57c337058263bb3f0dafd897c55f82ee/es01_l_16k.pcm)
[out.pcm](/uploads/9ee13b2557c37a0a33470d7360025817/out.pcm)
![image](/uploads/bb3fe48e9d57c6b62ae7daca6b7a9765/image.png)
![image](/uploads/020f2bb24020756f6dba82ec3896be56/image.png)
The output data seems to have a very bad quality. Is this normal?https://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/opus/-/issues/2343cmake - neon optimizations doesn't compile on rp2020-10-05T21:26:53ZMarcus Asteborgcmake - neon optimizations doesn't compile on rpReference: https://github.com/xiph/opus/issues/203Reference: https://github.com/xiph/opus/issues/203https://gitlab.xiph.org/xiph/opus/-/issues/2342cmake - fix lrint detection on Linux ARM2022-07-12T14:05:12ZMarcus Asteborgcmake - fix lrint detection on Linux ARMlrint detection needs -m flaglrint detection needs -m flaghttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2395Missing files in share/admin after make install2020-10-09T16:38:28ZGilouMissing files in share/admin after make installA few of the newer xsl files for admin are missing after make install:
```
~/icecast-server$ diff -r admin/ /usr/local/share/icecast/admin/ | grep -v Makefile
Only in admin/: dashboard.xsl
Only in admin/: fallbacks.xsl
Only in admin/incl...A few of the newer xsl files for admin are missing after make install:
```
~/icecast-server$ diff -r admin/ /usr/local/share/icecast/admin/ | grep -v Makefile
Only in admin/: dashboard.xsl
Only in admin/: fallbacks.xsl
Only in admin/includes: player.xsl
Only in admin/includes: playlist.xsl
Only in admin/: showlog.xsl
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2394Include libshout release 2.4.4 on website2020-10-02T20:20:37ZPhilipp SchafftInclude libshout release 2.4.4 on websiteThe following libshout release should distributed on the mirrors and then included in the website:
```
ddc44d4db0193471b1a61d41e8ec975a021da4f5af657716ecbb1eaf95231e03ac44036148f0d5bd897ba5c03f075fd67017fecfccebb4f11be56375c0e5c088 lib...The following libshout release should distributed on the mirrors and then included in the website:
```
ddc44d4db0193471b1a61d41e8ec975a021da4f5af657716ecbb1eaf95231e03ac44036148f0d5bd897ba5c03f075fd67017fecfccebb4f11be56375c0e5c088 libshout-2.4.4.tar.gz
7273d5e8da3ad10e6fc754663df5b56e8058a41f libshout-2.4.4.tar.gz
```Ralph GilesRalph Gileshttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2320Unable to disable SSL build in libshout-2.4.32020-10-21T07:10:11ZNight 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/opus/-/issues/2341Mono file size is larger than Stereo file size, for same content and settings...2020-09-29T09:18:55ZTonuricsMono file size is larger than Stereo file size, for same content and settings. [Stereo uses lower bitrate.]Hello, I have some old Mono audio recordings from a CD that are stored in Stereo FLAC files. If I transcode one into a Stereo OPUS file using:
`ffmpeg -y -i ./input.flac -codec:a libopus -compression_level 10 -vbr on -b:a 192k -metadata...Hello, I have some old Mono audio recordings from a CD that are stored in Stereo FLAC files. If I transcode one into a Stereo OPUS file using:
`ffmpeg -y -i ./input.flac -codec:a libopus -compression_level 10 -vbr on -b:a 192k -metadata replaygain_album_gain= -metadata replaygain_album_peak= -metadata replaygain_reference_loudness= -metadata replaygain_track_gain= -metadata replaygain_track_peak= -af volume=replaygain=album -loglevel quiet ./output.opus`
Results in a 7,299,479 byte (7.0 MiB) file.
```
encoder=Lavc58.91.100 libopus
Pre-skip: 312
Playback gain: 0 dB
Channels: 2
Original sample rate: 48000 Hz
Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min)
Page duration: 1000.0ms (max), 999.8ms (avg), 940.0ms (min)
Total data length: 7299479 bytes (overhead: 0.656%)
Playback length: 6m:04.933s
Average bitrate: 160 kbit/s, w/o overhead: 159 kbit/s
```
Since the audio is Mono: I thought it would be interesting to throw away the right channel. And I used this command to transcode:
`ffmpeg -y -i ./input.flac -codec:a libopus -compression_level 10 -vbr on -b:a 192k -map_channel 0.0.0 -metadata replaygain_album_gain= -metadata replaygain_album_peak= -metadata replaygain_reference_loudness= -metadata replaygain_track_gain= -metadata replaygain_track_peak= -af volume=replaygain=album -loglevel quiet ./output.opus`
Results in a 8,804,150 byte (8.4 MiB) file.
```
encoder=Lavc58.91.100 libopus
Pre-skip: 312
Playback gain: 0 dB
Channels: 1
Original sample rate: 48000 Hz
Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min)
Page duration: 1000.0ms (max), 999.8ms (avg), 940.0ms (min)
Total data length: 8804150 bytes (overhead: 0.556%)
Playback length: 6m:04.933s
Average bitrate: 193 kbit/s, w/o overhead: 191.9 kbit/s
```
Which was surprising, as I expected little to no difference between the file sizes. It appears that OPUS is using a bitrate of 160k for the Stereo version, instead of the requested 192k bitrate [which is being used in Mono].
To ensure this wasn't an issue coming from ffmpeg, I transcoded the same file using opusenc:
`opusenc --bitrate 192k ./input.flac ./output.opus`
Results in a 7,307,706 byte (7.0 MiB) file.
```
ENCODER=opusenc from opus-tools 0.2
ENCODER_OPTIONS=--bitrate 192k
Pre-skip: 312
Playback gain: -12.2891 dB
Channels: 2
Original sample rate: 44100 Hz
Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min)
Page duration: 1000.0ms (max), 999.8ms (avg), 940.0ms (min)
Total data length: 7307706 bytes (overhead: 0.667%)
Playback length: 6m:04.933s
Average bitrate: 160.2 kbit/s, w/o overhead: 159.1 kbit/s
```
Which are virtually the same results as ffmpeg.
This seems like a bug. At the very least, I would expect the Stereo bitrates to be closer to 192k.
Or maybe this some sort a Mono documentation issue? [i.e. VBR doesn't work?]
Thanks for reading.
System details:
```
Linux 5.8.12-arch1-1 #1 SMP PREEMPT Sat, 26 Sep 2020 21:42:58 +0000 x86_64 GNU/Linux
ffmpeg n4.3.1
libopusenc 0.2.1
opusenc opus-tools 0.2 (using libopus 1.3.1)
```https://gitlab.xiph.org/xiph/opus/-/issues/2340CMake - Improve compiler checks for intrinsics and prefix definitions with CO...2020-09-11T21:54:39ZMarcus AsteborgCMake - Improve compiler checks for intrinsics and prefix definitions with COMPILER_reference: https://github.com/xiph/opus/issues/198
set(SSE1_SUPPORTED 1 PARENT_SCOPE)
COMPILER_SSE1_SUPPORTED etcreference: https://github.com/xiph/opus/issues/198
set(SSE1_SUPPORTED 1 PARENT_SCOPE)
COMPILER_SSE1_SUPPORTED etchttps://gitlab.xiph.org/xiph/opus/-/issues/2339libopus 1.2.1 - Windows - Integer division by zero2020-09-01T20:43:17ZAlexander Matveevlibopus 1.2.1 - Windows - Integer division by zeroHi everyone,
Our crash detection system registered Unhandled exceptions:
silk_Decode + 2485 (edited) \silk\dec_API.c(317)
opus_decode_frame + 971 (edited) \src\opus_decoder.c(381)
opus_decode_native + 763 (edited) \src\opus_decoder.c(6...Hi everyone,
Our crash detection system registered Unhandled exceptions:
silk_Decode + 2485 (edited) \silk\dec_API.c(317)
opus_decode_frame + 971 (edited) \src\opus_decoder.c(381)
opus_decode_native + 763 (edited) \src\opus_decoder.c(693)
opus_decode + 218 (edited) \src\opus_decoder.c(782)
Unhandled exception at (edited): Integer division by zero.
/* Number of output samples */
*nSamplesOut = silk_DIV32( nSamplesOutDec * decControl->API_sampleRate, silk_SMULBB( channel_state[ 0 ].fs_kHz, 1000 ) );
We do not know how we can reproduce this issue. We started seeing this issue a year ago and we still receive these crash reports.
Please investigate the issue or suggest us what we should debug.
Thank you for helping!
Alexhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2319Building errors2020-10-21T08:53:09ZAtomtmBuilding errorsTrying to build the package and I get
```
checking for autoconf...
checking for automake 1.6 or later... automake
checking for aclocal 1.6 or later... aclocal
checking for libtool... libtoolize
Generating configuration files for libsho...Trying to build the package and I get
```
checking for autoconf...
checking for automake 1.6 or later... automake
checking for aclocal 1.6 or later... aclocal
checking for libtool... libtoolize
Generating configuration files for libshout, please wait....
aclocal -I m4
autoheader
libtoolize --automake
automake --add-missing
configure.ac:235: error: required file 'src/common/net/Makefile.in' not found
configure.ac:235: error: required file 'src/common/timing/Makefile.in' not found
configure.ac:235: error: required file 'src/common/thread/Makefile.in' not found
configure.ac:235: error: required file 'src/common/avl/Makefile.in' not found
configure.ac:235: error: required file 'src/common/httpp/Makefile.in' not found
src/Makefile.am:22: error: required directory src/common/avl does not exist
src/Makefile.am:22: error: required directory src/common/net does not exist
src/Makefile.am:22: error: required directory src/common/timing does not exist
src/Makefile.am:22: error: required directory src/common/httpp does not exist
src/Makefile.am:6: error: required directory src/common/thread does not exist
```
when using `./autogen.sh`. Any ideas please ?https://gitlab.xiph.org/xiph/opus/-/issues/2338cmake: wrong project version propagated to pkg-config file2020-11-21T18:29:34ZDonato Sciarracmake: wrong project version propagated to pkg-config fileWhen building the project as:
```
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=RELEASE
```
I get:
>>>
-- Opus library version: 0.8.0
-- Found Git: /usr/bin/git (found version "2.25.1")
-- Opus package version: 1.3.1
-- Opus pr...When building the project as:
```
mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=RELEASE
```
I get:
>>>
-- Opus library version: 0.8.0
-- Found Git: /usr/bin/git (found version "2.25.1")
-- Opus package version: 1.3.1
-- Opus project version: 1.3.1
>>>
the "Opus library version" is propagated in the pkg-config file (at the time of writing 0.8.0). I discovered this while building tag 1.3.1 locally. Including opus in my cmake project as `pkg_check_modules(OPUS REQUIRED "opus")` returned:
> -- Found opus, version 0.8.0
I can live with it locally but I think it would good to fix it!