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

Jean-Claude wrote:

> If a timecode for the start of a movie is 10:00 as I saw in a 
> previous email, I understand that as: this movie shall start at 
> 10:00pm tonight. If I want to play it at another time, I need to do some
retiming.

No - this is not correct. Timecode on a movie (or indeed in a 
GOP of an MPEG file) is **not** the desired play time. 
Often **by convention**, movies are timecoded from 10 hours 
- that is every movie timecoding starts at 10:00. Adverts and 
other inserts are typically timecoded from a different start 
point eg. 1 hour. This helps broadcast engineers detect the 
material type **just** from the timecode (which is often
displayed on the front panel of broadcast 'tape' players).

The timecode doesn't even necessarily reflect the runtime 
of the movie. That is - even if the timecode on a movie video 
recording starts at 10:00, and the movie lasts for 1 hour 
the last timecode on the movie could be 13:00 as
there could be jumps in the timecode track. 
These jumps occur during the editing of a movie (or interuption of
its playback - e.g. newsflash / adverts).

Generally speaking however - after editing a Master Tape will be restriped
so that the timecode is continuous. Any jumps detected by
playout equipment are caused by playback interruptions - this
allows the use of timecoe as a reference to the frame within the master
tape.

The timecode is at best a unique reference to a frame of video 
within the movie.
 
>> 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.


> Does this mean that the 10:00 does not refer to actual wall 
> clock time ?

That's right - timecode is a frame reference (but not a frame number)
 
>> 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).

> It is a lot easier to implement the management of a list of edits, 
> because you can anticipate better than when you are just listening to 
> timecodes and detecting a jump. The jump can be detected only quite 
> "late", whereas the edit list can be sent a long time in advance.

Ahhh... but you **never** get the edit list. That's the problem.
In broadcasting there are many situations where equipment has to 
**follow** the video signal (and the timecode inside it) 
that it is 'sitting' on.

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

> This is a very strong requirement, and it means the edit list 
> *has* to be sent with the movie, either as the time codes, or as a 
> higher level list of segments (of the original, full movie) to play, the 
> time codes being just a discrete way of representing the edit list.

That's it - quite a good way of looking at it in fact - the timecode
is an edit list - but you only see it when the edit is upon you :-)
The timecode is there to allow you to detect an edit.
You will very rarely get broadcast video (inside the broadcast environment)
without timecode, but it is almost always stripped off prior to broadcast, 
since the part of the signal it lives in (VBI or [audio for LTC]) is often
re-used
for something else (Teletext, Closed Captions, or audio etc)

OK purists please note I know I've played fast and loose with frame and
field in here, 
not to mention ignoring frame rate issues etc.

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 12:23:51 UTC