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

Dear John, all,

> A new par-like construct could be designed where the second stream 
> (TT) is locked to the first (video). The video can be stopped, 
> started, rewound, played at variable speed, have ads inserted, etc. 
> The corresponding parts of the TT stream are displayed in sync (cued 
> in and cued out as required).
>
> This could probably be seen as syntactic sugar for "pure" SMIL, but 
> would be much more compact since all the triggering is implicit. 

This behavior very much ressembles to the OCR dependency in MPEG-4.

For those who may not know MPEG-4 very well, let me explain this notion 
a little bit more in details. Within MPEG-4 Systems, you have the Binary 
Format for Scenes (BIFS) which is a binary format to describe the 
spatial and temporal layout of the presentation as well as the media 
that compose the presentation (Audio, Video, 2D/3D Graphics and Text). 
The synchronization is not described within the BIFS description. For 
that purpose, you have the Object Description Framework (ODF) which by 
the means of an Object Descriptor (OD) describes, among other things, 
the synchronisation properties of a media. Hence, in the OD, you can 
specify that the clock reference of a media stream is the clock of 
another stream. Therefore, when the user clicks on the video to start, 
stop or pause it, the other stream is automatically started, stopped or 
paused. In your case, the clock reference of the TT stream is the clock 
of the video stream.

To map this into a SMIL-like notion, I would rather see this notion be 
put in the header section of the document than in a par element.
Since a stream can depend only on one clock, you don't want to 
manipulate this at the par element level but instead declare it once for 
the whole presentation (document).

Best Regards,

Cyril Concolato

-- 
Ecole Nationale Supérieure des Télécommunications, Paris
Dept. Comelec
46, rue Barrault 75013 Paris                
Tel: +33145817991    Fax: +33145804036

Received on Tuesday, 18 February 2003 08:18:04 UTC