[Icecast] only a few listeners - reduce resource usage?

[D.T.]

Hello, thank you for your timely reply!

It took me a while to get into it.

Additional challenges came up: I realised that most of my music
collection is MP3, and I can save some quality/processing when I stream
MP3 instead of OGG/Vorbis.
I think I have that part under control now, but I mention it for
context. It also means that I cannot use ogg-based source clients -
even Debian's libshout3 does not support MP3 - I use ffmpeg for
everything currently. This works OK so far:

1. Looping through music collection, ffmpeg transcodes and pipes or
just pipes music to stdout

 |
 V

2. The result is caught (-i pipe:) by a continuous ffmpeg process that
is an icecast client

 |
 V

3. Icecast2 => World

________________

Now, about the on-demand relaying.

First, I want to make sure about the terminology:

- The master is the one connected to the icecast clients that actually
produce the music
- The slave is public-facing and relays web requests for mountpoints to
the master

So what is currently point 3. would become the master, which then
relays to

4. Icecas2 (slave) => world

Correct?

Since I want on-demand streaming for all my streams I decided on the
global <master-server> configuration.

But this means I need to start 2 separate icecast daemons with
different configurations, yes?
The provided init script (Debian package) clearly does not have such a
scenario in mind, and things could quickly get messy.

Or am I missing something obvious here?

Cheers,

D.T.


On Thu, 2022-04-07 at 07:18 +0000, Philipp Schafft wrote:
> Good morning,
> 
> On Wed, 2022-04-06 at 06:37 +0000, D.T. wrote:
> > Hello,
> > I have made myself a radio station that just shuffles my music
> > collection, transcodes it to ogg/vorbis and streams that over
> > icecast.
> > It's a simple shell script utilixing ffmpeg and oggfwd, on a
> > headless
> > Debian server.
> > Due to copyright issues I cannot make it public (I guess), so I'll
> > often have no listeners at all, and usually just myself.
> > But the script is still chugging along, transcoding music to
> > nowhere.
> > 
> > Now I understand that the buffer has to be full when a listener
> > connects. And I also understand that the unique character of a
> > radio
> > station would be lost if the playlist actually stops when nobody is
> > listening.
> > 
> > Even so, is it possible to avoid this waste of resources while
> > still
> > having my very own radio station?
> 
> Actually, yes and a bit of no:
> 
> You can do that with on-demand relays. They are exactly what you ask
> for:
> With on-demand relays the source is connected when at least one
> listener is connected and is disconnected in times of idle.
> 
> So from an Icecast point of view this is totally possible.
> 
> However I have not yet seen any out-of-the-box sourceclient for that.
> But if you are already on the scripting level of things that could be
> an option for you.
> 
> Overview on how it works:
> Basically when data is required Icecast will do a HTTP GET request to
> a
> URL you provided. It expects a source of data there. Keep in mind
> that
> this source needs to provide data at the correct speed.
> 
> And that's all there is to it already. :)
> 
> 
> > Cheers,
> > 
> > D.T.
> > 
> > PS: thanks for yet another glorious FOSS application!!!
> 
> Thank you for your kind words. :)
> 
> 
> With best regards,
> 
> 
> PS: Feel free to use "shout" from libshout as a little bit more
> modern
> replacement to "oggfwd". :)
> 
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

___

Vaccines for everyone!
Donate to the COVAX alliance:
https://gogiveone.org/ (WHO)
https://www.gavi.org/donate (Gavi)

___

Vaccines for everyone!
Donate to the COVAX alliance:
https://gogiveone.org/ (WHO)
https://www.gavi.org/donate (Gavi)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20220605/e67192cd/attachment.sig>