- From: <Johnb@screen.subtitling.com>
- Date: Wed, 12 Feb 2003 10:01:05 -0000
- To: lists@wiltgen.net, public-tt@w3.org
> 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