[ogg-dev] Skeletal relations

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

> If you have an application-specific need for exact font data, then I think
> the mechanism for retrieving this data should lie in your application, and
> not in the media format that you're using for media data. I would have said
> the same thing to Adobe if they'd asked me ;-)

We may or may not be talking about the same specific thing. My point was
not that there should be a shared font codec or similar, but that it might be
useful to consider a way to supply arbitrary data to multiplexed streams, each
codec then interpreting this data as it sees fit (possibly ignoring it). Now, I
kind agree with your points too.

> Realtime vs. prerolled do not present problems here. ROE is agnostic as to
> whether the media data is generated on the fly or stored on disk - it merely
> needs a handle on the data. Furthermore, with Annodex and ROE we will
> absolutely be able to switch tracks on the fly - that's part of the point of
> time-based URI values. Furthermore we can do so without the overhead of
> transmitting and decoding multiple (text / audio / video / whatever) tracks
> at a time. This is not a special case that we haven't considered :)

If you do that, it implies that you have to modify the stream at runtime (eg, as
the vorbis streamers do - cache the headers, and send them at startup. To be
generic, you also have to resend any data pages needed for correct
interpretation
of the stream (eg, whatever since the backlink).
If you do that, fine, but it's extra work that's outwith the scope of
the codec (eg,
it needs extra code to do this). And it's generic, so shouldn't really
have anything
to depend on Annodex and/or ROE.

> Fonts are not cheap. That's true. Again, though, I think that a
> font-retrieval mechanism is outside the scope of Ogg, and should be dealt
> with in an application-specific way (we would all obviously prefer a

Yes, I agree with this, the font thing was just an example.

> By the way, how would you deal with fonts if you didn't burst transmit
> them?! You can hardly decode them as a stream...

I didn't have any particular method in mind, just didn't want to assume burst
transmitting was the only option. Thinking about this now, you could send each
character as it is used, keeping track of what characters are already sent.
No claim that it's a clever thing to do though :)