Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2023-03-18T15:58:34Zhttps://gitlab.xiph.org/xiph/opusfile/-/issues/2328Release v0.122023-03-18T15:58:34ZRalph GilesRelease v0.12Tracking issue for the 0.12 release.Tracking issue for the 0.12 release.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2387listclients not working if authentication type is url2020-10-15T10:35:27Znaitsirchlistclients not working if authentication type is urlWe have configured our Icecast (v. 2.4.4) mount with stream_auth via URL. Authentication with the source client works well. But it is comming to a strange error when listener stats are requested with the source password.
This is our mou...We have configured our Icecast (v. 2.4.4) mount with stream_auth via URL. Authentication with the source client works well. But it is comming to a strange error when listener stats are requested with the source password.
This is our mount config:
```xml
<mount type="default">
<mount-name>/stream</mount-name>
<stream-name><![CDATA[Test]]></stream-name>
<authentication type="url">
<option name="auth_header" value="icecast-auth-user: 1"/>
<option name="stream_auth" value="https://my-authentication-provider.com/api/icecast/stream_auth"/>
</authentication>
</mount>
```
Streaming with butt and source password works as expected. So the authentication works.
Now, if I try to access the URL `/admin/listclients?mount=/stream` with the source password, to see the number of connected listeners. I get a *403 Forbidden* with the message `Mountpoint in use`.
This is the request that is sent by curl:
```
GET /admin/listclients?mount=/stream HTTP/1.1
Host: server34299.streamplus.de:10106
Authorization: Basic {...}
User-Agent: curl/7.64.0
Accept: */*
```
I have checked the base64 encoded username and password in the authentication header. It is the same that is used in the source client.
The response by Icecast is:
```
HTTP/1.0 403 Forbidden
Server: Icecast 2.4.4
Connection: Close
Date: Wed, 17 Jun 2020 11:58:06 GMT
Content-Type: text/plain; charset=utf-8
Cache-Control: no-cache, no-store
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Pragma: no-cache
Mountpoint in use
```
If I remove the `<authentication type="url">` part of the config and restart the server, calling `/admin/listclients?mount=/stream` works as expected.
It looks like the listclients action has a bug if Icecast is running with stream_auth via URL. If you need any further information please let me know.
OS: Debian 10.4, Linux version 4.19.0-9-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07)
**Update:**
If I use the admin credentials to access the listener stats, it works as expected.https://gitlab.xiph.org/xiph/opus/-/issues/2326undefined behavior in silk_NSQ_del_dec_neon2020-06-14T07:36:42ZRalph Gilesundefined behavior in silk_NSQ_del_dec_neonCompiling for aarch64 with gcc 9.3.0, I get an undefined behaviour warning:
```
silk/arm/NSQ_del_dec_neon_intr.c: In function ‘silk_NSQ_del_dec_neon’:
silk/arm/NSQ_del_dec_neon_intr.c:422:55: warning: iteration 80 invokes undefined behav...Compiling for aarch64 with gcc 9.3.0, I get an undefined behaviour warning:
```
silk/arm/NSQ_del_dec_neon_intr.c: In function ‘silk_NSQ_del_dec_neon’:
silk/arm/NSQ_del_dec_neon_intr.c:422:55: warning: iteration 80 invokes undefined behavior [-Waggressive-loop-optimizations]
422 | NSQ->sLPC_Q14[ i ] = psDelDec->sLPC_Q14[ i ][ Winner_ind ];
| ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
silk/arm/NSQ_del_dec_neon_intr.c:421:9: note: within this loop
421 | for( ; i < NSQ_LPC_BUF_LENGTH; i++ ) {
| ^~~
```https://gitlab.xiph.org/xiph/opus/-/issues/2325float to short improvements2020-06-16T14:23:47ZMarcus Asteborgfloat to short improvements[22:58.40] <+jmspeex> xnorpx: About rounding, I actually think the right solution is to write functions that convert whole vectors at a time and then we can just use the normal run-time intrinsics method
[22:59.09] <+jmspeex> BTW, does S...[22:58.40] <+jmspeex> xnorpx: About rounding, I actually think the right solution is to write functions that convert whole vectors at a time and then we can just use the normal run-time intrinsics method
[22:59.09] <+jmspeex> BTW, does SSE2 even have a proper way to round without messing with rounding modeshttps://gitlab.xiph.org/xiph/Infrastructure/-/issues/2232mf5 requirements2020-07-13T16:20:45ZRalph Gilesmf5 requirements# Xiph.Org Service Requirements
With the failure of mf4, we have a decision to make about where we want to run our services.
Most essential things have been migrated to catfish. For remaining bits, please add to the list below and help...# Xiph.Org Service Requirements
With the failure of mf4, we have a decision to make about where we want to run our services.
Most essential things have been migrated to catfish. For remaining bits, please add to the list below and help prioritize.
Several options going forward
- re-install mf4 from scratch, have backups for when it fails again.
- Buy a replacement server (or several).
- Must have remote console support.
- osuosl prefers Dell PowerEdge.
- Use osuosl's openstack cluster.
- Redundant storage (but no geographical replication)
- Don't have to maintain underlying hosts.
- Can still contribute, probably by buying drives for the Ceph cluster.
The raid failure demonstrates we've not been doing a good job with administration. Whatever we do going forward, we need to make sure we have automated offsite backups and that it's much easier to configure and upgrade our various services, ideally from deployment templates stored in version control. We should periodically practice service migration and restoration.
## static sites 🔶
- Partially restored from git or older svn backup + archive.org.
- Served as static html or shtml from catfish.
- Working on auto-deployment from gitlab ci.
- Should move remaining sites from svn to git.
- media.xiph.org is served from beaufish, and wasn't affected.
## dynamic websites
- gitlab.xiph.org ✅
- vm already on catfish
- wiki.xiph.org ✅
- vm aleady on catfish
- dir.xiph.org ✅
- switched to beta vm on catfish
- awcy ✅
- vm already on catfish
- svn.xiph.org
- down, lost data
- ftp.osuosl.org has a current snapshot of releases and websites
- people.xiph.org ❌
- down, lost data.
- planet.xiph.org
- anyone still blogging?
- jenkins ❌
- down, lost data.
- should replace with gitlab-ci.
- munin ❌
- down, not high priority.
- Better replacements?
- review.xiph.org 🔶
- down, have a recent backup.
- not actively used: not planning to restore.
## releases 🔶
- downloads.xiph.org redirects from catfish to ftp.osuosl.org
- ftp site has current files.
- was backed by svn, lost recent history.
- restore svn and re-populate from ftp.osuosl.org?
- alternate: git? gitlab artifacts? Some other object store?
## shell server
- Several people used shell accounts on mf4.
- Do we need to keep providing this?
- Alternate: per-user containers? kubernetes?
## email ✅
- mail and lists already on a catfish vm.
## dns 🔶
- catfish temporarily authoritative
- Need another machine to be secondary
- alternate: Use registrar or osuosl.https://gitlab.xiph.org/xiph/Infrastructure/-/issues/2230Restore vorbis.com redirects2020-05-26T03:44:29ZRalph GilesRestore vorbis.com redirectsIIRC the vorbis.com website was full of obsolete information, so before the server crash we had it redirecting to xiph.org/vorbis. We should restore that.IIRC the vorbis.com website was full of obsolete information, so before the server crash we had it redirecting to xiph.org/vorbis. We should restore that.https://gitlab.xiph.org/xiph/opus/-/issues/2322Autogen failed on Cygwin2020-05-25T17:30:32ZredmanmaleAutogen failed on Cygwin`./autogen.sh` failed on Cygwin when trying to build from cloned repo:
```bash
Updating build configuration files, please wait....
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
autoreconf-2.69: libtoo...`./autogen.sh` failed on Cygwin when trying to build from cloned repo:
```bash
Updating build configuration files, please wait....
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
autoreconf-2.69: libtoolize failed with exit status: 1
```
Maybe it's because `ltmain.sh` is a symlink.
Building from tarball (without autogen) works fine.
**Env**
windows 10 x64
autoreconf 2.69
libtoolize 2.4.6
opus 1.3.1https://gitlab.xiph.org/xiph/Infrastructure/-/issues/2229re-create planet.xiph.org snippet2020-05-07T02:34:13ZRalph Gilesre-create planet.xiph.org snippet[xiph.org](https://www.xiph.org/) loads a teaser of recent links from planet.xiph.org. IIRC this was generated by some script connected to the planet website, and needs to be re-created now that mf4 is gone.[xiph.org](https://www.xiph.org/) loads a teaser of recent links from planet.xiph.org. IIRC this was generated by some script connected to the planet website, and needs to be re-created now that mf4 is gone.https://gitlab.xiph.org/xiph/ezstream/-/issues/2269error -3: Login failed when trying to run multiple instances of ezstream2023-02-19T15:45:02ZDan Steingarterror -3: Login failed when trying to run multiple instances of ezstreamquick thank you for writing such great software.
I am attempting to serve multiple files on multiple mount points to a single `icecast2` server instance. The first connection succeeds as expected, but the subsequents attempts fail with ...quick thank you for writing such great software.
I am attempting to serve multiple files on multiple mount points to a single `icecast2` server instance. The first connection succeeds as expected, but the subsequents attempts fail with
`ezstream[9770]: stream: default: connect: [localhost]:8000: error -3: Login failed`
when I use an `xml` configuration file structured as
```
<ezstream>
<servers>
<server>
<hostname>localhost</hostname>
<password>hackme</password>
</server>
</servers>
<streams>
<stream>
<mountpoint>/stream_x</mountpoint>
<format>MP3</format>
</stream>
</streams>
<intakes>
<intake>
<filename>file_x.mp3</filename>
</intake>
</intakes>
</ezstream>
```
where `x` above is a unique file for a unique stream. Thanks.Moritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/icecast-ices/-/issues/2322SIGUSR1 triggers resample & encoder initialising2020-03-25T23:20:09ZJonas LiljestrandSIGUSR1 triggers resample & encoder initialisingHi,
I'm having a bit of trouble with glitching audio when the metadata is updated
which I suspect is caused by using the encode feature.
In the logfile I see this
```
[2020-03-25 23:11:43] INFO signals/signal_usr1_handler Metadata u...Hi,
I'm having a bit of trouble with glitching audio when the metadata is updated
which I suspect is caused by using the encode feature.
In the logfile I see this
```
[2020-03-25 23:11:43] INFO signals/signal_usr1_handler Metadata update requested
[2020-03-25 23:11:43] INFO metadata/metadata_thread_signal tag 1 is artist=Some artist
[2020-03-25 23:11:43] INFO metadata/metadata_thread_signal tag 2 is title=Some title
[2020-03-25 23:11:43] INFO metadata/metadata_thread_signal Updating metadata
[2020-03-25 23:11:43] INFO audio/resample_initialise Initialised resampler for 2 channels, from 48000 Hz to 44100 Hz
[2020-03-25 23:11:43] INFO encode/encode_initialise Encoder initialising in VBR mode: 2 channel(s), 44100 Hz, quality
```
Here is my full `ices.xml`
```
<ices>
<background>0</background>
<logpath>/home/pi/ices/</logpath>
<logfile>ices.log</logfile>
<logsize>2048</logsize>
<loglevel>3</loglevel>
<consolelog>0</consolelog>
<pidfile>/home/pi/ices/ices.pid</pidfile>
<stream>
<instance>
<hostname></hostname>
<port>8000</port>
<password></password>
<mount>/radio.ogg</mount>
<reconnectdelay>2</reconnectdelay>
<reconnectattempts>5</reconnectattempts>
<maxqueuelength>80</maxqueuelength>
<encode>
<samplerate>44100</samplerate>
<channels>2</channels>
</encode>
<resample>
<in-rate>48000</in-rate>
<out-rate>44100</out-rate>
</resample>
</instance>
<input>
<module>stdinpcm</module>
<param name="rate">48000</param>
<param name="channels">2</param>
<param name="metadata">1</param>
<param name="metadatafilename">/var/ices2/tmp/metadata</param>
</input>
</stream>
</ices>
```
I start ices2 with the following command.
```
arecord -D plughw:1 --channels 2 --format dat -t raw | ices2 ices/ices.xml
```
Which logs
```
Recording raw data 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2383Oversized EBML headers for WebM live stream2022-03-09T19:32:39ZWolne WilnoOversized EBML headers for WebM live streamFrom version ffmpeg 4.1 or above, when trying to stream WebM video Icecast produce error: `EBML Header too large, failing`
Solution is to increase EBML Header in `format_ebml.c` from 131072 bytes (0.125 MiB) to bytes 524288 (0.5 Mib)
C...From version ffmpeg 4.1 or above, when trying to stream WebM video Icecast produce error: `EBML Header too large, failing`
Solution is to increase EBML Header in `format_ebml.c` from 131072 bytes (0.125 MiB) to bytes 524288 (0.5 Mib)
Change in https://gitlab.xiph.org/xiph/icecast-server/-/blob/master/src/format_ebml.c from `#define EBML_HEADER_MAX_SIZE 131072` to `#define EBML_HEADER_MAX_SIZE 524288`https://gitlab.xiph.org/xiph/theora/-/issues/2311Files produced by encoder_example are not properly muxed2020-03-05T22:05:53ZTristan MatthewsFiles produced by encoder_example are not properly muxedTo reproduce:
```
$> ./encoder_example ~/Videos/akiyo_qcif.y4m -o akiyo.ogv
$> ffplay akiyo.ogv
[ogg @ 0x7f0448000bc0] Broken file, keyframe not correctly marked.
Input #0, ogg, from 'akiyo.ogv':
Duration: 00:00:10.01, start: 0.00000...To reproduce:
```
$> ./encoder_example ~/Videos/akiyo_qcif.y4m -o akiyo.ogv
$> ffplay akiyo.ogv
[ogg @ 0x7f0448000bc0] Broken file, keyframe not correctly marked.
Input #0, ogg, from 'akiyo.ogv':
Duration: 00:00:10.01, start: 0.000000, bitrate: 66 kb/s
Stream #0:0: Video: theora, yuv420p, 176x144 [SAR 128:117 DAR 1408:1053], 29.97 tbr, 29.97 tbn, 29.97 tbc
[ogg @ 0x7f0448000bc0] Broken file, non-keyframe not correctly marked.
[ogg @ 0x7f0448000bc0] Broken file, non-keyframe not correctly marked.
[ogg @ 0x7f0448000bc0] Broken file, non-keyframe not correctly marked.
[ogg @ 0x7f0448000bc0] Broken file, non-keyframe not correctly marked.
[ogg @ 0x7f0448000bc0] Broken file, non-keyframe not correctly marked.
[ogg @ 0x7f0448000bc0] Broken file, non-keyframe not correctly marked.
...
```
Relevant parsing code from libavformat:
https://github.com/FFmpeg/FFmpeg/blob/e27a35e0458224ef6f47753f248ba84ec8284818/libavformat/oggdec.c#L783Tristan MatthewsTristan Matthewshttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2314Allow disabling installation of ckport database2020-02-11T08:40:50ZPetr PisarAllow disabling installation of ckport databaseI found out that libshout-2.4.3 installs libshout.ckport file although I have no use for it. An attached patch adds --disable-ckport configure option that allows users to disable the installation.
[libshout-2.4.3-Allow-disabling-ckport-...I found out that libshout-2.4.3 installs libshout.ckport file although I have no use for it. An attached patch adds --disable-ckport configure option that allows users to disable the installation.
[libshout-2.4.3-Allow-disabling-ckport-database-installation.patch](/uploads/18b0544b437ccba7c9dd352e25175354/libshout-2.4.3-Allow-disabling-ckport-database-installation.patch)https://gitlab.xiph.org/xiph/ogg/-/issues/2299Invalid shift in oggpack_read()2020-01-29T15:17:19ZMichael NiedermayerInvalid shift in oggpack_read()ossfuzz of ffmpeg - libvorbis (which uses libogg) possibly found a bug in libogg
```
bitwise.c:396:23: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
#0 0x7f3378 in oggpack_read /src/ogg/src/bitwise...ossfuzz of ffmpeg - libvorbis (which uses libogg) possibly found a bug in libogg
```
bitwise.c:396:23: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
#0 0x7f3378 in oggpack_read /src/ogg/src/bitwise.c:396:23
#1 0x7cb1eb in _vorbis_unpack_info /src/vorbis/lib/info.c:212:15
#2 0x7cb0f5 in vorbis_synthesis_headerin /src/vorbis/lib/info.c:409:16
#3 0x4c2d82 in oggvorbis_decode_init /src/ffmpeg/libavcodec/libvorbisdec.c:108:12
```
The code is possibly in need of a cast to unsigned but i have not looked deeply into it.
The full report and 2 testcases are at the link below (this is possible not publically accessible but i can give access to this to anyone from xiph or libogg who wants to look into it). The testcase would require ffmpeg+ossfuzz+libvorbis+libogg in a bloated docker image though sadly, so iam not sure how useful that testcase would be. For me it does not reproduce outside docker.
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18710https://gitlab.xiph.org/xiph/ogg/-/issues/2298include file wrong on macOS2020-11-14T23:54:53ZHelmut K. C. Tessarekinclude file wrong on macOSThe following change in `os_types.h` from ogg **1.3.3**
```
#elif (defined(__APPLE__) && defined(__MACH__)) /* MacOS X Framework build */
# include <inttypes.h>
```
to **1.3.4**
```
#elif (defined(__APPLE__) && defined(__MACH__)) /* M...The following change in `os_types.h` from ogg **1.3.3**
```
#elif (defined(__APPLE__) && defined(__MACH__)) /* MacOS X Framework build */
# include <inttypes.h>
```
to **1.3.4**
```
#elif (defined(__APPLE__) && defined(__MACH__)) /* MacOS X Framework build */
# include <sys/types.h>
```
causes other libs to error out during compile:
eg. for vorbis:
```
CC synthesis.lo
In file included from analysis.c:20:
In file included from /Users/Shared/ffmpeg/sw/include/ogg/ogg.h:24:
/Users/Shared/ffmpeg/sw/include/ogg/os_types.h:75:12: error: unknown type name 'uint16_t'
typedef uint16_t ogg_uint16_t;
^
/Users/Shared/ffmpeg/sw/include/ogg/os_types.h:77:12: error: unknown type name 'uint32_t'
typedef uint32_t ogg_uint32_t;
^
/Users/Shared/ffmpeg/sw/include/ogg/os_types.h:79:12: error: unknown type name 'uint64_t'
typedef uint64_t ogg_uint64_t;
^
CC psy.lo
CC info.lo
3 errors generated.
```
I changed the include file to `stdint.h` and all is fine again.
I'm not sure why someone changed it in the first place, but it broke compiling on macOS.https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2313ezstream hangs with libshout2019-11-18T08:44:49Zzygmundezstream hangs with libshoutHi,
Some time ago I was reported ezstream hangs with version of libshout 2.4.3 but problem still exists even with master branch, after few houres stream stops and I need to kill -9 ezstream.
When I downgraded to 2.4.1 everything is perf...Hi,
Some time ago I was reported ezstream hangs with version of libshout 2.4.3 but problem still exists even with master branch, after few houres stream stops and I need to kill -9 ezstream.
When I downgraded to 2.4.1 everything is perfect.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2379Consider adding fallback support for WolfSSL2024-01-21T02:16:56ZUnit 193Consider adding fallback support for WolfSSLHowdy,
WolfSSL has an OpenSSL compatibility layer, so if a distribution can't offer Icecast linked with OpenSSL, using WolfSSL might be a possibility. I've made and tested a minimal patch, and with git master of WolfSSL Icecast is full...Howdy,
WolfSSL has an OpenSSL compatibility layer, so if a distribution can't offer Icecast linked with OpenSSL, using WolfSSL might be a possibility. I've made and tested a minimal patch, and with git master of WolfSSL Icecast is fully functional.
Would you consider adding support for it? It was mentioned that this might be more fitting for the 2.4 series.
Example patch attached (note this is not the version I was testing).
[icecast-wolfssl.patch](/uploads/5690621487ec0fc7ee689d161032b5ef/icecast-wolfssl.patch)
~Unit 193Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2311Add support for JWT tokens2023-03-18T10:25:44ZThiago SantosAdd support for JWT tokensAdds support for setting a JWT authorization token (or any opaque token) to libshout. It will be used as an "Authorization: Bearer <token>" header instead of the usual user/password header for HTTP requests.Adds support for setting a JWT authorization token (or any opaque token) to libshout. It will be used as an "Authorization: Bearer <token>" header instead of the usual user/password header for HTTP requests.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/liboggz/-/issues/7Ten off by one errors?2019-08-13T16:55:34ZRalph GilesTen off by one errors?Moved from [ogg #2197](https://gitlab.xiph.org/xiph/ogg/issues/2197) reported by @dcb314.
[timespec.c:123]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowi...Moved from [ogg #2197](https://gitlab.xiph.org/xiph/ogg/issues/2197) reported by @dcb314.
[timespec.c:123]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it. [timespec.c:127]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it. [timespec.c:131]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it. [timespec.c:135]: timespec.c:139 timespec.c:143 timespec.c:147 timespec.c:151 timespec.c:155https://gitlab.xiph.org/xiph/icecast-server/-/issues/2378There should be a stats value indicating how if a stream is in a stable state2022-02-27T20:06:54ZPhilipp SchafftThere should be a stats value indicating how if a stream is in a stable stateThere should be a stats value that indicates if a stream has been proven stable. That is at least connected for a given minimum amount of time and sending data. This could be used by the fallback logic to avoid switching 'back' to a flap...There should be a stats value that indicates if a stream has been proven stable. That is at least connected for a given minimum amount of time and sending data. This could be used by the fallback logic to avoid switching 'back' to a flapping stream.Philipp SchafftPhilipp Schafft