Re: TT Content Buffering and Timing Scenarios

Glenn A. Adams wrote...

>> (2) Live (created-on-the-fly) timed text can never have XML rules enforced
>> because the entire file doesn't even exist when it starts to be shown.  Live
>> RealText provided me with a lot of challenges in other ways as well.
> 
> Could you describe some of the issues with "live timed text" more fully and
> how it can "never have XML rules enforced"? Are you saying that even
> well-formedness rules aren't possible?

Not by the client when it's streamed, since you have no idea what the rest
of the file looks like.  The server can enforce well-formedness, though,
and anybody using TT for the wire format as well can either send TT
before streaming content (this is similar to a common technique for
QuickTime) or stream well-formed TT chunks in realtime as necessary.

> The RealText *file format* was designed to be independent of delivery method,
> and to be easily packaged for just-in-time delivery.  It's up to a file-format
> handler on the server side to decide how to package and deliver the contents
> of the text based on the delivery environment. The *wire format* I think is
> what we probably don't want to define for TT, but we certainly should think
> about it while designing the *file format*.

This strikes me as a near-perfect summary.  Another way to put it might
be to say that TT is a streamable file format rather than a streaming file
format, since it's going to enable /so much more/ than just sending the TT
file format down the wire.

I assume that contributors should be very familiar with current methods in
order to better steal their best aspects.  Here's what we've got so far:

    MPsub
    http://www.MPlayerHQ.hu/DOCS/documentation.html#mpsub

    QText
    http://www.apple.com/quicktime/tools_tips/tutorials/texttracks.html

    RealText
    http://service.real.com/help/library/guides/realtext/realtext.htm

-- Charles Wiltgen
   <http://playbacktime.com/>

Received on Thursday, 30 January 2003 14:03:27 UTC