[Icecast] The myth of the two different kinds of mounts [WAS: Re: falling back]

[Philipp Schafft]

Good morning,

first of all, thank you Petr Pisar for you mail. It gives a good
overview but I feel the need to go into details a bit more.

On Fri, 2021-05-21 at 21:50 +0200, Petr Pisar wrote:
> Icecast has two types of mount points: source-mounts which content is
> pushed into Icecast and relay-mounts which content is pulled by
> Icacast.

This is actually a old myth. And I honestly don't know where it
originated from.

Icecast only knows one kind of mount points. Each mount can be in
mounted state (a source connected) or unmounted state (no source
connected).

Once a client is connects Icecast first checks if the mount is part of
the Admin API. If so it will handle the request via the Admin API, if
not it will continue:
Next it is checked if the mount point is mounted[0]. If it is, the
client is connected to that source.
If it is unmounted Icecast will try to auto connect a source. There are
currently the following source types Icecast can auto connect:

 * Relays
 * Admin API (This is everything under /admin; And only used for Admin
   API)
 * fserve (this is "plain files" and "XSLT rendered stats")

So what does that mean:
If you configure a relay Icecast will start a new source client. But
that is build into Icecast. That source client then forwards the data
it reads from another source[1].

If nothing specific has been configured, Icecast will next try using
static files with fserve. So Icecast will start a fserve source that
will then send the file if there is one.

If nothing could mount the mount point Icecast will send a error
("404") indicating that there is no source for the mount.

This also means:
You can apply all mount settings to all mount points. However those not
applicable will be ignored by Icecast. (Also the Admin API ignores most
settings as special rules apply for it. Mostly noticeable with auth/ACL
settings.)


> A transmission of the content which is pulled can only be initiated
> by Icecast. On the other hand, the pushed content cannot be initiated
> by Icecast. The pushed content is always initated by an external
> stream source (transcode in your case).

Exactly:
 * External sources for externally generated events (e.g.: "Someone
   pressed the \"on air\" button")
 * Internal source for internally generated events (e.g.: "Some client
   connected").


> Basically, Icecast is a streaming proxy of which task is to multipy
> an external source to multiple clients at the same time. The external
> source is either pushed or pulled content.


> Streaming local files is only a trivial tool for providing a fallback
> when the external source is unavailable.

Actually streaming of local files is only there to provide the web
interface. That you can use it for media is just because there is no
difference for Icecast. To Icecast it's all sending data from a source
to a sink.

However to provide what you describe there is one tiny bit of extra
code (it's really just a few lines!) that will loop local files when
used as fallback. But this is just meant for a really last resort.



Also based on what we learned above:
If you want a source to be started only when there are listeners: Use a
relay. The relay source will notify an external component of the demand
(by requesting content). That is the way to go.

To make this work with an external data source just write a tiny CGI
script or similar that sends the necessary headers and start a
encoder/transcoder that sends data to stdout (which is what is send
back to the client for CGI).

That can for example be done with just a few lines of shell. Something
like:
   #!/bin/sh
   printf "some: headers\r\n\r\n";
   exec myencoder blabla -o -


Hope this mail was helpful everyone and people learned a bit more about
Icecast. :)


[0] Two little exceptions: a) everything under /admin is protected
against being mounted by non-API; b) connections that try to mount a
mount point are handled a bit differently.
[1] Actually it splices the connection. Which gives way better
performance.

-- 
Philipp Schafft (CEO/Geschäftsführer) 
Telephon: +49.3535 490 17 92

Löwenfelsen UG (haftungsbeschränkt)     Registration number:
Bickinger Straße 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 523 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20210522/a5574203/attachment.sig>