W3C home > Mailing lists > Public > public-tt@w3.org > January 2003

RE: TT Content Buffering and Timing Scenarios

From: Erik Hodge <ehodge@real.com>
Date: Thu, 30 Jan 2003 10:10:17 -0800
Message-Id: <5.1.0.14.2.20030130095041.031cb930@mail.real.com>
To: "Glenn A. Adams" <glenn@xfsi.com>, "W3C TT Public" <public-tt@w3.org>

At 08:22 PM 1/29/2003 -0500, Glenn A. Adams wrote:


>I should have added the following:
>
>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.

RealText was conceived in late 1996 precisely for streaming of long-
format text.  Its predominant use, however, is just to add short,
non-changing text to presentations, e.g., a title, a caption, or a
seekable table of contents.  But, I've seen a 4 Megabyte RealText
file streamed along with a 6-hour video presentation.

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*.

So, to be "streamable", a file format should be designed so that:
(a) the file handler (reader, parser, packager) on a server (or on
the client if HTTP or local-file) doesn't have to read/parse/store
the entire file in order to determine what needs to be sent at any
given time.
(b) the file handler can easily handle a seek request to any given
time in the stream with a minimal use of server-side resources.

The implications of this include:
(1) An XML (assuming we choose that) file can't be validated without
reading/parsing the entire file.  Therefore, the file has to already
be assured to be valid, well-formed XML before an attempt to stream
it is made.  RealText just does its best when confronted with XML
errors without throwing an error and/or stopping the presentation.
(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.

         - Erik



>G.
Received on Thursday, 30 January 2003 13:03:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 2 November 2009 22:41:25 GMT