[xiph-rtp] header caching and chaining

[Ralph Giles]

On Thu, Feb 03, 2005 at 09:31:26PM +1000, Geoff Shang wrote:

> Those of us using vorbis streams so far rely on the ability to chain 
> streams for providing metadata updates.  So streaming title and artist 
> information, etc.  Now I don't think we should lose this ability unless 
> there's a good reason for losing it.  Whether this is the best mechanism 
> for conveying this info is another question, and if it can be carried 
> without support for chained bitstreams then I guess that's fine.

The plan is to replace this with a separate metadata stream through 
which the updates can be sent. (We could also use in-band transmission 
of metadata header packets.) So this functionality won't go away, but is 
outside the scope of the vorbis/theora RTP draft.

We'd kind of always intended to do this anyway. The simple flat 
classification the in-stream metadata headers provide is more limited 
than what some people want, and the precedence rules for multiplexed 
streams are kind of hacky.

The Ogg requirement to transmit new codebooks at a chaining boundary 
whenever the metadata changes also causes a nasty bandwidth spike in 
very low bitrate streams, which a separate stream also helps with.

> I do also like the idea of being able to change audio format, as it's a big 
> plus over MP3, but I realise I'm a voice of 1 and may get shouted down on 
> this one.

It's not that we don't appreciate the feature, but it's important to 
make tradeoffs against implementation complexity.

> I also presume that scaling down to a lower bitrate version of a stream due 
> to bandwidth limitations might also be affected if chaining is not 
> supported.

Correct. Without chaining it works more like an analog feed: you pick 
the parameters you want the channel to support and they're fixed for the 
duration of the connection.

 -r