Icecast - Aug 2004 - does icecast care what it streams?

On 3 Feb 2004 at 12:06, Michael Smith wrote:
> On Tuesday 03 February 2004 00:41, Joern Nettingsmeier wrote:
> > ...i.e. could it stream arbitrary stuff (such as video) if i don't
> > care about metadata?
> 
> Most of icecast doesn't care. However, some bits do, so it's
neccesary
> to have some handling code in it for each datatype.
> 
> It would be _very_ easy to add support to icecast for streams of type
> "application/octet-stream" - i.e. a stream that icecast should
just
> feed straight through without having any special handling for at all,
> then you could use that for your purposes.
Would this e.g. allow for Nullsoft Video, mpeg4-video or similar to 
be broadcasted? Or did maybe someone have a closer look on how to 
implement streaming for such data types?

<p>Regards,
 Stefan
--- >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.

At 07:16 PM 2/2/2004, you wrote:
>On 3 Feb 2004 at 12:06, Michael Smith wrote:
>
> > It would be _very_ easy to add support to icecast for streams of type
> > "application/octet-stream" - i.e. a stream that icecast
should just
> > feed straight through without having any special handling for at all,
> > then you could use that for your purposes.
>
>Would this e.g. allow for Nullsoft Video, mpeg4-video or similar to
>be broadcasted? Or did maybe someone have a closer look on how to
>implement streaming for such data types?
it would be true to say that yes, you could stream NSV or other video types 
with this manner (assuming that they don't need special stream processing, 
NSV does not, something like Ogg-Theora probably would)...the main problem 
is the issue of a source client.  Currently, there is only one (that I know 
of) source client that will encode and send NSV, and that is the one that 
will only connect to shoutcast and uses shoutcast's proprietary method and 
customization of HTTP for it's connection protocol.  Icecast currently does 
not (and probably will not) support this type of connection.  Similarly, 
the Windows Media Encoder (which can also be used to generate a video 
stream) also uses a connection protocol that is not supported by Icecast 
(they use a entirely different method which involves "pulling" the
source
stream from the client rather than the client "pushing" the source
stream
to the server.

o yes, we can support streaming of video with Icecast, and probably the 
first step is to build a source client which can generate a video stream 
using a codec that doesn't have any special handling properties and can be 
modified to support the icecast connection protocol.

oddsock

<p>>Regards,
>  Stefan
>--- >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.
<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.

On Tuesday 03 February 2004 15:16, oddsock wrote:
> it would be true to say that yes, you could stream NSV or other video types
> with this manner (assuming that they don't need special stream
processing,
> NSV does not, something like Ogg-Theora probably would)...the main problem
> is the issue of a source client.  Currently, there is only one (that I know
> of) source client that will encode and send NSV, and that is the one that
> will only connect to shoutcast and uses shoutcast's proprietary method
and
> customization of HTTP for it's connection protocol.  Icecast currently
does
For the record: shoutcast's protocol is not a 'customization of
HTTP'. It
superficially looks somewhat similar, but actually isn't. At all - which is 
why icecast doesn't support it - it's a lot of pain for very little
gain.

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.

> At 07:16 PM 2/2/2004, you wrote:
> [..] Similarly, the Windows Media
> Encoder (which can also be used to generate a video stream) also uses
> a connection protocol that is not supported by Icecast (they use a
> entirely different method which involves "pulling" the source
stream
> from the client rather than the client "pushing" the source
stream to
> the server.
As of WindowsMedia9, you can also have the Source Client "pushing" 
the stream to the server, using the HTTP-POST-Method (at least it 
looks like the source client is sending a POST-Request.. as I don't 
have a WM-Server, I couldn't check out a true client<->server-
connection). Since it's Microsoft, I presume there is still some 
propietary handling in the background. Would someone care to look 
deeper into this? Are we even allowed to support WM9, according to 
MS' licenese terms?

Oh, BTW: First post here (I guess.. been reading for almost a year 
now, thanks for all the tips and a huge thank you for icecast2) :-)

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