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@googlemail.com <
ogg.k.ogg.k@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@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
> 1) Font data, as in the actual font itself, doesn't really belong in an ogg > stream.People wanting to have more control on the appearance of an overlay might want to control the font. Since font naming is largely non standard (eg, the foundry etc system (you know, *-*-*-* system) is X only I think, and I think Windows just has filenames), one can't specify a font to use in a way that you know will work. Provided you'd have the font in the first place. That's (one of ?) the reason various document types can have embedded fonts. Yes, it's not ideal, but there's no real other way to do it that I know of.> 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.In this case, it's realtime muxing. That's a special case. While it probably does help in a lot of situations, it doesn't apply in all cases where one could use an Ogg stream. It's a great help though. Besides, when I coded the xine Kate plugin, I've made it so you can switch languages on the fly. All streams are decoded, but only the selected one (if any) is actually displayed. This is not possible with such a scheme (not saying it's deficient, just that it also adds constraints).> 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.Yes, text is cheap, but not fonts. Especially if they have to be burst transmitted in headers before playback actually begins. It's also a corner case (custom font + lots of multiplexed streams). but I'd ideally like to have something that scales if possible. Speaking of scaling, one of the issues that I've seen is the large amount of framing data against codec data. Since I have a packet per page (for timing reasons), Ogg adds a lot of bytes to mine. But that is another story...
On 20/02/2008, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote:> > 1) Font data, as in the actual font itself, doesn't really belong in an ogg > > stream. > > > People wanting to have more control on the appearance of an overlay > might want to control the font. Since font naming is largely non standard > (eg, the foundry etc system (you know, *-*-*-* system) is X only I think, > and I think Windows just has filenames), one can't specify a font to use > in a way that you know will work. Provided you'd have the font in the > first place. That's (one of ?) the reason various document types can have > embedded fonts. Yes, it's not ideal, but there's no real other way to do > it that I know of. > >I think the naming thing is a bit of a red-herring; css manages okay, I believe the capability for embedded fonts would be useful. but most of the time you probably just want to use a standard one from the system. -- imalone
Hi again :) On Wed, Feb 20, 2008 at 9:01 PM, ogg.k.ogg.k@googlemail.com < ogg.k.ogg.k@googlemail.com> wrote:> > 1) Font data, as in the actual font itself, doesn't really belong in an > ogg > > stream. > > People wanting to have more control on the appearance of an overlay > might want to control the font. Since font naming is largely non standard > (eg, the foundry etc system (you know, *-*-*-* system) is X only I think, > and I think Windows just has filenames), one can't specify a font to use > in a way that you know will work. Provided you'd have the font in the > first place. That's (one of ?) the reason various document types can have > embedded fonts. Yes, it's not ideal, but there's no real other way to do > it that I know of.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 ;-)> > 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. > > In this case, it's realtime muxing. That's a special case. While it > probably does > help in a lot of situations, it doesn't apply in all cases where one could > use > an Ogg stream. It's a great help though. > Besides, when I coded the xine Kate plugin, I've made it so you can switch > languages on the fly. All streams are decoded, but only the selected one > (if any) is actually displayed. This is not possible with such a scheme > (not > saying it's deficient, just that it also adds constraints).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 :)> > > 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. > > Yes, text is cheap, but not fonts. Especially if they have to be burst > transmitted > in headers before playback actually begins. It's also a corner case > (custom > font + lots of multiplexed streams). but I'd ideally like to have > something that > scales if possible. > Speaking of scaling, one of the issues that I've seen is the large amount > of > framing data against codec data. Since I have a packet per page (for > timing > reasons), Ogg adds a lot of bytes to mine. But that is another story... >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 consistent font naming scheme over all operating systems, but that's not going to happen). By the way, how would you deal with fonts if you didn't burst transmit them?! You can hardly decode them as a stream... Cheers, -Shane -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/ogg-dev/attachments/20080221/b99a0f28/attachment.htm