Thank you Phillip, my first time here. 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. 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). Have a nice day, with best regards, -- 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
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>
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). >-- 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