[vorbis-dev] RFC draft for Vorbis over RTP

[Segher Boessenkool]

On 26-mei-04, at 12:14, Jack Moffitt wrote:
> All the files produced by current encoders
> use the same set of codebooks for the same configurations anyways.

This is not a good argument, of course; it would restrict one
standard (Vorbis streams) to be more restricted than it already
is, to be able to cooperate with another standard (Vorbis RTP
transmissions) that is supposed to be dependent on it, not the
other way around.

You can of course make this restriction, but you'll need a
better argument than this.

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

That might be worthwhile.  But I'm not convinced yet.

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

I think he means "start another logical stream".  And yes, you
can get a quite relevant quality gain / bitrate reduction by
doing just that.

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

Erm no.

I showed that just changing the static Huffman code helps anywhere
between 0%-5% on average streams, 5%-20% on pretty quiet streams,
and about 10% on some of the less-well tuned modes of the Xiph
libvorbis encoder.

I also showed (without code; just based on a statistical model)
that fully tuning the codebooks will on most streams help 20%-40%
bandwidth.  Actually coming up with very good books (even for a
static stream, with full prediction) is quite non-trivial, though.

Also, good books tend to be very big.  Not funny for the cheap
portable players, and sure not nice for streaming over a low-
bandwidth network.

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

Of course.  There's only one set of codebooks per logical stream.

If the transmitter wants to save bandwidth when changing codebooks,
it could do so by out-of-band transmission of the new codebooks,
some time before the actual change; that way, it can prevent too
big bandwidth surges.

> Exactly.  I think in the case of streaming, it is more or less expected
> that a stream will have a fixed set of parameters.

True enough.  But I can't see a compelling reason to prohibit
chaining of logical streams; and if chaining is allowed, changing
books should be allowed, too.

<p>Segher

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