[Icecast-dev] Server Side Spot Replacement?

[Philipp Schafft]

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/20170411/73aba07f/attachment.sig>