ogg dev - Feb 2008 - Ogg/Kate preliminary documentation

> Right. This was, in fact, one of the roles of "chaining" where
you'd
> mark such changed components with a chain boundary, at which such
> things are explicitly allowed to change. The drawbacks are the
> overhead of resending all the setup data for configurable codecs like
> vorbis and theora, and the semantic conflict between 'chain boundary
> flags an edit point' and 'chain boundary flags a program
change' which
This also means that having to chain a particular logical stream implies
having to break and rechain all other multiplexed streams. For, say,
Theora (just imagining there, I don't know if that'd actually be the
case),
it could mean having to reencode a keyframe on the fly for the first frame
of the new chain, or go without video for whatever time is left before the
next keyframe (I've got no real idea how much time typically elapses
between keyframes, but I believe it is variable ?)
> There are certainly arguments for doing it both ways, but from the
> Annodex point of view it is nice to push as much of that onto the
> mux/skeleton level as possible, for all the reasons Silvia described.
> Do you have a counter illustration of where adding a new category
> suddenly, on the fly is contra-compelling?
No particular reason, just the fact that it constrains possible uses of the
codec, especially for on the fly generation.
I could certainly make up an example where one streams a video of people
in an office, and labels are placed near each person following them around,
but this is just a possible use I just made up, not something I actually need
to be done.
Not that the kate format currently supports well moving regions around in
realtime anyway, but that's something I'm thinking about currently.
> CMML 3.1 had a 'track' attribute that could be supplied to clips to
> make a similar distinction. We discussed this quite a bit at LCA last
> week and the general feeling was that we should remove that from CMML
> itself, focussing on its role as a text track codec for the 4.0
> revision, and push the multiple-stream affects up to the authoring
> level, with either a new xml format for describing stream contents, or
> in the stream itself.
I'm not totally sure I'm following you here.
The idea behind the category field was for a player program to automatically
classify the kate streams as being the "same". eg, if you have 16
streams,
in 8 languages, 8 of them having the category "subtitles" and the rest
having
the category "director comments", then the program could present a
list of
two available stream types, "subtitles" and "director
comments", in addition to
the language selection. This set of categories may or may not match any
categories that would apply to an accompanying multiplexed video, say.
If there was any (eg, not a text only stream).
> only, and so on. To say that a particular visual overlay should be
> applied to a particular video stream, and whether to do so by default,
That's an interesting use I hadn't thought of.

On Feb 11, 2008 9:27 PM, ogg.k.ogg.k@googlemail.com <
ogg.k.ogg.k@googlemail.com> wrote:
> > Right. This was, in fact, one of the roles of "chaining"
where you'd
> > mark such changed components with a chain boundary, at which such
> > things are explicitly allowed to change. The drawbacks are the
> > overhead of resending all the setup data for configurable codecs like
> > vorbis and theora, and the semantic conflict between 'chain
boundary
> > flags an edit point' and 'chain boundary flags a program
change' which
>
> This also means that having to chain a particular logical stream implies
> having to break and rechain all other multiplexed streams. For, say,
> Theora (just imagining there, I don't know if that'd actually be
the
> case),
> it could mean having to reencode a keyframe on the fly for the first frame
> of the new chain, or go without video for whatever time is left before the
> next keyframe (I've got no real idea how much time typically elapses
> between keyframes, but I believe it is variable ?)
>
> > There are certainly arguments for doing it both ways, but from the
> > Annodex point of view it is nice to push as much of that onto the
> > mux/skeleton level as possible, for all the reasons Silvia described.
> > Do you have a counter illustration of where adding a new category
> > suddenly, on the fly is contra-compelling?
>
> No particular reason, just the fact that it constrains possible uses of
> the
> codec, especially for on the fly generation.
> I could certainly make up an example where one streams a video of people
> in an office, and labels are placed near each person following them
> around,
> but this is just a possible use I just made up, not something I actually
> need
> to be done.
> Not that the kate format currently supports well moving regions around in
> realtime anyway, but that's something I'm thinking about currently.

In actual fact, you do not have to fill your logical bitstream with data,
even if you prepare for it by sending a bos packet. So, when live streaming,
we would normally know beforehand what resources we are sending - which sets
up the different logical bitstreams. Then, as we get to the, we can put them
in the stream. I don't really see a problem with this approach.

Cheers,
Silvia.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/ogg-dev/attachments/20080212/3f38c05c/attachment.htm

> In actual fact, you do not have to fill your logical bitstream with data,
> even if you prepare for it by sending a bos packet. So, when live
streaming,
> we would normally know beforehand what resources we are sending - which
sets
> up the different logical bitstreams. Then, as we get to the, we can put
them
> in the stream. I don't really see a problem with this approach.
I'm not sure I understand what you mean here - are you saying that you can
start off as many streams as you want (via a bos packet at chain start), and
then allocate them as you need them (in essence keeping a large pool of
available streams and reusing them, hoping you don't need more than the
pool size) ?
If so, then it is certainly possible, but if not, can you please elaborate ?

On 11-Feb-08, at 2:27 AM, ogg.k.ogg.k@googlemail.com wrote:
> The idea behind the category field was for a player program to  
> automatically
> classify the kate streams as being the "same". eg, if you have 16
> streams,
> in 8 languages, 8 of them having the category "subtitles" and the
> rest having
> the category "director comments", then the program could present
a
> list of
> two available stream types, "subtitles" and "director
comments", in
> addition to
> the language selection.
You followed. And there's nothing wrong with having an indication  
embedded in a particular codec's stream. One can do the same thing  
with the comment headers supported by most of the other codecs we  
have. However, given that this is a special case of a requirement  
that's shared by most stream types, and that we have this skeleton  
stream for global and per-substream interpretation instructions, it  
makes sense to standardize a way of saying category "director  
comments", language "German" there as well. It also makes more
sense
to declare inter-stream relationships like Translation-of or Overlay- 
on at a higher level, so the streams remain self-contained after  
demux. If a Skeleton is not present one could fall back to heuristics  
and similar tags in embedded in the various streams.

  -r