<br><br><div class="gmail_quote">On Thu, Feb 21, 2008 at 9:00 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">> If you have an application-specific need for exact font data, then I think<br>
> the mechanism for retrieving this data should lie in your application, and<br>
> not in the media format that you're using for media data. I would have said<br>
> the same thing to Adobe if they'd asked me ;-)<br>
<br>
</div>We may or may not be talking about the same specific thing. My point was<br>
not that there should be a shared font codec or similar, but that it might be<br>
useful to consider a way to supply arbitrary data to multiplexed streams, each<br>
codec then interpreting this data as it sees fit (possibly ignoring it). Now, I<br>
kind agree with your points too.<br>
<div class="Ih2E3d"></div></blockquote><div><br>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.<br>
<br>Of course you could always stuff your up-front data into the vorbis comment packet...<br> </div><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"><br>
> Realtime vs. prerolled do not present problems here. ROE is agnostic as to<br>
> whether the media data is generated on the fly or stored on disk - it merely<br>
> needs a handle on the data. Furthermore, with Annodex and ROE we will<br>
> absolutely be able to switch tracks on the fly - that's part of the point of<br>
> time-based URI values. Furthermore we can do so without the overhead of<br>
> transmitting and decoding multiple (text / audio / video / whatever) tracks<br>
> at a time. This is not a special case that we haven't considered :)<br>
<br>
</div>If you do that, it implies that you have to modify the stream at runtime (eg, as<br>
the vorbis streamers do - cache the headers, and send them at startup. To be<br>
generic, you also have to resend any data pages needed for correct<br>
interpretation<br>
of the stream (eg, whatever since the backlink).<br>
If you do that, fine, but it's extra work that's outwith the scope of<br>
the codec (eg,<br>
it needs extra code to do this). And it's generic, so shouldn't really<br>
have anything<br>
to depend on Annodex and/or ROE.<br>
<div class="Ih2E3d"></div></blockquote><div><br>Modify which stream? Also, this is very much building on the capabilities and properties of Ogg and Annodex.<br><br>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).<br>
</div><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"><br>
> Fonts are not cheap. That's true. Again, though, I think that a<br>
> font-retrieval mechanism is outside the scope of Ogg, and should be dealt<br>
> with in an application-specific way (we would all obviously prefer a<br>
<br>
</div>Yes, I agree with this, the font thing was just an example.<br>
<div class="Ih2E3d"><br>
> By the way, how would you deal with fonts if you didn't burst transmit<br>
> them?! You can hardly decode them as a stream...<br>
<br>
</div>I didn't have any particular method in mind, just didn't want to assume burst<br>
transmitting was the only option. Thinking about this now, you could send each<br>
character as it is used, keeping track of what characters are already sent.<br>
No claim that it's a clever thing to do though :)<br>
</blockquote></div><br><br>Clever: yes. Sensible: probably not :)<br><br>Cheers,<br> -Shane<br>