Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2022-02-19T09:59:17Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2417After working days without problem Icecast 2.4.4 not trying to update relays ...2022-02-19T09:59:17ZdanielsoheilAfter working days without problem Icecast 2.4.4 not trying to update relays from master serverthis my icecast.xml config:
```
<icecast>
<location>Iran</location>
<admin>info@myts3.ir</admin>
<limits>
<clients>50000</clients>
<sources>1000</sources>
<queue-size>307200</queue-size>
<...this my icecast.xml config:
```
<icecast>
<location>Iran</location>
<admin>info@myts3.ir</admin>
<limits>
<clients>50000</clients>
<sources>1000</sources>
<queue-size>307200</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>600</header-timeout>
<source-timeout>600</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>196608</burst-size>
</limits>
<authentication>
<source-password>removed</source-password>
<relay-password>removed</relay-password>
<admin-user>admin</admin-user>
<admin-password>removed</admin-password>
</authentication>
<hostname>radio.myts3.ir</hostname>
<listen-socket>
<port>18000</port>
</listen-socket>
<http-headers>
<header name="Access-Control-Allow-Origin" value="*" />
</http-headers>
<master-server>192.168.100.53</master-server>
<master-server-port>8000</master-server-port>
<master-update-interval>30</master-update-interval>
<master-password>removed</master-password>
<relays-on-demand>0</relays-on-demand>
<fileserve>1</fileserve>
<paths>
<basedir>/usr/share/icecast</basedir>
<logdir>/var/log/icecast</logdir>
<webroot>/usr/share/icecast/web</webroot>
<adminroot>/usr/share/icecast/admin</adminroot>
<alias source="/" destination="/status-json.xsl"/>
</paths>
<logging>
<accesslog>access.log</accesslog>
<errorlog>error.log</errorlog>
<loglevel>4</loglevel>
<logsize>100000</logsize>
</logging>
<security>
<chroot>0</chroot>
</security>
</icecast>
```
i have logs too, its 66mB i can't send it here.https://gitlab.xiph.org/xiph/oggdsf/-/issues/1522After installing and removing MadFlac Ogg codec will not work.2009-03-11T23:15:39ZicarusAfter installing and removing MadFlac Ogg codec will not work.I think I have found a potential bug/conflict with oggcodecs_0.81.15562-x64.
I installed madflac 1.8 from http://madshi.net/madFlac.rar, then unintstalled it. I then installed oggcodecs_0.81.15562-x64. The installation appears to works ...I think I have found a potential bug/conflict with oggcodecs_0.81.15562-x64.
I installed madflac 1.8 from http://madshi.net/madFlac.rar, then unintstalled it. I then installed oggcodecs_0.81.15562-x64. The installation appears to works properly, but any flac files will not play.
I realise that this situation might be caused by the madflac codec as I have installed oggcodecs_0.81.15562-x64 in the past when I hadn't installed madflac previously and it worked fine so I have also sent this info to the maker of madflac.Cristian AdamCristian Adamhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2183Adjust Icecast's Auth Realm2021-10-30T09:32:58ZMarvin ScholzAdjust Icecast's Auth RealmCurrently Icecast is using the following header for telling the server how to do auth:
`WWW-Authenticate: Basic realm="Icecast2 Server"`
The Auth realm name should probably adjusted to just one of the following:
- 'Icecast Server'
- '...Currently Icecast is using the following header for telling the server how to do auth:
`WWW-Authenticate: Basic realm="Icecast2 Server"`
The Auth realm name should probably adjusted to just one of the following:
- 'Icecast Server'
- 'Icecast 2 Server'
- 'Icecast Admin Interface'
- value of server name + ' Server'
(please leave a comment which one you would go for, even better if you have a good reason for it)Icecast 3.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2145Adding <outro> file for mountpoints2018-03-06T12:49:38ZJordan EricksonAdding <outro> file for mountpointsHello, I thought of the idea of adding an <outro> file for mountpoints. This would operate like <intro>, but the file would be played immediately after a source disconnects and before the <intro> of any fallback mounts that listeners are...Hello, I thought of the idea of adding an <outro> file for mountpoints. This would operate like <intro>, but the file would be played immediately after a source disconnects and before the <intro> of any fallback mounts that listeners are moved to. Thank you for your consideration =)Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/opus/-/issues/2364Added the OPUS_SET_INBAND_FEC(2) option2023-07-27T04:04:32Zhua yanAdded the OPUS_SET_INBAND_FEC(2) optionWhat are the benefits of adding the OPUS_SET_INBAND_FEC(2) option? How does it affect audio quality? How does it affect audio quality compared to OPUS_SET_INBAND_FEC(1)?What are the benefits of adding the OPUS_SET_INBAND_FEC(2) option? How does it affect audio quality? How does it affect audio quality compared to OPUS_SET_INBAND_FEC(1)?https://gitlab.xiph.org/xiph/vorbis-tools/-/issues/317Add warning when -M is below average for a specific -q2018-01-22T04:18:38ZjazAdd warning when -M is below average for a specific -q```
Using -q x -M y (for streaming purposes), when y is below the average of -q,
it is ignored, although oggenc says " using constrained VBR ( ... , max br
y ) ".
It might be useful to add a warning about this, because if not, it simp...```
Using -q x -M y (for streaming purposes), when y is below the average of -q,
it is ignored, although oggenc says " using constrained VBR ( ... , max br
y ) ".
It might be useful to add a warning about this, because if not, it simply
looks like it doesn't work.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/theora/-/issues/1081Add user-lockable frame memory to theora2017-08-20T01:57:18ZGitlab BotAdd user-lockable frame memory to theora
## SUMMARY
Currently it is not generally possible to display ('play') theora content without
copying decoded frames at least twice - once from libtheora memory to user memory, and once from user memory to display memory.
This proposal...
## SUMMARY
Currently it is not generally possible to display ('play') theora content without
copying decoded frames at least twice - once from libtheora memory to user memory, and once from user memory to display memory.
This proposal suggests the addition of two API calls that add the concept of a "shared" buffer, allocated and freed by the user but lockable by libtheora. With such a buffer, one of these copies can be eliminated.
## THE PROBLEM
libtheora provides decoded frames in memory allocated and owned by libtheora (through the theora_yuv_out function call). libtheora does not guarantee that this memory is valid following subsequent theora_packet_in calls. Hence, the player application must either copy the decoded frame directly to the screen, or copy it to a buffer for later display.
However, it is undesirable to copy the frame directly to the screen, as this will lead either to unpredictable display times or an inefficient use of available time (the player must either display the frame as soon as it is ready or wait until the display time of the frame arrives). Hence, players must in general incur the cost of copying the frame to a temporary buffer owned by the player application.
## THREE PROPOSED SOLUTIONS
(1) One solution would be to add a single API call to libtheora:
```
theora_unlock_yuv_buffer(theora *, buffer *)
```
libtheora would then avoid freeing frames that have not been explicitly unlocked by the user. This approach has disadvantages:
* the behaviour of the library changes (legacy applications will stop working due to memory leaks)
* an additional function call per frame is required for normal operation of the library
(2) These disadvantages can be mitigated by requiring the user to lock buffers
first:
```
theora_lock_yuv_buffer(theora_state *, yuv_buffer *)
theora_unlock_yuv_buffer(theora_state *, yuv_buffer *)
```
libtheora would exhibit the same behaviour in the absence of these functions being
called, but would not free frames that have been locked by the user until subsequently unlocked.
(3) Another approach is to allow user-allocation of buffers:
```
theora_user_yuv_out(theora_state *, yuv_buffer *)
int theora_user_buffer_is_freeable(theora_state *, yuv_buffer *)
```
In this case, the user can provide user-allocated memory into which theora decodes the frame, and theora can indicate that a user-allocated frame should not be freed (for example, if the frame is a reference frame). Normal operation of the library is unchanged.
This approach has the additional advantage that the user can tailor memory use to the application and environment - restricted-memory embedded systems can avoid malloc and free, while directX-based systems can provide memory already allocated as a directX texture.
## RECOMMENDATION
Given that this problem exists, and is fixable with minimal API modification and no perceived change for existing applications, I would suggest that we consider fixing it. I currently favour approach 3, as it is more flexible, however this approach also means more work for the application designer that wishes to use the new feature.
https://gitlab.xiph.org/xiph/icecast-server/-/issues/2465Add support for RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token...2023-03-18T10:25:42ZPhilipp SchafftAdd support for RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token UsageSupport for RFC 6750 should be added. In a first iteration this only needs to be supported by the `url` and the `enforce-auth` backend.
See also: xiph/icecast-libshout#2311Support for RFC 6750 should be added. In a first iteration this only needs to be supported by the `url` and the `enforce-auth` backend.
See also: xiph/icecast-libshout#2311Philipp 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/icecast-server/-/issues/2084Add support for ANSI streaming2021-10-26T09:40:29ZPhilipp SchafftAdd support for ANSI streamingStreaming in Text+ANSI Codes should be added to icecast. This would allow to to send shows of e.g. text adventures or other text games and applications.Streaming in Text+ANSI Codes should be added to icecast. This would allow to to send shows of e.g. text adventures or other text games and applications.Icecast 2.6https://gitlab.xiph.org/xiph/xiph-qt/-/issues/1487Add steps to configure iTunes and QT to play FLAC and OGG files2009-04-19T20:46:52Zgary.johnsonAdd steps to configure iTunes and QT to play FLAC and OGG filesWhen I click on a flac file and open with QT I get the message, not a valid movie file.
When I open with iTunes, I get no action. I have the latest versions of iTunes and quicktime on OS X 10.4 as of DEC 28 08. It might be a nice idea ...When I click on a flac file and open with QT I get the message, not a valid movie file.
When I open with iTunes, I get no action. I have the latest versions of iTunes and quicktime on OS X 10.4 as of DEC 28 08. It might be a nice idea to have a page of instructions and a few test files so that we could declare victory on a successful install. Ditto for FirefoxArek KorbikArek Korbikhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2457add MPTCP support2023-04-06T12:41:42ZBjoern Jackeadd MPTCP supportMPTCP allows clients to switch from one network to another network without the TCP connection to break. So a client can be in a WIFI network and move to a LAN or a mobile data connection and the TCP connection stays alive. This is ideal ...MPTCP allows clients to switch from one network to another network without the TCP connection to break. So a client can be in a WIFI network and move to a LAN or a mobile data connection and the TCP connection stays alive. This is ideal for streaming applications and this would be perfect for Icecast. MPTCP v1 support was added to the Linux kernel in the early 5.x releases. Adding support for it for server applications is simple. MPTCP support is also transparent for non-MPTCP-aware devices.
All that being said, please add support for MPTCP to Icecast and have it enable it by default.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2263Add mime.types paths for other distros2020-10-11T14:45:20ZMarvin ScholzAdd mime.types paths for other distrosWe should add some more mime.types paths, seems the current one we have does not work on FreeBSD
and OS X uses a different one.
See [this](https://groups.google.com/forum/#!topic/golang-codereviews/fIw6mRzai4U) for some more paths that ...We should add some more mime.types paths, seems the current one we have does not work on FreeBSD
and OS X uses a different one.
See [this](https://groups.google.com/forum/#!topic/golang-codereviews/fIw6mRzai4U) for some more paths that seems to be usual.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/libao/-/issues/1735add libffado support2011-02-22T16:30:00ZGitlab Botadd libffado supportin order to play on firewire audio devices on linux, one has to use ffado ( http://www.ffado.org/ )
It would be nice if libao supported that. in order to play on firewire audio devices on linux, one has to use ffado ( http://www.ffado.org/ )
It would be nice if libao supported that. Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/rav1e/-/issues/84Add integration tests2018-02-28T19:58:31ZThomas DaedeAdd integration tests*Created by: yushincho*
That is another lovely built-in feature of Rust. Let's use it asap, and not writing hassle separate unit-tests programs.*Created by: yushincho*
That is another lovely built-in feature of Rust. Let's use it asap, and not writing hassle separate unit-tests programs.https://gitlab.xiph.org/xiph/speex/-/issues/1511add Haiku types in speex_types.h2018-01-21T13:05:26ZGitlab Botadd Haiku types in speex_types.hPatch to add Haiku types for speex.Patch to add Haiku types for speex.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/icecast-website/-/issues/1898add apt-get source instructions to debian notes and debian section to documen...2017-08-26T22:33:52ZThomas B. Rückeradd apt-get source instructions to debian notes and debian section to documentation** It wouldn't hurt to have that guide written to be included both on the website and in documentation. Or link from the website to the online documentation, that's maybe better.
* we should outline how one can rebuild the source packag...** It wouldn't hurt to have that guide written to be included both on the website and in documentation. Or link from the website to the online documentation, that's maybe better.
* we should outline how one can rebuild the source package from SID for debian/ubuntu.
* Also we should mention the official xiph.org packages.
* Also we should mention backports
* basically a "how to install icecast on debian" section
* including a warning about ssl
Debian has long release cycle and Icecast tends to hang in SID.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/rav1e/-/issues/3Add a mode to test encode/decode mismatch2018-02-28T19:58:32ZThomas DaedeAdd a mode to test encode/decode mismatch*Created by: smarter*
Probably by relying on aomdec being on the PATH*Created by: smarter*
Probably by relying on aomdec being on the PATHhttps://gitlab.xiph.org/xiph/opus-tools/-/issues/2297Add a "--bitrate-per-channel" or a "--quality" argument2018-05-13T08:51:36ZkuchikirukiaAdd a "--bitrate-per-channel" or a "--quality" argumentAs of now Opus doesn't have a setting equivalent to Vorbis, Nero AAC, or QAAC's VBR quality levels. This makes it difficult to batch encode multiple files with multiple channel configurations. With a quality level you can pick one sett...As of now Opus doesn't have a setting equivalent to Vorbis, Nero AAC, or QAAC's VBR quality levels. This makes it difficult to batch encode multiple files with multiple channel configurations. With a quality level you can pick one setting and the encoder will adjust the bitrate according to the channel layout: for example, QAAC @ q127 will target 320kbps for 2.0 channel and 768kbps for 5.1. This is a very handy feature.
If a --quality feature, may I suggest a naming scheme that has some relation to the bitrates output at 2.0? I mean, I'd have no idea what Vorbis' q=5.0 translates to without looking at a chart. QAAC, OTOH, seems to somewhat correspond to bitrate-per-channel in its q45-q91 range. This is pretty useful. I know to pick q91 if I want ~180k quality without needing to run off to a manual.
Mark HarrisMark Harrishttps://gitlab.xiph.org/xiph/vorbis/-/issues/2343Accessing elements outside of array boundaries2021-06-06T17:28:26ZdokutokuAccessing elements outside of array boundarieshttps://gitlab.xiph.org/xiph/vorbis/-/blob/4ba8efed8797016a85e57bc3cc7975bb31d65db5/lib/psy.c#L340
I think it is better to modify this line of code as the following code.
Otherwise, there is a danger of accessing outside the range of th...https://gitlab.xiph.org/xiph/vorbis/-/blob/4ba8efed8797016a85e57bc3cc7975bb31d65db5/lib/psy.c#L340
I think it is better to modify this line of code as the following code.
Otherwise, there is a danger of accessing outside the range of the array in line 347.
```c
if(halfoc>=P_BANDS-2)halfoc=P_BANDS-2;
```