Geoff Shang wrote:>My experience is that if you just want to stream content from a web server, >there won't be nice and neat transitions between your files. > >Yes, I see, of course. OK we won't do that, so can we use IceCast to stream a pre-built playlist file containing individual .ogg files all encoded at the required bitrate? I'm hoping so, so we don't have to purchase 500+ PC's to feed all the streams to IceCast. Can someone confirm if this is possible. Thanks, Ross Levis. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> I still need to know quite urgently if IceCast can provide a stream from > a pre-built M3U playlist file or not. Is this possible?<p>Additionally - icecast can actually directly serve the m3u file to the clients, and then the clients can individually access the songs. This brings up the issue of making ripping streams rather easier than you'd like, of course. Mike --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Adon Irani wrote:>you mean you have a pool of .ogg/.mp3 files ( perhaps an open po0l with >personal folders, etc ) . and you want to generate a playlist to a select >few or more of these files .. so that a listener will tune in at a certain >time, and listen to whichever types of songs you've decided for that time > >Basically, yes.>you don't want to do live simulcast sh0ws , correct? .. just offer 24-7 >music ( which will change depending on the time ) . you don't want to have >actual radio shows w/ song intro's , etc . . >That is correct, however, there will be song intro's etc because they will be pre-recorded as audio files.>this you can certainly do . instead of having icecast generate the .m3u >file , you could do this through php . >Ideally, yes. However, I will be writing a standalone Windows app to generate the m3u's on a daily basis.>if you have all the songs registered in a database , you could have an >already played index to track this ; and generate a rand0m song list and >filter out those tracks already played . and have different logics for the >different time of day . > >I can't go into details but the song selection won't be random. They will all be pre-selected manually by lots of DJ's and sent to the main server. My app will be combining lots of 2 hour shows into different playlists for different streams.>if you're not live encoding , icecast prolly still has performance >advantages over other on-demand streamers >That's nice to know, however, I was talking about the alternative of not using a streamer at all. ie. The M3U's look like a local playlist with each audio file specified in it. However, this would provide easy downloads if anyone looked at the m3u so I don't think we will go this way. I still need to know quite urgently if IceCast can provide a stream from a pre-built M3U playlist file or not. Is this possible? Thanks, Ross Levis. <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> I still need to know quite urgently if IceCast can provide a stream from > a pre-built M3U playlist file or not. Is this possible?Icecast itself can't - but most source clients can (_without_ reencoding, so the cpu load is fairly low). ices does this well. 'Urgent' requests like this tend not to get quick replies - one of the downsides of open source/free software is that it's typically stuff we work on outside business hours - so if you want quick support, etc., you may be lucky, but there are no guarantees. (we're happy to provide support or development for money/under contract, for anyone who is interested, by the way). Mike --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> > >you don't want to do live simulcast sh0ws , correct? .. just offer 24-7 > >music ( which will change depending on the time ) . you don't want to have > >actual radio shows w/ song intro's , etc . . > > > That is correct, however, there will be song intro's etc because they > will be pre-recorded as audio files.right . but all the content is pre-recorded and stored on the server ? in which case , you just need to track the song names and generate a custom m3u for it . i'm pretty sure an m3u file can contain multiple lines (ie, songs to play )> Ideally, yes. However, I will be writing a standalone Windows app to > generate the m3u's on a daily basis.the m3u doesn't have to be on the same server as the mp3/ogg files , but your windows app would have to be able to determine what files to expect on the server and where ., <p>>> I still need to know quite urgently if IceCast can provide a stream from > a pre-built M3U playlist file or not. Is this possible?yes . so long as the playlist file is on the same server (or if it can be generated by a local script ) , you can use ices (the icecast streamer ) . this will read a playlist file and stream through icecast . you can then connect to this stream via its mountpoint .. so if you needed to have 1ooo's of playlists , you would still need to have 1ooo's of mountpoints . however, if you are using the fileserve option ; you only need to generate a playlist that links to these songs . however, this again opens up security issues of direct access to the songs ( perhaps someone else can speak about this .. i'm not sure how this all works ) a:/, --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Tue, 11 Mar 2003, Ross Levis wrote:> That is correct, however, there will be song intro's etc because they > will be pre-recorded as audio files.My experience is that if you just want to stream content from a web server, there won't be nice and neat transitions between your files. If you have an M3U like so: http://www.myserver.com/content/songintro.mp3 http://www.myserver.com/content/song.mp3 And play that in your player of choice, my experience is that the player will buffer and play the intro, *then* buffer and play the song. So there'll be a gap whilst the song is being buffered, after the intro. Not likely to be the result you're looking for. Geoff. <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Adon Irani wrote: ------------------ however, if you are using the fileserve option ; you only need to generate a playlist that links to these songs . however, this again opens up security issues of direct access to the songs ( perhaps someone else can speak about this .. I'm not sure how this all works ) ------------------ (Long: semi-detailed explanation of how to do secure file-serving below - does not involve icecast) It is fairly simple (and known since the beginning of CGI) to restrict access to files served to the web from a webserver. Webservers generally provide some built-in security that usually leverages the file security of the operating system. Many times, that security is not dynamic enough for an application. There are hundreds of examples (if not more), to "serve" files dynamically. Basically, if you want to go the fileserve route, all you have to do is to create a script or executable (depending on your choice of dev platforms, operating system and webserver) that takes parameters (query string (GET), form data (POST), or session variables) that tell the script which "file" (read: MP3 or ogg) to send to the client. That script can perform the necessary authorization to determine if this client is allowed to download/stream this file. It's simple, even MS provides source code to do this. The way it works is you have this script that can take parameters and return data (it can be perl, php, asp, cgi, whatever). Let's say it is located at http://localhost/getFile.asp. You pass it the following data: File=waynefrigginnewton.ogg. getFile.asp opens the waynefrigginnewton.ogg file and sends every byte it reads to the Response, and thus the client (Winamp). The actual ogg file is located in a private directory that is not accessible from the published directories of your webserver. Thus no one can actually download the file directly, they must go thru your script to get it. That will at least make it a little harder for people to download your songs. The way to take it a step further is to add authorization (which may include authentication) in your script. This can be things like 1) has this client already downloaded this song 2), how long has this client been connected to my server (when did their session start?) 3), how many other songs has this client downloaded, etc. You could also require a usr/pwd as the data passed to the script. Probably the best, and most used method is to require users to go to your website first (this lets you track their session)..they may or may not "log in" to your site, but you still know who they are uniquely. You can then provide link(s) to your (static or generated) .m3u or .pls directly. If you generated the m3u file, you can include the unique ID of the client in the links. So your m3u file might look like: http://mydomain.com/getFile.asp?ID=ASDF1234QWER1234&file=waynefrigginnew ton.ogg http://mydomain.com/getFile.asp?ID=ASDF1234QWER1234&file=britneyfriggins pears.ogg http://mydomain.com/getFile.asp?ID=ASDF1234QWER1234&file=frankfrigginsin atra.ogg http://mydomain.com/getFile.asp?ID=ASDF1234QWER1234&file=foofrigginfight ers.ogg Your getFile script then just tracks the client by the "ID" value and their webserver session to determine what they are allowed to "Stream" from your script. If they ever just go straight to your getFile script on your webserver but have an invalid or expired ID they get nothing. As you can see you can get quite innovative on how you handle this and what you choose to let your clients do. It all depends on how much development you want to do to handle the authorization. This is done ALL the time on the web to restrict access to files like images (pr0n) or pdf's that may contain sensitive data that you want to provide on the web, but don't necessarily want anyone to be able to get to unless they go thru the proper steps. And it may be prohibitive to use just the OS's file system security due to a number of reasons like: hosted sites (it ain't your box so you can't control file security) or you cannot dynamically generate usrs/passwords and restrict directory/file access, etc. The biggest hurdle (which isn't much) is to make sure your script has read access to the unpublished directory that contains the files you want to stream. The downside to this approach, and the reason it isn't used more often for simple things, is that there is a performance hit by doing the file I/O this way, rather then just letting the webserver do it. Hope I didn't bore you all to death with this off-topic message. Todd --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.