Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2022-03-08T12:28:21Zhttps://gitlab.xiph.org/xiph/opus/-/issues/2353Encoding silence as VOIP results in low-level noise in output of decoder2022-03-08T12:28:21ZFrancis QuiersEncoding silence as VOIP results in low-level noise in output of decoderIn a scenario where speech is followed by pure silence (for example in a VoIP application where the user might mute their microphone), and DTX is disabled, it seems that the Opus (SILK) decoder generates very low-level noise (around -56d...In a scenario where speech is followed by pure silence (for example in a VoIP application where the user might mute their microphone), and DTX is disabled, it seems that the Opus (SILK) decoder generates very low-level noise (around -56dB). I am not sure whether this is a known, and potentially expected/desired behaviour, but I thought I would report it anyway. It feels that it would be nice if the transcoded output in this case could still be pure silence. This is the case if changing the application type from "voip" to "audio". Could you please comment? Many thanks.
Steps to reproduce (environment: Linux Ubuntu 18.04 64-bit, Opus 1.3.1):
```
./autogen.sh
./configure --enable-fixed-point --disable-doc --with-pic
./opus_demo voip 16000 1 64000 speech_and_silence.raw speech_and_silence_output.raw
```
[speech_and_silence.raw](/uploads/14ca8c17d68b6b0322300f53e5d3bdf9/speech_and_silence.raw)
[speech_and_silence_output.raw](/uploads/3caa5cfed4ce43ef1b94e29f6b729d22/speech_and_silence_output.raw)https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2331Add an option to disable tools2022-04-10T17:32:00ZFabrice FontaineAdd an option to disable toolsAs I'm unable to fork the project, please find attached a patch that allow the user to disable tools.
[0001-configure.ac-add-an-option-to-disable-tools.patch](/uploads/853966c2c49c76d002f218578e68c1a5/0001-configure.ac-add-an-option-to-...As I'm unable to fork the project, please find attached a patch that allow the user to disable tools.
[0001-configure.ac-add-an-option-to-disable-tools.patch](/uploads/853966c2c49c76d002f218578e68c1a5/0001-configure.ac-add-an-option-to-disable-tools.patch)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2406Icecast SSL stream information2022-04-20T09:19:24ZAlain SeysIcecast SSL stream informationNot realy a issue rather a question we have a icecast server if we listen (vlc)to the http stream we can get the current track information if we listen to the https stream(vlc) we only can hear the stream but no track information is serv...Not realy a issue rather a question we have a icecast server if we listen (vlc)to the http stream we can get the current track information if we listen to the https stream(vlc) we only can hear the stream but no track information is served.
is there a way to also give the track information trough ssl ?
on our website we use a php script to get the trackinformation from a https stream but in vlc we cant get it to work.
please advise mehttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2330URL-escaping ?=& in the mountpoint prevents mountpoints with query strings2022-04-09T19:27:00ZNiko DittmannURL-escaping ?=& in the mountpoint prevents mountpoints with query strings#11b83da8 breaks connecting to mountpoints with a query string.
We are running a libshout compatible streaming server (at least we try ;) ) which uses a query string parameter to set a priority for a source client. This way a newly conn...#11b83da8 breaks connecting to mountpoints with a query string.
We are running a libshout compatible streaming server (at least we try ;) ) which uses a query string parameter to set a priority for a source client. This way a newly connecting source client can auto-kick an existing source client by providing a higher priority. I only now realized that by updating from my old libshout 2.3.1 on debian to 2.4.3 on ubuntu query string get now escaped:
```
SOURCE /m1?prio=3 HTTP/1.0 "ices/0.4 libshout/2.3.1"
SOURCE /m1%3fprio%3d3 HTTP/1.0 "ices/0.4 libshout/2.4.3"
```
I realize that the exact semantics of "mountpoints" aren't formaly specified (or are they?) but this completely broke my expectation of a mount point basically just being the path of a URL.
I opened an [issue on github](https://github.com/xiph/Icecast-libshout/issues/22) before I found the repo here. I'm gonna close over there and refer to this issue here.https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2329Unbreak shout.pc (on non-GNU systems)2021-04-16T12:46:56ZMoritz GrimmUnbreak shout.pc (on non-GNU systems)The pkgconfig file shout.pc contains a list of requirements starting with an empty value:
`Requires.private: , ogg, vorbis, theora, speex, libssl`
This is not well-formed and doesn't work with pkgconfig on OpenBSD (for example). Since ...The pkgconfig file shout.pc contains a list of requirements starting with an empty value:
`Requires.private: , ogg, vorbis, theora, speex, libssl`
This is not well-formed and doesn't work with pkgconfig on OpenBSD (for example). Since libogg is a must-have dependency, the simple fix is to just start the list with it.
Patch: [libshout_proper_shout_pc.diff](/uploads/5cf7acd7e02ea62a9712a79375a6b663/libshout_proper_shout_pc.diff)https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2328libshout 2.4.5 mp3 song metadata not updating2022-04-12T11:02:02ZStephen Fairchildlibshout 2.4.5 mp3 song metadata not updatingCalls to shout_set_metadata() are not updating the song metadata on the connected Icecast server when libshout 2.4.5 is streaming in mp3 format. My testing indicates the issue is not present in libshout version 2.4.4.
[libshout_mp3_met...Calls to shout_set_metadata() are not updating the song metadata on the connected Icecast server when libshout 2.4.5 is streaming in mp3 format. My testing indicates the issue is not present in libshout version 2.4.4.
[libshout_mp3_metadata.c](/uploads/d163d9fcbb3757b333b1ac2bb5d999e6/libshout_mp3_metadata.c)https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2327When preventing caller "abuse-after-free", abort()2023-03-09T09:48:58ZMoritz GrimmWhen preventing caller "abuse-after-free", abort()The shout_free() function attempts to prevent use-after-free issues by not doing anything in case the caller still has an open connection. While this can mitigate security issues in calling applications, it covers up these flaws in the f...The shout_free() function attempts to prevent use-after-free issues by not doing anything in case the caller still has an open connection. While this can mitigate security issues in calling applications, it covers up these flaws in the form of hard to detect memory leaks.
Libshout should either leave the responsibility for these kinds of defects where they belong and not perform the "is a connection still open?" check, as it will never be able to solve _all_ of these problems (and applications running into this _will_ have other problems as well and are in some dire need of SAST tools).
However, since there is some merit to this safeguard, at least make it highly visible with a proper, noisy abort(): [shout_free_abort_before_use-after-free.diff](/uploads/7eb49ff1ce810e41d523e54cbb6f8428/shout_free_abort_before_use-after-free.diff) -- it might be a wake-up call!https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2326logic error in shout_free()2021-02-09T00:03:36ZMoritz Grimmlogic error in shout_free()A logic error in shout_free() prevents memory from being released unless there is an active connection. It should be reversed. This is a regression that was introduced with the switch to the new internal state machine.
Proposed fix: [sh...A logic error in shout_free() prevents memory from being released unless there is an active connection. It should be reversed. This is a regression that was introduced with the switch to the new internal state machine.
Proposed fix: [shout_free_logic_error_fix.diff](/uploads/efff24f90ef25e582fdfb42e1e6985b2/shout_free_logic_error_fix.diff)https://gitlab.xiph.org/xiph/opus/-/issues/2352[Question]How to edit metadata without re-encoding ?2021-01-30T21:24:09Zsebma[Question]How to edit metadata without re-encoding ?Hi,
How can I edit metadata without re-encoding ?Hi,
How can I edit metadata without re-encoding ?https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2327Don't forget to sync translations2023-03-09T10:41:32ZMario BlättermannDon't forget to sync translationsHello,
as you might know, the translations of vorbis-tools are maintained at GNU TP [1]. Obviously the translations haven't been synced with the Git content for years. For example, I can't found my German translation which resides there...Hello,
as you might know, the translations of vorbis-tools are maintained at GNU TP [1]. Obviously the translations haven't been synced with the Git content for years. For example, I can't found my German translation which resides there for more than six years. At least the last two releases 1.4.1 and 1.4.2 don't contain it.
[1] http://translationproject.org/domain/vorbis-tools.htmlPhilipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/rnnoise/-/issues/3rnnoise have any patents inside?2021-03-11T07:14:31ZVasiliy Glazovrnnoise have any patents inside?Hi.
I want to add rnnoise library to Fedora GNU/Linux repository. And I need to know is rnnoise use any patented technology or algorithm?Hi.
I want to add rnnoise library to Fedora GNU/Linux repository. And I need to know is rnnoise use any patented technology or algorithm?https://gitlab.xiph.org/xiph/icecast-server/-/issues/2405Recovering from fallback directs to wrong mount2021-05-08T14:13:53ZLauri HeikkiläRecovering from fallback directs to wrong mountDon't know should one re-open old issue https://gitlab.xiph.org/xiph/icecast-server/-/issues/642 or not, but here's a new one...
One has two mounts (/mount_a and mount_b) with the same fallback mount<br>
-> The sources for both relayed ...Don't know should one re-open old issue https://gitlab.xiph.org/xiph/icecast-server/-/issues/642 or not, but here's a new one...
One has two mounts (/mount_a and mount_b) with the same fallback mount<br>
-> The sources for both relayed mounts (/remote_mount_a and /remote_mount_b) go down<br>
-> All listeners get directed to /backup mount<br>
-> Both relayed sources recover<br>
-> All listeners get directed to single mount, for example /mount_a, even though they were listening /mount_b before
```
<relay>
<server>a.remote.server.com</server>
<mount>/remote_mount_a</mount>
<local-mount>/mount_a</local-mount>
</relay>
<mount type="normal">
<mount-name>/mount_a</mount-name>
<fallback-mount>/backup</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
<relay>
<server>remote.server.com</server>
<mount>/remote_mount_b</mount>
<local-mount>/local_mount_b</local-mount>
</relay>
<mount type="normal">
<mount-name>/mount_b</mount-name>
<fallback-mount>/backup</fallback-mount>
<fallback-override>1</fallback-override>
</mount>
<relay>
<server>b.remote.server.com</server>
<mount>/remote_backup</mount>
<local-mount>/backup</local-mount>
<on-demand>1</on-demand>
</relay>
```Icecast 2.5.0https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2325No connection in nonblocking mode, retry shout_open() fails.2022-04-12T11:02:27ZDaniel SchürmannNo connection in nonblocking mode, retry shout_open() fails.Probably since 2.4.2 and https://gitlab.xiph.org/xiph/icecast-libshout/-/commit/032aa10d93553ede0bbfb1c2f094f9794f12da15
shout_open() returns SHOUTERR_RETRY instead retry until timeout in
https://gitlab.xiph.org/xiph/icecast-libshout/-/...Probably since 2.4.2 and https://gitlab.xiph.org/xiph/icecast-libshout/-/commit/032aa10d93553ede0bbfb1c2f094f9794f12da15
shout_open() returns SHOUTERR_RETRY instead retry until timeout in
https://gitlab.xiph.org/xiph/icecast-libshout/-/blob/master/src/connection.c#L464
Unfortunately it is not possible without closing shout to continue the iteration using shout_open().
It fails with SHOUTERR_CONNECTED
https://gitlab.xiph.org/xiph/icecast-libshout/-/blob/master/src/shout.c#L185
Calling shout_close() does not fix the issue, because it starts the iteration from the beginning.
Is there another public function that can be called?
In my test 70 loops are required to open the connection.https://gitlab.xiph.org/xiph/rnnoise/-/issues/2Reduce number of symbols provided by library?2021-01-22T21:01:57ZPetter ReinholdtsenReduce number of symbols provided by library?This is the complete list of symbols provided by the library:
```
% nm ./.libs/librnnoise.a |awk '/ T / {print $3}'|sort
_celt_autocorr
celt_fir
celt_iir
_celt_lpc
celt_pitch_xcorr
compute_band_corr
compute_band_energy
compute_dense
com...This is the complete list of symbols provided by the library:
```
% nm ./.libs/librnnoise.a |awk '/ T / {print $3}'|sort
_celt_autocorr
celt_fir
celt_iir
_celt_lpc
celt_pitch_xcorr
compute_band_corr
compute_band_energy
compute_dense
compute_gru
compute_rnn
interp_band_gain
opus_fft_alloc
opus_fft_alloc_arch_c
opus_fft_alloc_twiddles
opus_fft_c
opus_fft_free
opus_fft_free_arch_c
opus_fft_impl
opus_ifft_c
pitch_downsample
pitch_filter
pitch_search
remove_doubling
rnnoise_create
rnnoise_destroy
rnnoise_get_frame_size
rnnoise_get_size
rnnoise_init
rnnoise_model_free
rnnoise_model_from_file
rnnoise_process_frame
%
```
All the rnnoise_* symbols look good, but what about the rest? They might cause symbol conflicts with users of the library. Perhaps all exported symbols should have the rnnoise_ prefix?https://gitlab.xiph.org/xiph/opus/-/issues/2351fixed point compile on armv5te architecture2021-01-16T12:19:50ZDavid Summersfixed point compile on armv5te architectureTrying to compile fixed point on armv5te architecture, using opus 1.3.1. I configure with:
`CPPFLAGS="-D_FORTIFY_SOURCE=2" CFLAGS="-march=armv5te -O2 -pipe -fstack-protector-strong -fno-plt" CXXFLAGS="-march=armv5te -O2 -pipe -fstack-p...Trying to compile fixed point on armv5te architecture, using opus 1.3.1. I configure with:
`CPPFLAGS="-D_FORTIFY_SOURCE=2" CFLAGS="-march=armv5te -O2 -pipe -fstack-protector-strong -fno-plt" CXXFLAGS="-march=armv5te -O2 -pipe -fstack-protector-strong -fno-plt" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro" ./configure --prefix=/usr --disable-static --enable-custom-modes --enable-fixed-point --disable-silent-rules`
The make fails with:
```
gcc -DHAVE_CONFIG_H -I. -I./include -I./celt -I./silk -I./silk/float -I./silk/fixed -D_FORTIFY_SOURCE=2 -march=armv5te -O2 -pipe -fstack-protector-strong -fno-plt -fvisibility=hidden -W -Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes -MT celt/kiss_fft.lo -MD -MP -MF celt/.deps/kiss_fft.Tpo -c celt/kiss_fft.c -fPIC -DPIC -o celt/.libs/kiss_fft.o
{standard input}: Assembler messages:
{standard input}:971: Error: first transfer register must be even -- `ldrd r9,r10,[r3,#-8]'
{standard input}:1148: Error: first transfer register must be even -- `ldrd r5,r6,[r1,fp]'
```
So looks like some faulty machine code for the armv5te architecture. Haven't yet worked out where this machine code is generated ...https://gitlab.xiph.org/xiph/opus/-/issues/2350cmake - add API test for shared library2021-01-08T17:25:15ZMarcus Asteborgcmake - add API test for shared libraryhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/23242.4.5 not tagged2022-04-09T19:22:43ZBe Ing2.4.5 not taggedSource code for version 2.4.5 is available to download at http://downloads.xiph.org/releases/libshout and the release is listed in https://gitlab.xiph.org/xiph/icecast-libshout/-/blob/master/NEWS#L1 but there is no Git tag.Source code for version 2.4.5 is available to download at http://downloads.xiph.org/releases/libshout and the release is listed in https://gitlab.xiph.org/xiph/icecast-libshout/-/blob/master/NEWS#L1 but there is no Git tag.https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2323Build on Windows / CMake2023-03-09T10:24:28ZJan HolthuisBuild on Windows / CMakeI'm unable to find documentation regarding building on Windows.
Would you be interested in a CMake build file?I'm unable to find documentation regarding building on Windows.
Would you be interested in a CMake build file?https://gitlab.xiph.org/xiph/opus/-/issues/2349When packet loss (less than 30%) exists in the code stream, the decoded resul...2021-01-06T12:40:33ZJie YangWhen packet loss (less than 30%) exists in the code stream, the decoded results will be distorted?When opus is used for codec, if packet loss exists in the code stream, the opus decoding to compensate will occur sound breakage. Especially when the packet loss rate is high, this phenomenon is easy to happen. After many tests, we found...When opus is used for codec, if packet loss exists in the code stream, the opus decoding to compensate will occur sound breakage. Especially when the packet loss rate is high, this phenomenon is easy to happen. After many tests, we found that this abnormal situation would occur at either 16K or 48K sampling rate. We also tried the latest 1.3 version, and unfortunately, this phenomenon hasn't gone away. Now we send you the results of raw data, encoded stream, packet loss and decoding, hoping to get a reply.[data_opus_1.rar](/uploads/bf8412434c03c1982d5112acab866208/data_opus_1.rar)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2404Issues in log file dublicate items since start of 20212021-01-04T20:47:54ZHans-Georg AlthoffIssues in log file dublicate items since start of 2021I have figured out, that user access is repeating the same data several times since the beginning of the year.
Usual the lines are ordered by time. Now I can see, that ip adresses are repeating with the same date and time.
This is corr...I have figured out, that user access is repeating the same data several times since the beginning of the year.
Usual the lines are ordered by time. Now I can see, that ip adresses are repeating with the same date and time.
This is corrupting my programm[access.log.old](/uploads/10f05b8ae9d6960d4a921d4654ab6e9c/access.log.old), which I use to analyse the data.