[Icecast-dev] Server Side Spot Replacement?

Rune Hafskjær
2017-04-18T12:17:18Z

Hi Philipp,

Thank you for insights and suggestions. Please see my recent answer and
questions to Lin in the same matter. I'm talking about thousands of
listeners, and individual mounts are probably not the way to go. 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...

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

BR
Rune


-----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).
>