Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2024-01-20T23:53:52Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2403HTTP 409 on reconnect2024-01-20T23:53:52ZGlenn SimsHTTP 409 on reconnectI recently updated our Icecast software from 2.4.4 to 2.4.99.2 (built via source). The internet at my station goes out sometimes and shuts off the stream. Our program, Broadcast Using This Tool, is designed to automatically reconnect t...I recently updated our Icecast software from 2.4.4 to 2.4.99.2 (built via source). The internet at my station goes out sometimes and shuts off the stream. Our program, Broadcast Using This Tool, is designed to automatically reconnect to the server if the connection dies. However, when the internet comes back on, the log says "server answered with 409!", which means an HTTP conflict.
Icecast is hosted on AWS EC2 running on ports 80 and 443. It is forwarded through my subdomain has an A record with an SSL certificate in the `icecast.xml` file. Since then I have not made any changes to the DNS. This issue had started happening after the upgrade to 2.4.99.2.
This is my BUTT log open in Notepad++ showing the error:
![Screenshot_2020-11-06_191540](/uploads/815c58d23d7cea1510d9fa0184b3d155/Screenshot_2020-11-06_191540.png)Icecast 2.5 rc1Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/liboggplay/-/issues/1liboggplay mishandles live ogg streams in Firefox2023-06-08T14:38:55ZMilesliboggplay mishandles live ogg streams in Firefox(speculation)
See the following bug on Mozilla's tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=611519
Seems pretty likely the bug is actually in liboggplay. When an audio element points to a live stream and it is played in the...(speculation)
See the following bug on Mozilla's tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=611519
Seems pretty likely the bug is actually in liboggplay. When an audio element points to a live stream and it is played in the browser, it works fine for roughly 20 minutes before severe stutter sets in. Pressing play also tends to play permanently cached audio instead of the actual stream. Is liboggplay perhaps treating this case as an infinitely large file transfer instead of a live stream?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/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/2401Allow `icy-metadata` and `icy-metaint` in default CORS configuration2022-02-26T18:35:51ZEthan HalsallAllow `icy-metadata` and `icy-metaint` in default CORS configurationI noticed that many of the public streams I've encountered have a wide-open Access-Control-Allow-Origin policy, but do not allow access to request the `Icy-Metadata` header nor allow access to read the `Icy-MetaInt` header in the respons...I noticed that many of the public streams I've encountered have a wide-open Access-Control-Allow-Origin policy, but do not allow access to request the `Icy-Metadata` header nor allow access to read the `Icy-MetaInt` header in the response. This prevents any clients that honor CORS (i.e. browsers) from requesting or reading icy metadata.
This patch is to allow cross-origin access to the `Icy-MetaData` and `Icy-MetaInt` headers by default. Also, this patch inserts the `Access-Control-Allow-Headers` and `Access-Control-Expose-Headers` into the default XML configuration so that icy metadata works by default. Users can opt-out of it like they can with `Access-Control-Allow-Origin: *`.
The main use-case is to enable browsers to read icy metadata via a cross-origin request. I'm building a client side library that does that here: [icecast-metadata-js](https://github.com/eshaz/icecast-metadata-js). The inline metadata offers immediate metadata updates with no noticeable latency, which is really valuable in certain contexts, like for broadcasting police / fire scanner metadata, or ad insertions, etc.
[0001-feat-add-icy-metadata-support-for-cors.patch](/uploads/fb696baa19b3dfe8419021d66d52e2a3/0001-feat-add-icy-metadata-support-for-cors.patch)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/2397Streamers get kicked upon DJ connection.2020-10-16T15:25:20ZCallum OKaneStreamers get kicked upon DJ connection.Hey, on my radioserver, running Icecast 2, whenever a streamer connects, all the listeners are disconnected from the stream. This only happens for some DJ's using software like VirtualDJ which many of ours do. We drop almost 100 listener...Hey, on my radioserver, running Icecast 2, whenever a streamer connects, all the listeners are disconnected from the stream. This only happens for some DJ's using software like VirtualDJ which many of ours do. We drop almost 100 listeners, and this is quite frustrating, anyone able to help?https://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/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/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/vorbis-tools/-/issues/2326No git tags2020-08-15T19:17:21ZTomasz KłoczkoNo git tagsLooks like currently there is no any git tags marking exact versions.
BTW: do you have any plans to make new release soon?Looks like currently there is no any git tags marking exact versions.
BTW: do you have any plans to make new release soon?https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2325ogg123: feeding FLAC file via STDIN fails2020-08-13T14:54:45ZSebastian Hübnerogg123: feeding FLAC file via STDIN failsHi,
I tried to feed ogg123 with an FLAC file via STDIN, but ogg123 is telling me it's corrupt.
```
> ogg123 - < HD_2020-01-30_465376506.flac
Audio Device: Advanced Linux Sound Architecture (ALSA) output
Error opening - using the og...Hi,
I tried to feed ogg123 with an FLAC file via STDIN, but ogg123 is telling me it's corrupt.
```
> ogg123 - < HD_2020-01-30_465376506.flac
Audio Device: Advanced Linux Sound Architecture (ALSA) output
Error opening - using the oggvorbis module. The file may be corrupted.
> cat HD_2020-01-30_465376506.flac | ogg123 -
Audio Device: Advanced Linux Sound Architecture (ALSA) output
Error opening - using the oggvorbis module. The file may be corrupted.
```
If I give the FLAC file as a normal input it is working:
```
ogg123 HD_2020-01-30_465376506.flac
Audio Device: Advanced Linux Sound Architecture (ALSA) output
Playing: HD_2020-01-30_465376506.flac
FLAC stream: 16 bits, 2 channel, 44100 Hz
Artist: Flamingo Pier
Encoded by: **removed**
Heardis_id: HD_2020-01-30_465376506
Title: Boogie Meltdown
ReplayGain (Track): -6.27 dB
ReplayGain Peak (Track): 0.986664
Done.
```
I tried it on Ubuntu 20.04 (vorbis-tools 1.4.0-11) and Ubuntu 18.04 (vorbis-tools 1.4.0-10.1) and both gave me the same error.
Is this a bug or just not possible with FLAC files?
thanks in advance :)https://gitlab.xiph.org/xiph/opus/-/issues/2334cmake - Build all tests and programs for Opus in CMake build2020-08-09T04:24:33ZMarcus Asteborgcmake - Build all tests and programs for Opus in CMake buildAC:
- Add minor unittest for dll and static build
- Add missing programs for dll and static buildAC:
- Add minor unittest for dll and static build
- Add missing programs for dll and static buildhttps://gitlab.xiph.org/xiph/opus/-/issues/2333cmake - Add Doxygen doc generation to CMakebuild2020-08-09T04:24:52ZMarcus Asteborgcmake - Add Doxygen doc generation to CMakebuildhttps://vicrucann.github.io/tutorials/quick-cmake-doxygen/https://vicrucann.github.io/tutorials/quick-cmake-doxygen/https://gitlab.xiph.org/xiph/opus/-/issues/2331Enable NEON optimizations for Windows ARM642020-08-09T04:09:13ZMarcus AsteborgEnable NEON optimizations for Windows ARM64Windows on ARM64 uses another header then the general neon one.
AC:
- Enable Neon for Windows ARM in CMake
- Fix includes
- Verify on ARM64 deviceWindows on ARM64 uses another header then the general neon one.
AC:
- Enable Neon for Windows ARM in CMake
- Fix includes
- Verify on ARM64 device