Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2017-10-05T10:40:40Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2259[PATCH] Master-Slave Aggregating Relay (multiple master setup)2017-10-05T10:40:40ZMarvin Scholz[PATCH] Master-Slave Aggregating Relay (multiple master setup)We got a pull-request on Github by [greenbender](https://github.com/greenbender):
> This pull request adds support for multiple Master-Slave relays. Something I am calling a Master-Slave Aggregating Relay.
>
> A couple of people have a...We got a pull-request on Github by [greenbender](https://github.com/greenbender):
> This pull request adds support for multiple Master-Slave relays. Something I am calling a Master-Slave Aggregating Relay.
>
> A couple of people have asked for this feature in the past and were referred to the Single-Broadcast Relay, which is OK provided you know the specific mountpoints that you want to relay ahead of time.
>
> If you are in a position where you want to relay mountpoints for more than one the master server, and one or more of the master servers adds and removes mountpoints dynamically or if you are unable to know what mountpoints are available ahead of time then this gives you the ability to aggregate all mountpoints for any numbers of master servers.
>
> Namespacing is also supported to prevent name clashes for mountpoints being relayed from different servers.
The patch can be found here:
```
https://github.com/xiph/Icecast-Server/pull/5.patch
```
For more information, see the [original Github Pull-Request](https://github.com/xiph/Icecast-Server/pull/5)!Icecast 2.5.2Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2237[PATCH] Detect Keyframes in WebM streams2018-03-06T12:49:37ZJoseph Wallace[PATCH] Detect Keyframes in WebM streamsThe existing WebM plugin will mark the start of any cluster as a sync point. This causes problems for web browsers, which tend to strictly demand that video streams are started on a keyframe.
The WebM specs call for a keyframe being the...The existing WebM plugin will mark the start of any cluster as a sync point. This causes problems for web browsers, which tend to strictly demand that video streams are started on a keyframe.
The WebM specs call for a keyframe being the first video frame in a cluster if the cluster contains a keyframe, but they do not require clusters to contain any keyframes at all.
This patchset:
1. implements some EBML parsing functions, to identify clusters accurately instead of assuming any occurrence of the cluster magic number is a cluster header.
2. detects if a WebM stream contains a track of type video.
3. examines the SimpleBlocks of each cluster to determine if the first video track block is marked as a keyframe.
If the first video block is a keyframe, the cluster is marked as a sync point. If the first video block is NOT a keyframe, the cluster is not marked as a sync point.
If a determination cannot be made in the first 4K of the cluster, it's optimistically marked as a sync point, since it's most likely an audio-only stream.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2156Check feasibility of intro functionality for WebM2018-03-06T12:49:38ZThomas B. RückerCheck feasibility of intro functionality for WebMSee #2155 also #1941
We would need to see if an otherwise parameter compatible stream can be spliced seamlessly so that it doesn't cause players to complain/break.
If not feasible we should disable intro if content-type is WebM.See #2155 also #1941
We would need to see if an otherwise parameter compatible stream can be spliced seamlessly so that it doesn't cause players to complain/break.
If not feasible we should disable intro if content-type is WebM.Icecast 2.5.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/icecast-server/-/issues/2138VCLT support in current icecast is useless2018-03-06T12:49:38ZPhilipp SchafftVCLT support in current icecast is uselessIn current state VCLT support is in codebase but not exposed anywhere beside the admin interface. As of current state it is of no use as it is not exposed to the listeners in any way.
I request to
1. enable support by making it as visib...In current state VCLT support is in codebase but not exposed anywhere beside the admin interface. As of current state it is of no use as it is not exposed to the listeners in any way.
I request to
1. enable support by making it as visible as the other formats OR
1. disable it by removing the code to avoid any maintenance need in future releases.
dm8tbr acknowledged to take a decision on this before final release of 2.5.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2127Icecast needs a web-UI for configuration2018-03-06T12:49:38ZThomas B. RückerIcecast needs a web-UI for configurationThere are various existing projects, open and proprietary, but none really make full use of the potential, while being usable.
The Icecast project should have its own reference configuration UI. Either from scratch or by adopting an exis...There are various existing projects, open and proprietary, but none really make full use of the potential, while being usable.
The Icecast project should have its own reference configuration UI. Either from scratch or by adopting an existing open source project.
There are two possible approaches:
* Internal (somehow as part of /admin)
* External (running on a proper web server)
The former would make it self-contained, while the latter would enable us to leverage an existing framework.
Both approaches need to be explored before a decision is made.
PS: Being fairly self-contained this would be potentially a very good GSoC or similar project. I am also sufficiently familiar with the config file and live config mechanics to mentor such a task.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2103Clarify default setting of logarchive2018-03-06T12:49:38ZMicheil SmithClarify default setting of logarchiveCurrently no default setting is in place for logarchive in the configuration, it's just by chance that the default is that it's off, due to how the internals of log.c work.Currently no default setting is in place for logarchive in the configuration, it's just by chance that the default is that it's off, due to how the internals of log.c work.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2101Verify if on-connect (events) are still impossible on windows2018-03-06T12:49:38ZThomas B. RückerVerify if on-connect (events) are still impossible on windowsWe migrated to mingw32, I suspect it might now be either trivial or easy to fork a script (.bat). We migrated to mingw32, I suspect it might now be either trivial or easy to fork a script (.bat). Icecast 2.6Stephan JauernickStephan Jauernickhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2055Changing relay on-demand settings messes things up2018-03-06T12:49:38ZMarvin ScholzChanging relay on-demand settings messes things upIf a relay is configure in Icecast like the following:
```
<relay>
<server>stream.server.de</server>
<port>8000</port>
<mount>/24.mp3</mount>
<local-mount>/diff.mp3</local-mount>
<relay-shoutcast...If a relay is configure in Icecast like the following:
```
<relay>
<server>stream.server.de</server>
<port>8000</port>
<mount>/24.mp3</mount>
<local-mount>/diff.mp3</local-mount>
<relay-shoutcast-metadata>0</relay-shoutcast-metadata>
<on-demand>1</on-demand>
</relay>
```
and the `on-demand` value is changed to 0 and config re-read with SIGHUP, it will still show as on-demand in the stats and the whole relay mount will disappear and reappear quite randomly.
When initially 0 and changed to 1 it seems to have no effect at all.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2100Document icecast access log format in docs2018-03-06T12:49:38ZThomas B. RückerDocument icecast access log format in docswe should explain it, especially the last field that adds on top of Apache "combined" type output and signifies connection duration in seconds.
Also mentioning that we do NOT log the amount of data sent by a source client due to adherin...we should explain it, especially the last field that adds on top of Apache "combined" type output and signifies connection duration in seconds.
Also mentioning that we do NOT log the amount of data sent by a source client due to adhering to convention "bytes _sent_".Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2094YP protocol documentation / revision2018-03-06T12:49:38ZThomas B. RückerYP protocol documentation / revisionWe should document the currently used YP protocol, old docs might be available but are outdated.
As we'll have to introduce a few changes we should rethink some protocol aspects while we document it.
Collaborative wiki page is at https...We should document the currently used YP protocol, old docs might be available but are outdated.
As we'll have to introduce a few changes we should rethink some protocol aspects while we document it.
Collaborative wiki page is at https://wiki.xiph.org/Icecast/YP-protocol-v2Icecast 2.5.0Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2091Fix up ogg serial numbers for incoming streams in Icecast2018-03-06T12:49:38ZThomas B. RückerFix up ogg serial numbers for incoming streams in IcecastWe should do this server side, there are too many broken things out there.
Ices has some code for this if we need a reference.We should do this server side, there are too many broken things out there.
Ices has some code for this if we need a reference.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2074symlink icecast docs into web dir during install2018-03-06T12:49:39ZThomas B. Rückersymlink icecast docs into web dir during installThis would make the docs much more discoverable for the average user.
We could then simply link to them from the status page and the admin pages.
Docs are already HTML as we also expose them through http://icecast.org/docs/ for each ver...This would make the docs much more discoverable for the average user.
We could then simply link to them from the status page and the admin pages.
Docs are already HTML as we also expose them through http://icecast.org/docs/ for each version
On Windows it would be a full copy instead.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1938timelimit_header is not considered for stream_auth2018-03-06T12:49:39Zcatotimelimit_header is not considered for stream_authProblem:
A url is configured for stream_auth to limit the authentication for sources. The configured URL returns a "icecast-auth-timelimit: 600"-header, but the source does not get disconnected after 10 minutes.Problem:
A url is configured for stream_auth to limit the authentication for sources. The configured URL returns a "icecast-auth-timelimit: 600"-header, but the source does not get disconnected after 10 minutes.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1880Join video streams on keyframes2018-03-06T12:49:39ZGregory MaxwellJoin video streams on keyframesFor keyframe based video (as opposed to rolling intra refresh) clients can't display output (correctly at least) until they hit a keyframe.
So it would be useful if streams started on keyframes. There are a couple options for this.
If ...For keyframe based video (as opposed to rolling intra refresh) clients can't display output (correctly at least) until they hit a keyframe.
So it would be useful if streams started on keyframes. There are a couple options for this.
If latency is unimportant and the server doesn't mind the memory usage it could buffer the span between keyframes and when a client attaches attach them back at the last keyframe. This would be like a keyframe adaptive preburst.
Alternatively, if latency matters more the server could reencode.
The best way to do this would be to constantly reencode with a very short keyframe interval (e.g. 1-12 frames) and play this out to new clients until a real keyframe comes. Optionally a 'loading' spinner could be displayed to avoid confusion from the low quality during this span. This is O(N) in the number of streams and O(1) in the number of users.
For some formats it would be possible to do some format specific smartness. E.g. in theora You could retransmit the prior keyframe timestamped as NOW-2, then reencode the prior frame (using all intra blocks at high quality) as NOW-1. Then splice in the stream. There will be some corruption until the next keyframe but it should be very minor. Unfortunately it would cause a jump in the visible output because the first frame is an old one.
Alternatively, alternatively, a pre-encoded short GOP "loading" video stream could be sent to users before the first new keyframe. Audio could be spliced in instantly however. This would avoid encoding in the icecast server.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1853Update graphics for Icecast documentation2018-03-06T12:49:39ZThomas B. RückerUpdate graphics for Icecast documentationRedoing some screenshots and graphics in a lossless format like PNG is desireable. Currently some are JPEG.
Please check back with dm8tbr as to when the web layout is final.
Target 2.3.3 if possible.Redoing some screenshots and graphics in a lossless format like PNG is desireable. Currently some are JPEG.
Please check back with dm8tbr as to when the web layout is final.
Target 2.3.3 if possible.Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1892Allow transient reconfiguration of all mount point parameters2018-03-06T12:49:39ZThomas B. RückerAllow transient reconfiguration of all mount point parametersgive the source user more freedom in controlling mount point options through admin requests.
How do we split control of <mount> options?
We could have XML tag attributes to control outside access: <stream-name allow-override="no">fooba...give the source user more freedom in controlling mount point options through admin requests.
How do we split control of <mount> options?
We could have XML tag attributes to control outside access: <stream-name allow-override="no">foobar</stream-name>
where override could be:
* yes - allow setting this value externally
* no - only the xml config file value may set this
* 'unset' - a default value is used if the attribute is not set. The default should be documented though!
Also, we should check the life-cycle for this. Do the settings get reset to the XML defined settings and defaults upon disconnection of the source client or do they persist until either the config is reloaded or the server restarted? I'd tend towards the latter and give an option to 'reset' from source side both during connect and at arbitrary points in time.Icecast 2.6Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/778[PATCH] video preview patch2018-03-06T12:49:39ZGitlab Bot[PATCH] video preview patchHere it is a patch allowing to see a preview of a theora stream in status.xsl page.Here it is a patch allowing to see a preview of a theora stream in status.xsl page.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2330Segmentation Fault in auth.c2018-04-18T00:14:17ZMarvin ScholzSegmentation Fault in auth.cReported by hopejr on Github:
There is a seg fault on unlocking the thread on line 189 of auth.c in the function auth_release() under certain circumstances:
1. Configure a mount point with a fallback that is a relay from another server...Reported by hopejr on Github:
There is a seg fault on unlocking the thread on line 189 of auth.c in the function auth_release() under certain circumstances:
1. Configure a mount point with a fallback that is a relay from another server that is actually running (the stream must have parameter hidden=0 and fallback-override=1)
2. Start Icecast
3. Stream to Icecast, and then stop the stream after an arbitrary amount of time
4. Load the status page in the browser
At that point, there will be a seg fault as described above. It does not happen when the mount point is hidden for some reason.
Test system is running Debian 9.3. Icecast version 2.4.99.2https://gitlab.xiph.org/xiph/icecast-server/-/issues/2092Write specification of Icecast specific HTTP protocol features2018-06-07T20:52:20ZThomas B. RückerWrite specification of Icecast specific HTTP protocol featuresUse HTTP 1.0 and 1.1 specs as base, document differences and quirks.
Give guidance what a source client SHOULD, MUST, MUST NOT do, etc.
Explain source and listener HTTP headers, authentication quirks.Use HTTP 1.0 and 1.1 specs as base, document differences and quirks.
Give guidance what a source client SHOULD, MUST, MUST NOT do, etc.
Explain source and listener HTTP headers, authentication quirks.Icecast 2.5.0Philipp SchafftPhilipp Schafft