- From: Dave Singer <singer@apple.com>
- Date: Wed, 12 Feb 2003 14:18:41 -0800
- To: Johnb@screen.subtitling.com, lists@wiltgen.net, public-tt@w3.org
> > > 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. On the contrary. Given a document with relative durations, inserting or deleting a segment is easy; everything naturally moves up and down when you do that. If the document uses absolute values, rather than relative, this is painful. One of the simplest uses is a timed-text file with relative durations, displaying (for example) captions, layed into a SMIL presentation in 'par' with the video and in a separate region. This ought to work... I don't disagree that perhaps SMIL needs some concept of how to align time-codes in two 'par' media, but that is a composition question that ought to be addressed in SMIL. -- David Singer Apple Computer/QuickTime
Received on Wednesday, 12 February 2003 17:22:57 UTC