RE: Why use time as a unit of measurement? (was: Proposal 0.0)

> You can forget about SMIL, although I think that understanding what it is
> a useful prerequisite for anyone who wants to contribute.

From the charter:
"The mission of the Timed Text Working Group (TTWG) is to develop an XML
based format used for the representation of streamable text synchronized
with some other timed media, like audio and video. A typical application is
real time captioning of movies on the Web (e.g. integrated in SMIL)."

Also from the charter:
"The Working Group coordinates with this group (Synchronised Multimedia
Interest Group) to ensure that Timed Text meets the requirements of timing
and integration in interactive multimedia presentations. SMIL is a building
block for Timed Text."

This does concern me however - since I do not believe SMIL is really
suitable as a basis for TT. I certainly can't see how to apply SMIL to what
I do - and I would consider my professional area to be a target for TT.
This is probably my lack of understanding of SMIL - but my current
perception of SMIL is that it was defined starting from the presentation
viewpoint and working backwards towards authoring. I feel TT should be a
much more agnostic format - that in a simple way (and SMIL is not simple),
defines a format for carrying text, timing and style information.

> Unless I'm missing something, Proposal 0.0 works just the way you would
like
> -- subtitles in one file, video and audio in another.

Unless I'm missing something, SMIL does not support **external**
synchronisation except through the event mechanism. In broadcast subtitling
- the player of the timed text is not in control of the playout of the other
media types (I.e. the player of the timed text has to follow the other
external media). AFAIK, SMIL assumes a player that co-ordinates all media
activities.

> > Subtitles are frame accurate for lip synching.
 
> I've explained a few times why time (rather than frame-based timecode)
> must be used.  As two examples, the TT should still work when taking a
> 24fps film source to NTSC, or to the web via a QuickTime movie with a
> default timebase of 600 units/second whose video content is encoded at
> 12fps.
 
> > I can conceive of other situations where the assumption of 1 sec per sec
is invalid.

> I know you're not serious, but I don't get the joke.

Well it wasn't exactly a joke. The point was that if you use a duration
based mechanism, and you wish to support slow play or reverse play (or
random access), then you invoke a large number of conversions from the
duration based representation into an absolute time representation. If you
start with an absolute time representation - then all that is necessary for
reverse play or slow play is to alter the rate (or value) of your (internal)
clock. Duration based mechanisms buy you nothing - and cost you lots.

> > ...timebases can always be converted into a single format.
> Exactly, and that single format is time.

Indeed, I don't think I have advocated otherwise :-) certainly not intended
to. But playback of timed text must support an event based, random access,
discontinuous style, as well as a linear 'watch a movie' style. This IMHO is
better achieved using absolute representations of time rather than durations
and relative to start timings.

regards 
John Birch

The views and opinions expressed are the author's own and do not necessarily
reflect the views and opinions of Screen Subtitling Systems Limited.

Received on Wednesday, 12 February 2003 05:03:52 UTC