[ogg-dev] Skeletal relations

[Shane Stephens]

Hi,

A couple of points:

1) Font data, as in the actual font itself, doesn't really belong in an ogg
stream.  Given that it truly is "global" data in the sense that your fonts
are shared by more than just a single ogg file, then the font should be
separate from the stream and just referenced using an appropriate font
naming scheme.  If you meant font references in the first place, well those
are small, and won't gobble much bandwidth at all.

2) We have been working on a specification and mechanism for indicating to
clients that there are multiple tracks of the same "kind" (e.g.
translation), and allowing clients to request individual tracks out of sets
of like tracks.  In fact with HTTP headers like Content-Language we can also
allow the server to default to a particular translation selection in the
absence of guidance from the client.  At the moment I think a preliminary
name for this specification is ROE - Silvia is in the process of nailing the
spec down so you should ask her any questions you have about it :)
Obviously this doesn't "solve" the duplication issue (if there is one) but
it does prevent duplicated data eating bandwidth.

3) Text is cheap!  Really cheap :)  Seriously - compare the amount of space
in your file taken up by text to that taken up even by audio, let alone
video.

Cheers,
    -Shane

On Feb 20, 2008 1:18 AM, ogg.k.ogg.k at googlemail.com <
ogg.k.ogg.k at googlemail.com> wrote:

> Something which you might also want to consider, unless it is deemed
> to be outside the scope of skeleton, is a way to embed data that can be
> referred to by other logical streams, as a means to avoid duplication.
>
> A logical stream is self contained as far as the data it handles goes, but
> several multiplexed streams might need the same, or similar, data.
>
> For instance, something I wanted to do was having several multiplexed
> Kate streams being able to use a shared font. This is currently not
> possible
> without duplicating the font data in each separate logical Kate stream,
> leading to waste of bandwidth. Since such "global" data needs to be in
> the headers (well, it doesn't *need* to be, but it's cleaner that way), it
> also
> means a large burst of data when one starts a stream.
>
> Also consider that text translations might mean dozens of multiplexed
> logical streams, something which isn't likely to occur with, say, Vorbis
> and Theora, where you usually get a few streams together. Duplication
> in this case becomes more of an issue.
>
> Back when I still thought CMML was about meta description of accompanying
> streams, I'd actually thought of CMML carrying such shared data to be
> delivered at the time it was needed, but that was quite "wouldn't it be
> nice"
> territory. If such shared data is kept in headers, Skeleton becomes a
> better
> fit for this payload.
> _______________________________________________
> ogg-dev mailing list
> ogg-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/ogg-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/ogg-dev/attachments/20080220/b74087f7/attachment.htm