[Icecast-dev] Icecast2 Burst-on-Connect

Michael Smith mlrsmith at gmail.com
Thu Feb 17 01:29:59 PST 2005


On Wed, 16 Feb 2005 23:25:24 -0800, Greg J. Ogonowski <greg at 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


More information about the Icecast-dev mailing list