[ogg-dev] Skeletal relations

[Shane Stephens]

On Thu, Feb 21, 2008 at 9:00 PM, ogg.k.ogg.k at googlemail.com <
ogg.k.ogg.k at googlemail.com> wrote:

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

I guess I'm a little concerned about putting arbitrary data in Ogg, period.
My point was that regardless of codec or name resolution technology used,
font downloading (like downloading of any other non-media-related data)
should be done out-of-band.

Of course you could always stuff your up-front data into the vorbis comment
packet...


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

Modify which stream?  Also, this is very much building on the capabilities
and properties of Ogg and Annodex.

Assume we have a set of resources {A,B,C,D,E} on disk, in an ogg file.  A
ROE-capable player requests an initial subset {A,C,E} from a ROE-enabled
player, using one of a number of mechanisms.  The server streams just A, C
and E to the player (and here we have Ogg-specific requirement #1: we need
to be able to extract subsets of streams from a multiplexed stream, quickly
and with minimal server effort.  Ogg allows this, some other codecs
don't.).  At some time T, the player decides to switch {C -> D}.  The player
makes a request to the server using a ROE/Annodex URI for {A,D,E} with time
offset T, and stops playing {A,C,E}.  Here of course we have the second
Ogg-specific requirement - at this stage no-one else supports URIs with time
offsets.  By using these, we've avoided modification of the original file on
disk, avoided vorbis-streamer-style special chained streams, and the only
extension required to mod-annodex is selection of a subset of streams (this
is something we were planning on adding anyway).


>
> > 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 :)
>


Clever: yes.  Sensible: probably not :)

Cheers,
    -Shane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/ogg-dev/attachments/20080221/331fded0/attachment-0001.htm