[vorbis-dev] streaming metadata requirements

[Segher Boessenkool]

> Michael seemed to agree with Jack that the cost of chaining boundaries
> is a real problem and added the fear that if we don't resolve it people
> will go back to things like the shoutcast separate udp broadcast, or
> those terrifying icy-headers stream-interleaved tags.
> 
> Now, monty has clearly vetoed adding updatable metadata to vorbis
> itself. That leaves us two places to put it. Outside the ogg stream
> entirely, or in a parallel, multiplexed logical bitstream.

Okay, how about this:

When we are _streaming_ a chained stream, don't send headers that are
equal to the same header for the previous substream (unless a new client
connects, of course).  The decoder could just detect this and reuse the
old codebooks or comments or whatever.  This wouldn't break anything, or
would it?  Note that I am _not_ suggesting leaving those headers out of
on-disk streams; only don't transmit them if not necessary.

> The second is at least part of the general plan. Problem is, Monty also
> marked the issue of multiplexed streams "won't fix" for rc1, and likely
> 1.0. I'd been holding off on the kithchen-sink, separate-stream metadata
> format until I felt we could do it right the first time, but as far as
> people think this is important I'm perfectly happy with vcomment packets
> in a separate bitstream. It nicely contains the special-casedness of the
> format, and players are free to ignore it. So this seems the best way
> forward to me.

Seems like I need to hurry implementing libogg2;  that'll nicely solve this.
I'll see if I can find time to chat about it this friday (on irc).

Cheers,

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.