[icecast-dev] Re: PATCH: increase network congestion resilience

[Ricardo Galli]

On Saturday 18 January 2003 16:04, Michael Smith shaped the electrons to 
shout:
> On Sunday 19 January 2003 01:59, Ricardo Galli wrote:
> > On Saturday 18 January 2003 03:37, Michael Smith shaped the electrons
> > to
> >
> > shout:
> > > We can't just drop packets, the transmission model assumed by the
> > > format handlers (and required by at least one of them) will not
> > > permit
> >
> > It's not vorbis. Does it?
>
> Vorbis certainly DOES require us to not drop packets. It'll work most
> of the time, but if you happen to do it at the wrong time, you'll end
> up sending a corrupt stream to the client. This is a bad idea.
...
> Yeah, you've been lucky (well, not THAT lucky, you're relatively
> unlikely to hit the broken cases) and not done this at one of the times
> where it will cause errors.

In icecast/vorbis each refbuf is composed of a entire page, and the 
documentation (http://www.xiph.org/ogg/vorbis/doc/oggstream.html) states 
that a page contains the necessary headers to reconstruct the packetsand 
re-sync the stream. So, the players must be able continue playing if it 
receives an out of sequence page. 

Because a refbuf is a page, we could drop them all but the logical stream 
headers, which are cached and sent first (easy to check). So, before 
discarding a page, we should check is "complete" (in the sense that the 
headers were not already sent, i.e. client->pos == 0) and that is not a a 
pre_data.

OTH, it seems logic and without that property icecast wouldn't work: when 
a new client connects, icecast sends it a pre_data and then start with 
the first available _random_ refbuf. What's the problem with "restarting" 
the stream with a "new", out of sequence, refbuf?

But I could be missing something, sorry if so.

<p>
-- 
  ricardo galli       GPG id C8114D34

--- >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 at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.