[ogg-dev] Ogg/Kate preliminary documentation

[ogg.k.ogg.k at googlemail.com]

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