Hi again :)<br><br><div class="gmail_quote">On Wed, Feb 20, 2008 at 9:01 PM, <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;"><div class="Ih2E3d">> 1) Font data, as in the actual font itself, doesn't really belong in an ogg<br>
> stream.<br>
<br>
</div>People wanting to have more control on the appearance of an overlay<br>
might want to control the font. Since font naming is largely non standard<br>
(eg, the foundry etc system (you know, *-*-*-* system) is X only I think,<br>
and I think Windows just has filenames), one can't specify a font to use<br>
in a way that you know will work. Provided you'd have the font in the<br>
first place. That's (one of ?) the reason various document types can have<br>
embedded fonts. Yes, it's not ideal, but there's no real other way to do<br>
it that I know of.</blockquote><div><br>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 ;-)<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 2) We have been working on a specification and mechanism for indicating to<br><div class="Ih2E3d">
> clients that there are multiple tracks of the same "kind" (e.g.<br>
> translation), and allowing clients to request individual tracks out of sets<br>
> of like tracks. In fact with HTTP headers like Content-Language we can also<br>
> allow the server to default to a particular translation selection in the<br>
> absence of guidance from the client. At the moment I think a preliminary<br>
> name for this specification is ROE - Silvia is in the process of nailing the<br>
> spec down so you should ask her any questions you have about it :)<br>
> Obviously this doesn't "solve" the duplication issue (if there is one) but<br>
> it does prevent duplicated data eating bandwidth.<br>
<br>
</div>In this case, it's realtime muxing. That's a special case. While it<br>
probably does<br>
help in a lot of situations, it doesn't apply in all cases where one could use<br>
an Ogg stream. It's a great help though.<br>
Besides, when I coded the xine Kate plugin, I've made it so you can switch<br>
languages on the fly. All streams are decoded, but only the selected one<br>
(if any) is actually displayed. This is not possible with such a scheme (not<br>
saying it's deficient, just that it also adds constraints).</blockquote><div><br>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 :)<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><div class="Ih2E3d">
> 3) Text is cheap! Really cheap :) Seriously - compare the amount of space<br>
> in your file taken up by text to that taken up even by audio, let alone<br>
> video.<br>
<br>
</div>Yes, text is cheap, but not fonts. Especially if they have to be burst<br>
transmitted<br>
in headers before playback actually begins. It's also a corner case (custom<br>
font + lots of multiplexed streams). but I'd ideally like to have something that<br>
scales if possible.<br>
Speaking of scaling, one of the issues that I've seen is the large amount of<br>
framing data against codec data. Since I have a packet per page (for timing<br>
reasons), Ogg adds a lot of bytes to mine. But that is another story...<br>
</blockquote></div><br>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).<br>
<br>By the way, how would you deal with fonts if you didn't burst transmit them?! You can hardly decode them as a stream...<br><br>Cheers,<br> -Shane<br>