[icecast-dev] Re: PATCH: increase network congestion resilience
gallir at uib.es
Sat Jan 18 08:18:58 PST 2003
On Saturday 18 January 2003 16:04, Michael Smith shaped the electrons to
> 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
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.
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.
More information about the Icecast-dev