[vorbis] YAVTS (yet another vorbis test stream)

[Manuel Lora]

Since you mention that detecing catching up is harder, is it -or would it be 
feasable- on the client plugin side to select an average bitrate (modem, 
cable, whatever, or 28, 56, 128, etc) and that information be sent to the 
server. That way it might minimize peeling.

ml

> First, there are two things here.  Peeling and negotiation.  Do not lump
> them together :)
>
> Peeling will be some combination of cascaded codebooks and choppin off
> the ends of packets as they fly by.  Fairly easy, and probably not very
> resource intensive, so we could do this on the fly for every client.
>
> Negotiation is a protocol concern.  Not a format one.  For instance,
> RealNetworks SureStream just chooses between one of several encodings
> (ie, a surestream file has all bitrates included, it is not peeled).  In
> icecast, we know when you've fallen behind.  It's somewhat harder to
> detect catching up, but i think with some clever testing and guessing we
> can come up with something that works pretty well.
>
> jack.
>
> --- >8 ----
> List archives:  http://www.xiph.org/archives/
> Ogg project homepage: http://www.xiph.org/ogg/
> To unsubscribe from this list, send a message to 'vorbis-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.


-- 
Uptime:
  6:46pm  up 1 day, 12:07,  2 users,  load average: 0.16, 0.06, 0.06
My father taught me three things:
	(1) Never mix whiskey with anything but water.
	(2) Never try to draw to an inside straight.
	(3) Never discuss business with anyone who refuses to give his name.

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-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.