[vorbis-dev] RFC draft for Vorbis over RTP

[Jack Moffitt]

> One drawback is of course, that you can't take any existing Ogg/Vorbis 
> stream or the output of any Ogg/Vorbis encoder, feed it to the streaming 
> server and expect it to work. If you restrict the entire transmission to 
> one set of codebooks, you need "RTP enabled" encoders, which can be 
> configured to follow this restriction. 

All the files produced by current encoders
use the same set of codebooks for the same configurations anyways.  You
can just take a lot of files output by the encoders, strip the
codebooks, renumber the granulepos for a new valid Ogg file.

Any encoder producing a _single_ logical bitstream can just be passed
straight to the server.

I'm not saying "pick a set of codebooks" for everything.  I'm saying
send a single set of codebooks on setup, and restrict the stream to
_that_ set for the duration.  Essentially disallowing chains over RTP.

> I am not able to judge the impact 
> of this myself and it is difficult to estimate which quality gain to 
> expect by changing the codebooks "on the fly". 

We don't change codebooks "on the fly".  New encoders use new codebooks.
All current encoders that I know of have used a fixed set of codebooks
for that encoder generation.  But there are several generations of these
fixed sets.

> AFAIK, the reference 
> encoder works with a fixed set of codebooks anyway, but then the 
> question comes up: Was the ability of dynamic codebooks in the format 
> spec really worth the added implementation complexity?

Yes, as we can now see by the listening test results using alternate
tunings.

Again, I'm not suggesting we undo this feature.  We did not really
design Vorbis to have a different set of codebooks tailored to each
file.  We put those in there so that new changes could be made in
tunings and encoding without having to break the spec and write new
decoders.  In fact, Segher showed that tuning codebooks for specific
files gave you minimal gain anyway (tuning for size in this case).

So it's not expected that codebooks will change during the duration of a
stream.  Allowing them to just mirrors the way Ogg files and Icecast TCP
based streaming already work, ie, supporting chains.

> But, unrestricted streaming of any chained Ogg/Vorbis files may cause 
> other problems. What if other relevant parameters change - like sample 
> rate or number of channels? Is it possible to model this using SDP/RTP? 
> I think not...

Exactly.  I think in the case of streaming, it is more or less expected
that a stream will have a fixed set of parameters.  I can't think of any
counter arguments off the top of my head, so this idea seems like a
valid and worthy compromise.

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-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.