Hi there, I work at an internet radio station. My management thought it might be a good idea to enhance our radio with targeted ads. Do you know of any streaming server that is capable of inserting targeted ads into the stream? So far I have only found Ando Media's Targeted Ad Injector (http://andomedia.com/) which claims to be open source but I can't find the source anywhere. Regards, -- Micha? Jaszczyk
Micha? Jaszczyk wrote:> Hi there, > > I work at an internet radio station. My management thought it might be > a good idea to enhance our radio with targeted ads. Do you know of any > streaming server that is capable of inserting targeted ads into the > stream? So far I have only found Ando Media's Targeted Ad Injector > (http://andomedia.com/) which claims to be open source but I can't > find the source anywhere.I have some work implemented for this as an extension to my 10pre code. The interfaces are not documented yet as I wanted to try different use cases. If you are interested then you are welcome to try it out and send feedback http://www.icecast.pwp.blueyonder.co.uk/icecast-2.3.2-kh-ads.tar.gz with this, each listener is allocated a group id (default 0) which the server will use to lookup a file to play. The number of groups is determined by the <mount> setting <jingle-groups>. At the moment the group is only set in auth url by the Jingle-group; header, although I do have a hardcoded switch to allocate the next id to the next new listener for testing. You essentially set the group to file mapping via admin eg /admin/jingle?mount=/stream&id=0&file=/insert1 /admin/jingle?mount=/stream&id=1&file=/insert2 files are in webroot. You then just trigger when the inserts are to be run. This is where things differ slightly. With vorbis streams, the trigger is a simple vorbis file from the source client that lasts however long you want (can be silence as the content won't be sent to listeners) but has a Jingle: in the headers. With non-ogg streams things get more awkward as you don't have the same sort of information in stream and metadata inserts are not good enough. The mechanism currently uses the /admin/jingle interface again but you have an option of /admin/jingle?mount=/stream&play=10000 informs the server that this stream will be in jingle mode for 10 seconds. Any jingle files lasting longer than that will complete then return listeners to the stream. /admin/jingle?mount=/stream&play=on /admin/jingle?mount=/stream&play=off same sort of thing but a toggle I suspect the latter will be better so that people can interface with their source clients better. eg get next file if file is insert marker then .....&play=on if insert marker finished then .....&play=off karl.
> I have some work implemented for this as an extension to my 10pre code. The > interfaces are not documented yet as I wanted to try different use cases. > ?If you are interested then you are welcome to try it out and send feedback > > http://www.icecast.pwp.blueyonder.co.uk/icecast-2.3.2-kh-ads.tar.gz > > with this, each listener is allocated a group id (default 0) which the > server will use to lookup a file to play. The number of groups is determined > by the <mount> setting <jingle-groups>. ?At the moment the group is only set > in auth url by the Jingle-group; header, although I do have a hardcoded > switch to allocate the next id to the next new listener for testing. > > You essentially set the group to file mapping via admin eg > > /admin/jingle?mount=/stream&id=0&file=/insert1 > /admin/jingle?mount=/stream&id=1&file=/insert2 > > files are in webroot. ?You then just trigger when the inserts are to be run. > This is where things differ slightly. > > With vorbis streams, the trigger is a simple vorbis file from the source > client that lasts however long you want (can be silence as the content won't > be sent to listeners) but has a Jingle: in the headers. > > With non-ogg streams things get more awkward as you don't have the same sort > of information in stream and metadata inserts are not good enough. The > mechanism currently uses the /admin/jingle interface again but you have an > option of > > /admin/jingle?mount=/stream&play=10000 > > informs the server that this stream will be in jingle mode for 10 seconds. > Any jingle files lasting longer than that will complete then return > listeners to the stream. > > /admin/jingle?mount=/stream&play=on > /admin/jingle?mount=/stream&play=off > > same sort of thing but a toggle > > I suspect the latter will be better so that people can interface with their > source clients better. eg > > get next file > ? if file is insert marker then > ? ? .....&play=on > ? if insert marker finished then > ? ? .....&play=off > > > karl.Uhm, I guess I'm not following you... Could you explain once again giving more details? :) Cheers, -- Micha? Jaszczyk
Karl Heyes wrote:> Micha? Jaszczyk wrote: > >> Hi there, >> >> I work at an internet radio station. My management thought it might be >> a good idea to enhance our radio with targeted ads. Do you know of any >> streaming server that is capable of inserting targeted ads into the >> stream? So far I have only found Ando Media's Targeted Ad Injector >> (http://andomedia.com/) which claims to be open source but I can't >> find the source anywhere. >> > > I have some work implemented for this as an extension to my 10pre code. > The interfaces are not documented yet as I wanted to try different use > cases. If you are interested then you are welcome to try it out and > send feedback > > http://www.icecast.pwp.blueyonder.co.uk/icecast-2.3.2-kh-ads.tar.gz > > with this, each listener is allocated a group id (default 0) which the > server will use to lookup a file to play. The number of groups is > determined by the <mount> setting <jingle-groups>. At the moment the > group is only set in auth url by the Jingle-group; header, although I do > have a hardcoded switch to allocate the next id to the next new listener > for testing. > > You essentially set the group to file mapping via admin eg > > /admin/jingle?mount=/stream&id=0&file=/insert1 > /admin/jingle?mount=/stream&id=1&file=/insert2 > > files are in webroot. You then just trigger when the inserts are to be > run. This is where things differ slightly. > > With vorbis streams, the trigger is a simple vorbis file from the source > client that lasts however long you want (can be silence as the content > won't be sent to listeners) but has a Jingle: in the headers. > > With non-ogg streams things get more awkward as you don't have the same > sort of information in stream and metadata inserts are not good enough. > The mechanism currently uses the /admin/jingle interface again but you > have an option of > > /admin/jingle?mount=/stream&play=10000 > > informs the server that this stream will be in jingle mode for 10 > seconds. Any jingle files lasting longer than that will complete then > return listeners to the stream. > > /admin/jingle?mount=/stream&play=on > /admin/jingle?mount=/stream&play=off > > same sort of thing but a toggle > > I suspect the latter will be better so that people can interface with > their source clients better. eg > > get next file > if file is insert marker then > .....&play=on > if insert marker finished then > .....&play=off > > > karl. > > _______________________________________________ > Icecast mailing list > Icecast at xiph.org > http://lists.xiph.org/mailman/listinfo/icecast >I have to toss in this. There is a project out there called liquidsoap which is a streaming client (plugs into Icecast, but doesn't replace it AFIK) that can do all sorts of fun jingles, and seamless switches between live and standard streams. savonet.sourceforge.net is the page site, and they have some pretty good basic examples and great stuff to get it working (I use it personally rather simply, to branch my ogg/vorbis stream to mp3) ~Seann// -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5614 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.xiph.org/pipermail/icecast/attachments/20090513/5d7a4648/attachment.bin