[vorbis-dev] streaming metadata requirements

[Beni Cherniavsky]

[ This is a long post.  In short, I propose to keep pure chained streams
on disk and add some "macro" facility to streamed data to reuse codebooks,
provided the clients agrees to parse it - either as vorbis-specific and
maybe protocol-specific thing or better as generic Ogg spec extension. ]

On Mon, 11 Jun 2001, Monty wrote:

> On Mon, Jun 11, 2001 at 03:50:43PM -0700, Segher Boessenkool wrote:
> > > Another obvious solution is to make a substream that's nothing but
> > > vorbis comment header packets, and update that way. This is *really*
> >
> > Why put it in a separate substream?  We could just change the spec to
> > allow new headers halfway into the "normal" stream (the spec doesn't
> > specifically disallow it at the moment, even).
>
> I intend that it is disallowed.  The comment header is not for
> streamed metadata, and doing this behind the chaining mechanism's back
> breaks or compromises design assumptions in the Ogg layer.
>
> Monty
>
I agree with Monty, keeping the chained streams independent is a right
design IMO:

- Easier to separate the chained parts latter.

- The codebooks _can_ change between chained streams (at least in a future
encoder), and other changes, like sample rate, mono/stereo can happen.

- In the case of commercials mentioned earlier, it's more logical to
"paste" the once-encoded commercials than encode them every time (unless
you crossfade them).

The streams should be separate, on the disk at least.  I think the
streaming bandwidth waste can be solved by adding a sort of "codebook
reuse compression" at the streaming layer that restores the chain parts to
be independent on the recieving side, for either decoding or saving the
stream.  The server would compare every new codebook to the (remebered)
previous one and tell the client "insert here the last codebook you
remember" instead of resending it.

I don't think it should be obligatory for a decoder to support this - only
if it informs the server that it's capable of it.  This way "dumb" clients
and servers (for example servers entirely ignorant about ogg) remain
possible.  The specific mechanism might be defined as an extension to the
vorbis spec (that has right to live only in streamed data), or can be
stream-protocol specific.  For example RTP will get the headers
out-of-band anyway, won't it?  Then the headers can be assigned IDs, and
the requesting client would say "I have codebooks from headers 31A, 5F2,
F00;  tell me what to reuse or send new ones (and send the full other
headers in any case".  Similar arrangements can probably made with http
(cookies?).  The client also says "I promise to remember the last N
codebooks at any time through this stream / this session" (however a
session will be defined).  If the client dies, when he is rerun, he
doesn't say he has anything and gets the full codebooks first time.

Better yet, define this as a generic extension to the Ogg layer (which is
anyway intended for streaming): mark some pages/packets/byte ranges (we
don't know what parts of Tarkin's and other future codecs' data will be
likely to repeat) as "remember me" and add "include remembered part X
here" notation.  Again, this can only exist in a stream, must be expanded
before decoding or saving to disk: demanding this from a client demands
him to allocate memore, which he could be short of.  The way I see it is
extending the Ogg library with extra API that says "allocate N buffers of
B bytes for remembering" and "assume reader has N buffers of B bytes" -
with a protocol-depended way for a client to tell the server that this
much buffers can be expected from him.  Probably a streams starts with
some "I will indeed use that many buffers of yours", otherwise the
undeeded buffers are deallocated (the server must support this and be
willing to allocate this much).  When saving to disk the client must
rebuild the stream with "assume reader has no buffers".  This can also be
made to support some IDs to use the mechanism accross disconnet /
reconnect - probably tell the server "consider this a direct continuation
of stream X you gave me 5 minutes ago" - and consistently feed the ogg
layer with them as such.

One buffer from the last part of the chain is easy to support for decoding
but not saving by asking the vorbis decoder to keep the (decoded) codebook
around.


-- 
Beni Cherniavsky <cben at crosswinds.net>
                 (also scben at t2,cben at tx in Technion)

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