Icecast - Aug 2004 - Newbie question - on demand streaming?

Hi,
>> Just thinking about migrating from Shoutcast.....  I have a question
>> on how to make Icecast behave as I have Shoutcast running, and provide
>> "on demand" streaming via my web server. In other words,
currently I
>> have a link on my webserver such as thus:
>
> If you already ahve a websserver, why use icecast or shoutcast at all?
Well, a number of reasons.  Dedicated streamers are better at streaming
audio/video than webservers, the major reason for using Shoutcast et
al.  .m3u files suck (which is how I presume you feel I should be streaming
from my webserver).....I seem to remember you have to play around with mime
types et al.  Dedicated streaming gives me the ability to do live
broadcasts and thus gives me greater flexability than just using my
webserver.  Webservers are intended for delivering markup language and are
good at it.  Thus I prefer leaving them to do that and that alone.
Seperating duties tends to give a nicely cohesive environment...i.e. My
webserver dishes up web pages, my audio server dishes up audio.  Nice
design principles in there somewhere.  etc etc.....I could go on.

The reason I wanna go Icecast is that I'd like a truly GPL'd
environment,
not some pseudo one like Shoutcast.

So lets just take it for given that I'm mad and that I'm gonna use a
dedicated streamer such as Icecast.  Can I make it behave like Shoutcast's
on demand feature detailed in my original mail?

Rgds,

Steve Huckle


-- 
Imagine a world with no hypothetical situations....

-----------------------------------------
This email was sent using SquirrelMail.
   "Webmail for nuts!"
http://squirrelmail.org/

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

> Well, a number of reasons.  Dedicated streamers are better at streaming
> audio/video than webservers,
In theory.  In practice this is not true.  Apache is far more robust
than any streaming server I've seen yet, and far more stable.  Many of
the scaling issues have been addressed, and the drawbacks are minimal.

Streaming servers should be better for two reaosns.  1) they can be more
efficient.  they are serving a very specific kind of data.   2) they can
use protocols like RTP to improve quality.

Neither of these things is true of any server yet.  Apache offers more
functionality and works better than the alternatives for on demand
streaming.

Once more clients use RTP then there's a large case for using a
streaming media server for on-demand as opposed to using apache.  As
right now they both use TCP and most HTTP too, it's better to use the
better tool.
> al.  .m3u files suck (which is how I presume you feel I should be streaming
> from my webserver).....I seem to remember you have to play around with mime
> types et al.  
Use a simple cgi script or some such to autogenerate m3u's and set
mimetypes correctly.  This is trivial.
> Dedicated streaming gives me the ability to do livek
> broadcasts and thus gives me greater flexability than just using my
> webserver.  
I wasn't talking about live streams or even simulated live streams.  I'm
only proposing apache for on-demand streaming of static content.  Hell,
it even supports seeking.
> Webservers are intended for delivering markup language and are
> good at it.  
This was true years ago.  Webservers are now built for serving general
data over the HTTP protocol.  They commonly do serve large files, and
HTTP has replace FTP in most cases for file download.  Web server
evolved to handle generic data more and more, and teh fact that they
have been around forever, have lots of tool support, and lots of
configurability makes them the right tool for the on-demand streaming
job on today's internet.
> Seperating duties tends to give a nicely cohesive environment...i.e. My
> webserver dishes up web pages, my audio server dishes up audio.  Nice
> design principles in there somewhere.  etc etc.....I could go on.
You can use the same argument a different way to argue for keeping them
together.  They both travel over HTTP.  Use a common server.  When audio
data starts getting pumped over RTP or some other non-HTTP protocol,
then there is a strong case for not using a web server.
> The reason I wanna go Icecast is that I'd like a truly GPL'd
environment,
> not some pseudo one like Shoutcast.
Apache is also Free Software.
> So lets just take it for given that I'm mad and that I'm gonna use
a
> dedicated streamer such as Icecast.  Can I make it behave like
Shoutcast's
> on demand feature detailed in my original mail?
Yes.  The support is there, but it's not great.  The staticdir config
option points to a dir of files.  And then you can access these at
http://url:port/files/blah.mp3.  Note that it probably won't generate
m3u's for you.  I have forgotten if it does that or not.

jack.

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

Jack Moffitt wrote:
> Once more clients use RTP then there's a large case for using a
> streaming media server for on-demand as opposed to using apache.  As
> right now they both use TCP and most HTTP too, it's better to use the
> better tool.
Any chance of seeing a UDP-based transport for icecast in the near
future? Also, downscaling in case of degrading bandwith?

Akos

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

Hi Jack,

Thnx for the feedback....a strong argument and I'll consider it.  Somewhat
puzzled you're making a case for using Apache for on-demand streaming
though....since Icecast is your baby.  Is Icecast so inferior here?

And I agree that RTP will be a big leap forward.  There IS a server on the
way for this....check out http://www.danubio.org.

Rgds,

Steve Huckle
>> Well, a number of reasons.  Dedicated streamers are better at
>> streaming audio/video than webservers,
>
> In theory.  In practice this is not true.  Apache is far more robust
> than any streaming server I've seen yet, and far more stable.  Many of
> the scaling issues have been addressed, and the drawbacks are minimal.
>
> Streaming servers should be better for two reaosns.  1) they can be
> more efficient.  they are serving a very specific kind of data.   2)
> they can use protocols like RTP to improve quality.
>
> Neither of these things is true of any server yet.  Apache offers more
> functionality and works better than the alternatives for on demand
> streaming.
>
> Once more clients use RTP then there's a large case for using a
> streaming media server for on-demand as opposed to using apache.  As
> right now they both use TCP and most HTTP too, it's better to use the
> better tool.
>
>> al.  .m3u files suck (which is how I presume you feel I should be
>> streaming from my webserver).....I seem to remember you have to play
>> around with mime types et al.
>
> Use a simple cgi script or some such to autogenerate m3u's and set
> mimetypes correctly.  This is trivial.
>
>> Dedicated streaming gives me the ability to do livek
>> broadcasts and thus gives me greater flexability than just using my
>> webserver.
>
> I wasn't talking about live streams or even simulated live streams.
> I'm only proposing apache for on-demand streaming of static content.
> Hell, it even supports seeking.
>
>> Webservers are intended for delivering markup language and are
>> good at it.
>
> This was true years ago.  Webservers are now built for serving general
> data over the HTTP protocol.  They commonly do serve large files, and
> HTTP has replace FTP in most cases for file download.  Web server
> evolved to handle generic data more and more, and teh fact that they
> have been around forever, have lots of tool support, and lots of
> configurability makes them the right tool for the on-demand streaming
> job on today's internet.
>
>> Seperating duties tends to give a nicely cohesive environment...i.e.
>> My webserver dishes up web pages, my audio server dishes up audio.
>> Nice design principles in there somewhere.  etc etc.....I could go on.
>
> You can use the same argument a different way to argue for keeping them
> together.  They both travel over HTTP.  Use a common server.  When
> audio data starts getting pumped over RTP or some other non-HTTP
> protocol, then there is a strong case for not using a web server.
>
>> The reason I wanna go Icecast is that I'd like a truly GPL'd
>> environment, not some pseudo one like Shoutcast.
>
> Apache is also Free Software.
>
>> So lets just take it for given that I'm mad and that I'm gonna
use a
>> dedicated streamer such as Icecast.  Can I make it behave like
>> Shoutcast's on demand feature detailed in my original mail?
>
> Yes.  The support is there, but it's not great.  The staticdir config
> option points to a dir of files.  And then you can access these at
> http://url:port/files/blah.mp3.  Note that it probably won't generate
> m3u's for you.  I have forgotten if it does that or not.
>
> jack.
>
> --- >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.

-- 
Imagine a world with no hypothetical situations....

-----------------------------------------
This email was sent using SquirrelMail.
   "Webmail for nuts!"
http://squirrelmail.org/

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