RE: TT Content Buffering and Timing Scenarios

See inline.

> -----Original Message-----
> From: Charles Wiltgen [mailto:lists@wiltgen.net] 
> Sent: Wednesday, January 29, 2003 11:34 PM
> To: W3C TT Public
> Subject: Re: TT Content Buffering and Timing Scenarios
> 
> 
> 
> Glenn A. Adams wrote...
> 
> > Well, I hope this will spark a useful discussion, at least 
> one that I can
> > learn from.
> 
> Normally I like to lurk on new lists, but since nobody's 
> chimed in yet (why,
> it's been over three hours!)...   :^)
> 
> > In using RealText and QuickText as (potential) examples of 
> non-streaming
> > TT content, I did not mean to imply that they were only 
> non-streaming; I
> > believe (but am not completely certain) that they also may 
> be delivered
> > in streaming mode; perhaps someone can confirm this for me.
> 
> I know that QuickTime supports this.

Thanks for confirming.
 
> > Given that we are committed to defining an XML based syntax 
> for TT, how
> > should we deal with the need to stream TT content?
> 
> My main experience with this is related to EventStream, an XML-based
> language we created for Cleaner 5 that allows content authors 
> to define
> timed text, buttons, timed URL triggers, etc. in a 
> format-agnostic fashion.
> 
> EventStream text was encoded very differently depending on 
> the destination
> format (QuickTime, RealSystem, Windows Media), and streamed 
> very differently
> as well depending on the format and the protocol (HTTP, RTSP, 
> MMS) used.

I think you must mean RTP, not RTSP, correct? Since RTSP is just
a command/control protocol.
 
> I guess what I'm asking is, does this group need to define how TT is
> streamed using all potential standards-based and proprietary 
> protocols and
> distribution formats?  That would be a challenge (he said 
> understatedly),
> and doesn't intuitively strike me as the place that a TT standard adds
> value.

Of course we can't define all possible distribution formats;
however, our charter does explicitly charge us to "develop an XML
based format used for the representation of streamable text
synchronized with some other timed media". So we need to address
this at some level. It may be that we simply indicate, by example,
how "one may stream" the format, without actually specifying the
streaming format itself. But, in designing the representation, this
has obvious implications on how information is organized. For example
this would preclude us from designing in some constraint that
requires parsing the entire content of the stream in order to
effectively interpret and use some well-defined portion of the
stream (call this an "access unit").


Regards,
Glenn

Received on Thursday, 30 January 2003 04:16:55 UTC