SMIL 3.0 Timing and Synchronization
Translations of this material:
- into Russian: Перевод "SMIL 3.0 Timing and Synchronization". Translation is not started yet.
-
Submitted for translation by damirmanapov 10.04.2010
Text
5.1 Overview and Summary of Changes for SMIL 3.0
This section is informative.
The SMIL 3.0 specification leaves the basic syntax and semantics of the SMIL 2.1 timing model unchanged [SMIL21-timing]. The only change for SMIL 3.0 are that the four DOM method calls which were reserved in SMIL 2.1 have now been defined. A new module, DOMTimingMethods, was added which contains these DOM methods.
In addition to these changes, various typos were corrected and some clarifications were added.
5.2 Introduction
This section is informative
SMIL 1.0 solved fundamental media synchronization problems and defined a powerful way of choreographing multimedia content. SMIL 2.0 extends the timing and synchronization support, adding capabilities to the timing model and associated syntax. SMIL 3.0 adds Document Object Model support. Some SMIL 1.0 syntax has been changed or deprecated. This section of the document specifies the Timing and Synchronization module.
There are two intended audiences for this module: implementers of SMIL 3.0 document viewers or authoring tools, and authors of other XML languages who wish to integrate timing and synchronization support. A language with which this module is integrated is referred to as a host language. A document containing SMIL Timing and Synchronization elements and attributes is referred to as a host document.
As this module is used in different profiles (i.e. host languages), the associated syntax requirements may vary. Differences in syntax should be minimized as much as is practical.
SMIL 3.0 Timing and Synchronization support is broken down into 17 modules, allowing broad flexibility for language designers integrating this functionality. These modules are described in Appendix A: SMIL Timing and Synchronization modules.
5.3 Overview of SMIL timing
This section is informative
SMIL Timing defines elements and attributes to coordinate and synchronize the presentation of media over time. The term media covers a broad range, including discrete media types such as still images, text, and vector graphics, as well as continuous media types that are intrinsically time-based, such as video, audio and animation.
Three synchronization elements support common timing use-cases:
The <seq> element plays the child elements one after another in a sequence.
The <excl> element plays one child at a time, but does not impose any order.
The <par> element plays child elements as a group (allowing «parallel» playback).
These elements are referred to as time containers. They group their contained children together into coordinated timelines.
SMIL Timing also provides attributes that may be used to specify an element’s timing behavior. Elements have a begin, and a simple duration. The begin may be specified in various ways — for example, an element may begin at a given time, or based upon when another element begins, or when some event (such as a mouse click) happens. The simple duration defines the basic presentation duration of an element. Elements may be defined to repeat the simple duration, a number of times or for an amount of time. The simple duration and any effects of repeat are combined to define the active duration. When an element’s active duration has ended, the element may either be removed from the presentation or frozen (held in its final state), e.g. to fill any gaps in the presentation.
An element becomes active when it begins its active duration, and becomes inactive when it ends its active duration. Within the active duration, the element is active, and outside the active duration, the element is inactive.
Figure 1 illustrates the basic support of a repeating element within a simple <par> time container. The corresponding syntax is included with the diagram.
<par begin="0s" dur="33s">
<video begin="1s" dur="10s" repeatCount="2.5" fill="freeze" .../>
</par>
Figure 1 — Strip diagram of basic timing support. The starred «Simple*» duration indicates that the simple duration is partial (i.e. it is cut off early).
The attributes that control these aspects of timing may be applied not only to media elements, but to the time containers as well. This allows, for example, an entire sequence to be repeated, and to be coordinated as a unit with other media and time containers. While authors may specify a particular simple duration for a time container, it is often easier to leave the duration unspecified, in which case the simple duration is defined by the contained child elements. When an element does not specify a simple duration, the time model defines an implicit simple duration for the element. For example, the implicit simple duration of a sequence is based upon the sum of the active durations of all the children.
Each time container also imposes certain defaults and constraints upon the contained children. For example in a <seq>, elements begin by default right after the previous element ends, and in all time containers, the active duration of child elements is constrained not to extend past the end of the time container’s simple duration. Figure 2 illustrates the effects of a repeating <par> time container as it constrains a <video> child element.
<par begin="0s" dur="12s" repeatDur="33s" fill="freeze" >
<video begin="1s" dur="5s" repeatCount="1.8" fill="freeze" .../>
</par>
Figure 2 — Strip diagram of time container constraints upon child elements. The starred «Simple*» durations indicate that the simple duration is partial (i.e. it is cut off early).
The SMIL Timing Model defines how the time container elements and timing attributes are interpreted to construct a time graph. The time graph is a model of the presentation schedule and synchronization relationships. The time graph is a dynamic structure, changing to reflect the effect of user events, media delivery, and DOM control of the presentation. At any given instant, the time graph models the document at that instant, and the semantics described in this module. However, as user events or other factors cause changes to elements, the semantic rules are re-evaluated to yield an updated time graph.
When a begin or end value refers to an event, or to the begin or active end of another element, it may not be possible to calculate the time value. For example, if an element is defined to begin on some event, the begin time will not be known until the event happens. Begin and end values like this are described as unresolved. When such a time becomes known (i.e. when it can be calculated as a presentation time), the time is said to be resolved. A resolved time is said to be definite if it is not the value «indefinite». See also the discussion of Unifying scheduled and interactive timing.
In an ideal environment, the presentation would perform precisely as specified. However, various real-world limitations (such as network delays) may influence the actual playback of media. How the presentation application adapts and manages the presentation in response to media playback problems is termed runtime synchronization behavior. SMIL includes attributes that allow the author to control the runtime synchronization behavior for a presentation.
5.4 Language definition
This section is normative
5.4.1 Changes for SMIL 3.0
This section is informative
This section remains largely unchanged for SMIL 3.0 except for the relaxation of the restrictions on the begin attributes of children of a seq time container. Also, a number of examples have been added.
5.4.2 Overview
This section is informative
The timing model is defined by building up from the simplest to the most complex concepts: first the basic timing and simple duration controls, followed by the attributes that control repeating and constraining the active duration. Finally, the elements that define time containers are presented.
The time model depends upon several definitions for the host document: A host document is presented over a certain time interval.
5.4.3 Attributes
This section defines the set of timing attributes that are common to all of the SMIL synchronization elements.
Unless otherwise specified below, if there is any error in the argument value syntax for an attribute, the attribute will be ignored (as though it were not specified).
The begin and dur attributes: basic timing support
This section is informative
The basic timing for an element is described using the begin and dur attributes. Authors may specify the begin time of an element in a variety of ways, ranging from simple clock times to the time that an event (e.g. a mouse click) happens. The simple duration of an element is specified as a simple time value. The begin attribute syntax is described below.
The normative syntax rules for each attribute value variant are described in Timing attribute value grammars; an attribute value syntax summary is provided here as an aid to the reader.
begin : SMIL-1-syncbase-value | Begin-value-list
Defines when the element becomes active.
The attribute value is either a SMIL 1.0 syncbase declaration, or a semi-colon separated list of values.
SMIL-1-syncbase-value
Deprecated. Describes a syncbase and an offset from that syncbase. The element begin is defined relative to the begin or active end of another element.
Begin-value-list : Begin-value («;» Begin-value-list )?
A semi-colon separated list of begin values. The interpretation of a list of begin times is detailed in the section Evaluation of begin and end time lists.
Begin-value : ( Offset-value | Syncbase-value | Event-value | Repeat-value | Accesskey-value | Media-Marker-value | Wallclock-sync-value | «indefinite» )
Describes the element begin.
Offset-value
Describes the element begin as an offset from an implicit syncbase. The definition of the implicit syncbase depends upon the element’s parent time container. The offset is measured in parent simple time.
Syncbase-value
Describes a syncbase and an offset from that syncbase. The element begin is defined relative to the begin or active end of another element.
Event-value
Describes an event and an optional offset that determine the element begin. The element begin is defined relative to the time that the event is raised. Events may be any event defined for the host language in accordance with [DOM2Events]. These may include user-interface events, event-triggers transmitted via a network, etc. Details of event-based timing are described in the section below on Unifying Event-based and Scheduled Timing.
Repeat-value
Describes a qualified repeat event. The element begin is defined relative to the time that the repeat event is raised with the specified Iteration value.
Accesskey-value
Describes an accesskey that determines the element begin. The element begin is defined relative to the time that the accesskey character is input by the user.
Media-Marker-value
Describes the element begin as a named marker time defined by a media element.
Wallclock-sync-value
Describes the element begin as a real-world clock time. The wallclock time syntax is based upon syntax defined in [ISO8601].
«indefinite»
The begin of the element will be determined by a «beginElement()» method call or a hyperlink targeted to the element.
The SMIL Timing and Synchronization DOM methods are described in the DOMTimingMethods section.
Hyperlink-based timing is described in the Hyperlinks and timing section.
Begin value semantics
Children of a seq can only specify a non-negative offset value for begin.
If no begin is specified, the default timing is dependent upon the time container.
If there is a syntax error in any individual value in the list of begin or end values (i.e. the value does not conform to the defined syntax for any of the time values), the host language must specify how the user agent deals with this.
A time value may conform to the defined syntax but still be invalid (e.g. if an unknown element is referenced by ID in a syncbase value). If there is such an evaluation error in an individual value in the list of begin or end values, the individual value will be will be treated as though «indefinite» were specified, and the rest of the list will be processed normally. If no legal value is specified for a begin or end attribute, the element assumes an «indefinite» begin or end time (respectively).
The deprecated SMIL-1-syncbase-values are semantically equivalent to the following SMIL 3.0 Begin-value types:
id(Id-value)(begin) is equivalent to Id-value.begin
id(Id-value)(end) is equivalent to Id-value.end
id(Id-value)(Clock-value) is equivalent to Id-value.begin+ Clock-value
This section is informative
Children of a par begin by default when the par begins (equivalent to begin="0s"). Children of a seq begin by default when the previous child ends its active duration (equivalent to begin="0s«); the first child begins by default when the parent seq begins. Children of an excl default to a begin value of «indefinite».
The begin value may specify a list of times. This can be used to specify multiple «ways» or «rules» to begin an element, e.g. if any one of several events is raised. A list of times may also define multiple begin times, allowing the element to play more than once (this behavior can be controlled, e.g. to only allow the earliest begin to actually be used — see also the restart attribute).
In general, the earliest time in the list determines the begin time of the element. There are additional constraints upon the evaluation of the begin time list, detailed in Evaluation of begin and end time lists.
Note that while it is legal to include «indefinite» in a list of values for begin, «indefinite» is only really useful as a single value. Combining it with other values does not impact begin timing, as DOM begin methods may be called with or without specifying «indefinite» for begin.
When a begin time is specified as a syncbase variant, a marker value or a wallclock value, the defined time must be converted by the implementation to a time that is relative to the parent time container (i.e. to the equivalent of an offset value). This is known as timespace conversion, and is detailed in the section Converting between local and global times.
Handling negative offsets for begin
For children of <par> and <excl> time containers, the computed offset relative to the parent begin time may be negative.
A begin time may be specified with a negative offset relative to an event or to a syncbase that is not initially resolved. When the syncbase or eventbase time is resolved, the computed time may be in the past.
The computed begin time defines the scheduled synchronization relationship of the element, even if it is not possible to begin the element at the computed time. The time model uses the computed begin time, and not the observed time of the element begin.
This section is informative
The use of negative offsets to define begin times merely defines the synchronization relationship of the element. It does not in any way override the time container constraints upon the element, and it cannot override the constraints of presentation time.
If an element has a begin time that resolves to a time before the parent time container begins, the parent time container constraint still applies. For example:
<par>
