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

Jean-Claude, 

you wrote:
> Just as the absolute time code seems horrible to us (PC 
> people) because it seems like you have to change the 
> timecodes everytime you play the movie.

Please explain why you see the timecodes as needing to change? 

I see a major difference between PC media playback and TV playback
in that in PCs the presentation may run slower than real time
if problems occur, whereas in TV it 'drops'. 
That is - in broadcast you can never get behind (wrt to the timecode).

This is also true for any live performance.
For example, at a conference the speaker is not going to slow 
down if there is a network delay in pushing the TT to the 
delegates console. The TT needs to follow the speaker.

The timecodes within slaved synchronised streams do not need to change 
- they are semantically equivalent to mediaMarkers. The problem 
with mediaMarking is that it is too verbose and an extra 
level of indirection above what is IMHO required.

If parts of a stream use absolute times that reference a
defined (within the stream) synchronisation master, what has to change?
The stream players (if you assume that each stream is played by a 
different component e.g. audio, video, text..) need to be
kept in sync to the defined syncMaster reference, rather than just told of
starts and stops.

The syncBase, syncMaster markup **may** allow this.

I see no implementation difference between synchronising streams 
against an arbitrary internal page clock (which is what I perceive 
as the current situation in SMIL) and synchronising streams with 
an explicitly provided external referenced clock (or a discontinuous 
clock extracted from another stream - see note below).

Note - the timecode could also come from a component within the stream.
MPEG2 allows for timecode to be included in the GOP header. It should
be possible to define this timecode as the syncMaster.

What **may** be required in SMIL is the ability to define 
in the markup the offset of the timecode from the 
internal page clock. So you can say that syncMaster timecode 
10.00.00:000 is equal to begin 0. 
A further implication is then that if the timecode
**jumps** from 10.10.00:000 to 10.11.00.000 
then the internal page clock jumps formward 
from begin 10 minutes to begin 11 minutes (i.e. A seek forward occurs).

This then preserves the use of relative to start markup - whilst still
allowing timecode accuracy.

> OK, this means another requirement:
> the TT stream maybe sent separately from the rest, even if it has to 
> stay ABSOLUTELY synchronized, whatever editing is done on the rest of 
> the movie

For TT to be more universally accepted, I feel it is
essential for this requirement to be met.

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 Friday, 21 February 2003 10:30:35 UTC