Hi,<br><br>A couple of points:<br><br>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.<br>
<br>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.<br>
<br>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.<br><br>Cheers,<br> -Shane<br><br><div class="gmail_quote">On Feb 20, 2008 1:18 AM, <a href="mailto:ogg.k.ogg.k@googlemail.com">ogg.k.ogg.k@googlemail.com</a> <<a href="mailto:ogg.k.ogg.k@googlemail.com">ogg.k.ogg.k@googlemail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Something which you might also want to consider, unless it is deemed<br>to be outside the scope of skeleton, is a way to embed data that can be<br>
referred to by other logical streams, as a means to avoid duplication.<br><br>A logical stream is self contained as far as the data it handles goes, but<br>several multiplexed streams might need the same, or similar, data.<br>
<br>For instance, something I wanted to do was having several multiplexed<br>Kate streams being able to use a shared font. This is currently not possible<br>without duplicating the font data in each separate logical Kate stream,<br>
leading to waste of bandwidth. Since such "global" data needs to be in<br>the headers (well, it doesn't *need* to be, but it's cleaner that way), it also<br>means a large burst of data when one starts a stream.<br>
<br>Also consider that text translations might mean dozens of multiplexed<br>logical streams, something which isn't likely to occur with, say, Vorbis<br>and Theora, where you usually get a few streams together. Duplication<br>
in this case becomes more of an issue.<br><br>Back when I still thought CMML was about meta description of accompanying<br>streams, I'd actually thought of CMML carrying such shared data to be<br>delivered at the time it was needed, but that was quite "wouldn't it be nice"<br>
territory. If such shared data is kept in headers, Skeleton becomes a better<br>fit for this payload.<br>_______________________________________________<br>ogg-dev mailing list<br><a href="mailto:ogg-dev@xiph.org">ogg-dev@xiph.org</a><br>
<a href="http://lists.xiph.org/mailman/listinfo/ogg-dev" target="_blank">http://lists.xiph.org/mailman/listinfo/ogg-dev</a><br></blockquote></div><br>