Icecast dev - Feb 2005 - Icecast2 Burst-on-Connect

Can anyone explain what the fundamental difference between the 
Burst-on-Connect mode that Icecast2 uses versus SHOUTcast?

There is a thread starting on the VLC Player list that is stating that the 
problems that VLC has playing Icecast2 Burst-on-Connect (default) streams 
is the fault of Icecast2.  I don't believe this is true, as Winamp has no 
problem with Icecast2 streams.  I'm hoping to get an explanation so that I 
can tell them what needs to be addressed in the VLC Player.

Thanks.
-greg.


________________________________________
Greg J. Ogonowski
VP Product Development
ORBAN/CRL, Inc.
1525 Alvarado St.
San Leandro, CA  94577  USA
TEL  +1 510 351-3500
FAX  +1 510 351-0500
Web:  http://www.orban.com
E-Mail:  greg@orban.com

On Wed, 16 Feb 2005 23:25:24 -0800, Greg J. Ogonowski <greg@orban.com>
wrote:
> Can anyone explain what the fundamental difference between the
> Burst-on-Connect mode that Icecast2 uses versus SHOUTcast?
> 
> There is a thread starting on the VLC Player list that is stating that the
> problems that VLC has playing Icecast2 Burst-on-Connect (default) streams
> is the fault of Icecast2.  I don't believe this is true, as Winamp has
no
> problem with Icecast2 streams.  I'm hoping to get an explanation so
that I
> can tell them what needs to be addressed in the VLC Player.
The whole point of burst-on-connect is "spray as much data at the
client on initial connect as you possibly can" (well, limited to your
buffer size). It's not conceptually complex or subtle - so it doesn't
seem likely that it's different in any really significant ways (but I
haven't done network traces on shoutcast streams to check).

The only thing I can think of that's almost certainly different is the
default size of the initial buffer (that's configurable in icecast,
and it might be configurable in shoutcast, but the defaults probably
differ). The HTTP headers differ in various ways too, but that
shouldn't be significant.

There's one thing that icecast doesn't do (except for ogg streams)
that other servers might (but from what I'm told, shoutcast doesn't):
start sending from some valid synchronisation point (e.g. the mpeg
sync pattern) - obviously, if you do that, it's a bit easier on
clients (but  I don't know of any that don't cope).

Mike

On Thu, 17 Feb 2005, Michael Smith wrote:
> There's one thing that icecast doesn't do (except for ogg streams)
> that other servers might (but from what I'm told, shoutcast
doesn't):
> start sending from some valid synchronisation point (e.g. the mpeg
> sync pattern) - obviously, if you do that, it's a bit easier on
> clients (but  I don't know of any that don't cope).
Media Player Classic requires a Content-Length: before it will stream.

So does Windows Media Player 6.4, except it also requires something else - 
could it be this mpeg sync pattern ?

Now discuss "Content-Length: -1" ...

Michael Smith wrote:
> The only thing I can think of that's almost certainly different is the
> default size of the initial buffer (that's configurable in icecast,
> and it might be configurable in shoutcast, but the defaults probably
> differ).
At least last time I checked, shoutcast had a 1 meg buffer (which was very 
annoying) that was not configurable.  This meant *huge* latancy at low bit 
rates.  And it would do stupid things like remember the end of the previous 
stream which was annoying as players would often choak when they got to the 
point where the new stream started.

Geoff.

On Thu, 2005-02-17 at 07:25, Greg J. Ogonowski wrote:
> Can anyone explain what the fundamental difference between the 
> Burst-on-Connect mode that Icecast2 uses versus SHOUTcast?
I can't see there being much difference if anything, the burst is just a
blast of data that icecast has in the queue (the last <burst-size> bytes
in fact)
> There is a thread starting on the VLC Player list that is stating that the 
> problems that VLC has playing Icecast2 Burst-on-Connect (default) streams 
> is the fault of Icecast2.  I don't believe this is true, as Winamp has
no
> problem with Icecast2 streams.  I'm hoping to get an explanation so
that I
> can tell them what needs to be addressed in the VLC Player.
The data that is sent is not modified in any way for bursting, it is
just sent at a quicker rate.  The main difference as already pointed out
by others is the amount, the default is 64kbytes (to match common
prebuffer sizes) for icecast whereas shoutcast blasts a whole lot more.

I can only think that VLC is getting its timing messed up because of the
burst.

karl.