Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2020-08-06T12:42:35Zhttps://gitlab.xiph.org/xiph/opus/-/issues/2330Make decoder state completely relocatable by avoiding inline pointer to mode2020-08-06T12:42:35ZDan RavivMake decoder state completely relocatable by avoiding inline pointer to modeCurrently, Opus Decoder state can be freely moved in memory in the same process, but it can't e.g. be copied as bytes to be sent across the network and set as a state for another decoder. But it *almost* can! The only thing preventing th...Currently, Opus Decoder state can be freely moved in memory in the same process, but it can't e.g. be copied as bytes to be sent across the network and set as a state for another decoder. But it *almost* can! The only thing preventing this use case is the `mode` pointer at the start of `CELTDecoder`. A clean decoder state on one machine has identical bytes to those of a clean state on another machine with the same architecture, except for possibly the bytes of the `mode` pointer - even when the mode itself is the same.
I'm not sure how to fix this in a way compatible with any custom mode, but it would be nice to be able to do this for the default mode, at least.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2392Tag for 2.4.4 is missing2024-01-06T20:01:19ZDavid RungeTag for 2.4.4 is missingHi! I package icecast for Arch Linux.
We currently use tarballs from this location: https://www.icecast.org/download/
However, the release for 2.4.4 is not reflected in a tag in this repository: https://gitlab.xiph.org/xiph/icecast-serv...Hi! I package icecast for Arch Linux.
We currently use tarballs from this location: https://www.icecast.org/download/
However, the release for 2.4.4 is not reflected in a tag in this repository: https://gitlab.xiph.org/xiph/icecast-server/-/tags
It would be very awesome if you could add the tag so that reproducibility can be ensured.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-website/-/issues/2053Poor contrast on main page2023-06-22T08:22:35ZTerence EdenPoor contrast on main pageThe following text is very hard to read due to low contrast between in and the background colour.
![low contrast warning](/uploads/55b8e6125728c00fc6c7312c615116b1/contrast.png)
> is free server software for streaming multimedia.
This...The following text is very hard to read due to low contrast between in and the background colour.
![low contrast warning](/uploads/55b8e6125728c00fc6c7312c615116b1/contrast.png)
> is free server software for streaming multimedia.
This is caused by the `h1` style in https://gitlab.xiph.org/xiph/icecast-website/-/blob/master/assets/css/style.css#L334
I suggest changing it from `#29495C` to `#CAD5DB` which is the background colour of the main page.Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2391Found memory leak problems on ubuntu 20.04 tls2024-01-21T02:16:55ZChaichanaFound memory leak problems on ubuntu 20.04 tlsubuntu 20.04tls icecast2 use abnormal memory, unlike ubuntu 18.04 that doesn't use memory much
Must use the command service icecast2 restart memory to return to normal But before long, it will be leak same.
- Installation of all applica...ubuntu 20.04tls icecast2 use abnormal memory, unlike ubuntu 18.04 that doesn't use memory much
Must use the command service icecast2 restart memory to return to normal But before long, it will be leak same.
- Installation of all applications
https://mediarealm.com.au/articles/icecast-https-ssl-setup-lets-encrypt/
- IMAGE
Top in image ubuntu 18.04 tls
Bottom in image ubuntu 20.04 tls
![ฟ](/uploads/d236d04fa7fc56f7c97c7d47e7937a12/ฟ.jpg)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2389Infinite loop login/passwd when htpasswd is used2020-10-26T17:36:34ZtormyvancoolInfinite loop login/passwd when htpasswd is usedSetting up **Icecast 2.4.4** Windows version (**W7 64bit** and **HTTP** protocol (I don't use HTTPS)) I got a strange issue, not reported by the error.log
The created user, gets an infinite loop of LOGIN popups.
Writing the correct logi...Setting up **Icecast 2.4.4** Windows version (**W7 64bit** and **HTTP** protocol (I don't use HTTPS)) I got a strange issue, not reported by the error.log
The created user, gets an infinite loop of LOGIN popups.
Writing the correct login and password, the popup is always returned and the user never get access.
Even giving to the user a login string as http://user:password@My_Public_Ip:8000/stream (where **/stream** is my mountpoint)
- 8000 is the port I use
- It's opened in bidirectional way on my router and firewall
- protocols: TCP/UDP
Please here below just the lines for the auth
in attachment ou find my *icecast.xml* "anonymized", as requested by your Policies, and the chunck of the *error.log* where I got the infinite loop
It resulted impossible to use Login and Password (at the moment).
Users should be very limited, that's why I put just 3
The MyAuth file is correctly generated and managed bui the UI
```
<!-- Normal mounts -->
<mount type="normal">
<mount-name>/stream</mount-name>
<max-listeners>3</max-listeners>
<authentication type="htpasswd">
<option name="filename" value="myauth"/>
<option name="allow_duplicate_users" value="0"/>
</authentication>
</mount>
```
[icecast.xml](/uploads/48fd92adae020bc51b2ab90b14e816c4/icecast.xml)
[error.log](/uploads/debf531d6f79a2f2cfd0d73f9789a687/error.log)https://gitlab.xiph.org/xiph/vorbis/-/issues/2342Getting undefined reference to `_impure_ptr' on mingw compilation2020-07-08T14:20:51ZMoritz BenderGetting undefined reference to `_impure_ptr' on mingw compilationI downloaded the libvorbis-1.3.7 tarball because I wanted to statically compile it. Compiling on mingw fails, with the main error being this:
```
make[3]: Entering directory '/g/Downloads/libvorbis-1.3.7/lib'
CCLD test_sharedbook.e...I downloaded the libvorbis-1.3.7 tarball because I wanted to statically compile it. Compiling on mingw fails, with the main error being this:
```
make[3]: Entering directory '/g/Downloads/libvorbis-1.3.7/lib'
CCLD test_sharedbook.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: test_sharedbook-sharedbook.o:sharedbook.c:(.rdata$.refptr._impure_ptr[.refptr._impure_ptr]+0x0): undefined reference to `_impure_ptr'
collect2.exe: error: ld returned 1 exit status
```
Compilation did work on my wsl, so I'm not sure what this is about. I managed to get the static library by make -j ing, but I'd still like to know why this part fails and whether there is a way to avoid this.https://gitlab.xiph.org/xiph/vorbis/-/issues/2341Broken MSDN links2020-07-04T02:02:58ZRalph GilesBroken MSDN linksThe api docs link to msdn.microsoft.com for details of how the Visual Studio 8 standard library handles stdin/out. Those links no longer work. They pages are still available through archive.org, but the docs should be reviewed to see if ...The api docs link to msdn.microsoft.com for details of how the Visual Studio 8 standard library handles stdin/out. Those links no longer work. They pages are still available through archive.org, but the docs should be reviewed to see if the details are still correct. Behaviour may well have changed in the intervening decade.https://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)