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

Incredibly helpful Phillip, thank you.

Could I ask more about this point here. Are you suggesting that the CGI script
is run by an http server (being accessed by the Icecast relay mount, when first
listener connects) or by Icecast directly?

That would simplify the Icecast side of things, but how would that be stopped
when the last Icecast listener disconnects? Icecast would then ?disconnect? from
that source, but how would that then stop the CGI/transcoding? Although having
done a fair bit of web design in the past, it is now quite a long time in the
past, so rusty and out-of-date and would appreciate some advice here?

Alternatively, is there any way to tap into Icecast's use of the internal
source client for relays, to use as a trigger in the way I?m trying to use the
on-(dis)connect functions to start and stop the transcode process, but which
does not seem to work for a relay?


Ken  G i l l e t t

_/_/_/_/_/_/_/_/


> On 22 May 2021, at 11:32, Philipp Schafft <phschafft at
de.loewenfelsen.net> wrote:
> 
> 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. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20210522/1c9ddde5/attachment.htm>

I have just discovered a feature of ffmpeg of which I was previously unaware.
Instead of sending the stream somewhere (usually to a file or as an Icecast
source as I?ve been trying to utilise), it can simply act as an http server and
await connections. So it can act as a source for Icecast to relay. This is good
news.

Not so good is that it grabs its source as soon as it starts, even when nothing
is sucking up that stream. This is no good for me as it locks onto the tuner
until the process is actually terminated. This is THE big issue for me as the
tuners have to be free for other use when not streaming/transcoding to Icecast.
Hence why I?m trying to get Icecast to ?tell? me when to start the transcoder -
but failing so far.

However using ffmpeg I would not need any internal relay in Icecast (although it
works perfectly well), but I am still left with needing to trigger the
transcoder to start and stop on-demand.

So I was wondering how I could start and stop this ffmpeg http server/transcode
process when the Icecast relay connects to and disconnects from that address.
Since I cannot seem to utilise Icecast?s on-(dis)connect triggers to do this, I
was hoping to trigger it all from ?the other end? as it were.

Right now, I cannot think of how to set this up, but as I said, my html
development skills are old and very rusty. However, I am sure it can be done.
Any pointers?


Ken  G i l l e t t

_/_/_/_/_/_/_/_/


> On 22 May 2021, at 12:40, Ken Gillett <kengroups at icloud.com>
wrote:
> 
> Incredibly helpful Phillip, thank you.
> 
> Could I ask more about this point here. Are you suggesting that the CGI
script is run by an http server (being accessed by the Icecast relay mount, when
first listener connects) or by Icecast directly?
> 
> That would simplify the Icecast side of things, but how would that be
stopped when the last Icecast listener disconnects? Icecast would then
?disconnect? from that source, but how would that then stop the CGI/transcoding?
Although having done a fair bit of web design in the past, it is now quite a
long time in the past, so rusty and out-of-date and would appreciate some advice
here?
> 
> Alternatively, is there any way to tap into Icecast's use of the
internal source client for relays, to use as a trigger in the way I?m trying to
use the on-(dis)connect functions to start and stop the transcode process, but
which does not seem to work for a relay?
> 
> 
> Ken  G i l l e t t
> 
> _/_/_/_/_/_/_/_/
> 
> 
> 
>> On 22 May 2021, at 11:32, Philipp Schafft <phschafft at
de.loewenfelsen.net <mailto:phschafft at de.loewenfelsen.net>> wrote:
>> 
>> 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. :)
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20210523/e913dcba/attachment.htm>

V?Sat, May 22, 2021 at 12:40:55PM +0100,?Ken Gillett
napsal(a):
> Could I ask more about this point here. Are you suggesting that the CGI
> script is run by an http server (being accessed by the Icecast relay mount,
> when first listener connects) or by Icecast directly?
>
By an HTTP server.
> That would simplify the Icecast side of things, but how would that be
> stopped when the last Icecast listener disconnects? Icecast would then
> ?disconnect? from that source, but how would that then stop the
> CGI/transcoding?
When Icecast disconnects, the CGI script process, which was writing to the TCP
socket
on its standard output, gets a SIGPIPE signal from the kernel. If the script
did not install its own handler for the signal, a default one will be invoked
by kernel which terminates the process. Effectivelly the script process frees
all
resources, e.g. an opened tunner device.

More advanced HTTP server may keep proxying data between an HTTP client
(Icecast) and the CGI script. In that case the server notices a TCP disconnect
and should (?) kill the CGI script.

-- Petr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://lists.xiph.org/pipermail/icecast/attachments/20210523/c3a47895/attachment.sig>