Icecast dev - Aug 2004 - Server-side streaming roundup

Hi Icecasters!

I'm trying to gather information about the open source streaming scene 
(server-side) and, well, I consider three contenders (am I missing one?) 
for the "best streaming architecture". They are (in no particular
order)...

- (Vorbis's)? Icecast 2.0 + Ices
- Apple's Darwin Streaming Server (Quicktime Streaming Server) 4.1
- Real's Helix Platform

My study being in its earliest stage, I have some basic questions for 
you folks.

1. Why is the community that fragmented? I know that those 3 projects 
have different goals and provide different features, but if you abstract 
to the level where they are all streaming architectures, wouldn't it be 
beneficial for all if there were a little more cross 
code-protocol-format-etc sharing-forking-branching-extending-whatever?

2. I look at the DSS 4.1 module API docs, at the RTP, RTSP, RTCP, and 
SDP RFCs, and at the MPEG-4 spec, and I just KNOW what I am dealing 
with. So where are the shoutcast / icecast protocol specs? Is there any 
architectural overview of the icecast system, somewhere? I looked at the 
libshout docs and old icecast manual.html already.

3. What do you people think of Apple and Real's initiatives, both 
technologically as well as socially (politically?)?

4. What do you thing of my icecast wish list (and gee, are some of them 
already implemented, planned?) :
Helix-like Marketing ;-)
DSS's docs, management interface and standard adherence
Transparent content negotiation
Structured metadata (An XML app would be great)
Advanced playlist support (cues, cuts, external metadata, permissions, etc.)
On-the-fly downsampling, and cross fading (between playlist elements)

<p>Yeah, I know some of those features fall under the ices scope, but I 
just wanted to gather everything under the same "product".

<p>vincent

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

At 07:44 PM 8/11/02 -0400, you wrote:
>Hi Icecasters!
>
>I'm trying to gather information about the open source streaming scene 
>(server-side) and, well, I consider three contenders (am I missing one?) 
>for the "best streaming architecture". They are (in no particular
order)...
>
>- (Vorbis's)? Icecast 2.0 + Ices
>- Apple's Darwin Streaming Server (Quicktime Streaming Server) 4.1
>- Real's Helix Platform
>
>My study being in its earliest stage, I have some basic questions for 
>you folks.
>
>1. Why is the community that fragmented? I know that those 3 projects 
>have different goals and provide different features, but if you abstract 
>to the level where they are all streaming architectures, wouldn't it be 
>beneficial for all if there were a little more cross 
>code-protocol-format-etc sharing-forking-branching-extending-whatever?
>
Basically because there is no community. Whilst apple's server is open
source (and maybe real's thing will be, I don't know details of that),
both of those are really commercial efforts that happen to be open
source. They've never even talked to us.
>2. I look at the DSS 4.1 module API docs, at the RTP, RTSP, RTCP, and 
>SDP RFCs, and at the MPEG-4 spec, and I just KNOW what I am dealing 
>with. So where are the shoutcast / icecast protocol specs? Is there any 
>architectural overview of the icecast system, somewhere? I looked at the 
>libshout docs and old icecast manual.html already.
There aren't real specs, mostly because documentation tends to come
last (which is admittedly a bad thing) in open source things. It's
basically just HTTP (from the client side, it IS just HTTP. There are
some minor extensions on the source side). Docs will come in time...

<p>>
>3. What do you people think of Apple and Real's initiatives, both 
>technologically as well as socially (politically?)?
Apple's is technically nice, but I don't know much about it. They
haven't really done a good job of marketing it.
Real's? I don't trust them at all (socially/politically), and I
don't
know anything about it technically.

<p>>
>4. What do you thing of my icecast wish list (and gee, are some of them 
>already implemented, planned?) :
>Helix-like Marketing ;-)
>DSS's docs, management interface and standard adherence
That'd be great, but it's a lot of work for something nobody gets
paid for at all.
>Transparent content negotiation
Meaning?

<p>>Structured metadata (An XML app would be great)

icecast2 does this, though it's currently fairly limited. Extending this
is planned.
>Advanced playlist support (cues, cuts, external metadata, permissions, etc.)
>On-the-fly downsampling, and cross fading (between playlist elements)
ices2 does some of these (external metadata, though that's incomplete for
one common case, on-the-fly resampling, and dynamically scriptable playlists
to give you some of the others), and could do others easily. And then there
are things like cross fading which it will never have if you wait for me
to write the code (because I HATE CROSSFADING!), but I'll apply patches
if others send them to me.

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

>>Transparent content negotiation
> 
> 
> Meaning?
Well I'm speculating here but, the icecast protocol extends HTTP and 
HTTP provides Accept* headers (locale, content type, encoding, etc).

So for a "/resource" request, any of the following files could be
served
back depending on the client's request, and server's default settings :

"/resource.en.medium.ogg"
"/resource.fr.medium.ogg"
"/resource.en.medium.mp3"
"/resource.fr.medium.mp3"
"/resource.en.low.ogg"
"/resource.fr.low.ogg"
"/resource.en.low.mp3"
"/resource.fr.low.mp3"
"/resource.high.ogg"
"/resource.ogg"
...

Wher the (full) naming scheme is :

"resource name"."locale iso
code"."bandwith"."encoding"

That would also affect the metadata.

<p>>>Structured metadata (An XML app would be
great)
> 
> 
> icecast2 does this, though it's currently fairly limited. Extending
this
> is planned.
Ok, so were should I look, in the code to overview the metadata 
funcionality?

Also, were is the best knowledge base on the icecast/shoutcast protocol?

<p>thanks a million,

<p>vincent

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