[Icecast-dev] Server Side Spot Replacement?

Wed Apr 19 11:51:50 UTC 2017

Good morning,

On Tue, 2017-04-18 at 12:17 +0000, Rune Hafskjær wrote:
> Hi Philipp,
> 
> Thank you for insights and suggestions. Please see my recent answer
> and questions to Lin in the same matter.

(I did, but answering here, keeping in mind your other answer.)

> I'm talking about thousands of listeners, and individual mounts are
> probably not the way to go.

A client can also be attached to an internal source, normally reading a
file from the disk. That is what happens when you request a random file
from Icecast (e.g. an image for the status page).

The same can be used (but requires a patch) to move listeners on and
back to the other source after the file ended. We have done something
very similar for another client already.

> A dream scenario would be to trigger a move of all listeners at the
> start of an ad break to a mount with a dynamic scripted playlist of
> ads playing from a separate CDN. And move everybody back to the
> original mount when the playlist is finished. If that can be done...

It can. My main concern is the load that this could cause on the server.
e.g. reading a file for each listener will generate a lot I/O-load on
that machine. But most of those effects are inherent to the situation
(e.g. a webserver will have the same problem with the same number of
simultaneous clients). Some may be within Icecast.

I think it's possible with only a bit of work to see how it performs.
Before writing a real patch.

> 
> Any thoughts and detailed help to move further are much appreciated.

I would be pleased if you could answer my question on which
formats/codecs should be supported.

I also think such a test could be a potential first step. To see if the
direction is one that is possible or if some dedicated solution as Mr.
Marcin suggested would be a better option.

Also feel free to contact me off-list if you're interested in commercial
support (including writing such a patch).

Have a nice day,

with best regards,

> 
> -----Original Message-----
> From: Icecast-dev [mailto:icecast-dev-bounces at xiph.org] On Behalf Of
> Philipp Schafft
> Sent: 11. april 2017 17:54
> To: Rune Hafskjær
> Cc: icecast-dev at xiph.org
> Subject: Re: [Icecast-dev] Server Side Spot Replacement?
> 
> Good afternoon,
> 
> 
> On Tue, 2017-04-11 at 13:03 +0000, Rune Hafskjær wrote:
> > Thank you Phillip,
>                ^^-^
> 
> 
> > my first time here.
> 
> No problem.
> 
> 
> > What I want to achieve is to replace ads in a live ad break on
> live 
> > streamed radio with personal spots for each listener. I want to 
> > recognize the start of the break, split listeners into separate 
> > streamed spots and then back again to the live stream when the
> spots 
> > has been played.
> > 
> > The main goal is to offer programmatic data driven ads on streamed 
> > radio and bring radio into the modern advertising world.
> > 
> > There are a number of companies that offers this in various cloud 
> > solutions in connection with Icecast servers, but there are pros
> and 
> > cons with the offerings and I want to understand how it's done and 
> > consider build it myself.
> 
> Ok. I think that can be done but needs modification of Icecast (to
> detect the break). It also depends on the used codec.
> Most codecs work like that:
> segment header(metadata), segment data, segment header(metadata),
> segment data, ...
> 
> ('segment' here as a general term. codecs/containers may use
> different
> names.)
> 
> The easiest way to detect the break would be to have a look at e.g.
> the metadata. It could contain a ID that can be used to identify the
> segment with the ad.
> 
> Which codecs do you plan to use? I do not see much trouble with Ogg
> based streams (Vorbis or Opus). With ICY based streaming (MP3 and AAC)
> there is the problem that metadata updates happen out of band and can
> not be synchronized to the audio perfectly. That is one of many
> restrictions MP3 and AAC has by design. It's independent on the
> implementation.
> 
> 
> Are your listeners group regarding the ads? What is the ratio of
> listener clients to alternative replacements? e.g: every listener get
> it's own specific content vs. there are 5 groups of ads, a listener is
> in one of those groups.
> 
> This is important in terms of scaling. Icecast's engine is made for
> 1->n streaming (broadcast, all get the same). It's not designed for
> n->n (every listener has it's own content). The more you go in
> direction of the later case the less performant Icecast will be. e.g.
> 5 groups is perfectly fine. 100 groups may still work nicely. 500
> groups is a bad idea, 50000 groups will likely kill performance.
> 
> So this is important to evaluate the options for an actual
> implementation.
> 
> I hope this was helpful to you,
> 
> with best regards,
> 
> > 
> > Best regards,
> > Rune
> > 
> > -----Original Message-----
> > From: Icecast-dev [mailto:icecast-dev-bounces at xiph.org] On Behalf
> Of 
> > Philipp Schafft
> > Sent: 11. april 2017 14:48
> > To: Rune Hafskjær
> > Cc: icecast-dev at xiph.org
> > Subject: Re: [Icecast-dev] Server Side Spot Replacement?
> > 
> > Good afternoon,
> > 
> > On Tue, 2017-04-11 at 11:06 +0000, Rune Hafskjær wrote:
> > > Hi guys,
> > 
> > > Can anyone share some (deep technical) light on how «Server Side
> > Spot
> > > Replacement” on live radio streaming with Icecast can be done?
> > 
> > I think it would be helpful if you could give some more context.
> Maybe 
> > by explaining your goal in a non-technical way (that often helps).
> > 

-- 
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: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast-dev/attachments/20170419/67056468/attachment.sig>