[vorbis-dev] streaming metadata requirements

rillian rillian at telus.net
Tue Jun 12 14:32:52 PDT 2001



On Tuesday, June 12, 2001, at 07:48 , Jack Moffitt wrote:

> This isn't so bad, except that if the data entry is delayed, the stream
> boundaries won't have any real significance.  But the slight delay in
> data is probably perfectly fine.

Isn't that was 'tape delay' is for? :-)

> [...]
> In the normal cases though, resending codebooks hasn't been a big
> problem.  Although if you're paying  bandwidth bills on a few hundred
> thousand listeners per month with an avg. listening time of 90 minutes
> (medium sized operation), the codebooks can add up.

Does it really work this way? Say you're streaming at 32 kbps, and the 
headers are 12kB, or the equivalent of three seconds of audio. That 
seems on the worse-case side. Even 12 commercials an hour raises your 
average bandwidth less than 2%. Peak bandwidth is more of an issue, 
that's 20% over a 15 second commercial, across all your users. You've 
certainly got more experience with streaming, but I'd expect if you're 
within 20% of your server capacity you'd be dropping people anyway from 
general burstiness.

Things are worse on the client side. Most players I've seen have 4 to 8 
seconds of streaming buffer. If this is over a 36 kbps modem link, we 
have to make up the extra 3 seconds at 4 kbps, so it takes 24 seconds to 
refill our streaming buffer. Thus 30 second commercials are fine, but 15 
will skip unless you go to something like a 128 kB buffer (and hope you 
don't join within a few minutes of a commercial break!)

So unless I'm missing something, the 'extra bandwidth bill' is spurious, 
but the 'dropping clients' issue isn't.

  -ralph

--- >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-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 Vorbis-dev mailing list