This is a working draft specification of timing and synchronization functionality for SMIL and other XML documents that incorporate SMIL Timing and Synchronization. It is part of the work in the Synchronized Multimedia Working Group (SYMM) towards a next version of the SMIL language (SMIL Boston) and associated modules. This version extends the Timing and Synchronization support available in the SMIL 1.0 specification.
SMIL 1.0 solved fundamental media synchronization problems and defined a powerful way of choreographing multimedia content. SMIL Boston extends the timing and synchronization support, adding capabilities to the timing model and associated syntax. This section of the document specifies the Timing and Synchronization module.
There are two intended audiences for this module: implementers of SMIL Boston document viewers or authoring tools, and authors of other XML languages who wish to integrate timing and synchronization support.
In the process of extending SMIL 1.0 for modularization and use in other XML languages, some alternate syntaxes have been defined. If a document would otherwise be SMIL 1.0 compatible except for use of alternate syntax, the use of the SMIL 1.0 syntax is recommended so the document will be playable by SMIL 1.0 as well as later document players.
As this module is used in different profiles, the associated syntax requirements may vary. Differences in syntax should be minimized as much as is practical. The semantics of the timing model and of the associated markup must remain consistent across all profiles. Any document type that includes SMIL Boston Timing and Synchronization markup (either via a hybrid DTD or via namespace qualified extensions) must preserve the semantics of the model defined in this specification.
The specification of timing and synchronization is organized in the following way. Time model concepts are introduced first, followed by a normative description of the time model and time graph construction. Clarification is provided for aspects of the model that were insufficiently documented in SMIL 1.0. The associated SMIL-DOM interfaces are described next. Open issues and examples are separated into appendices for readability purposes.
There are several important terms and concepts that must be introduced to
describe the time model. This section first describes general terms and then
defines basic timing concepts used throughout the document. This section
ends with a discussion of how the SMIL timing model is being extended to
support not only scheduled but also interactive presentations.
Note that certain areas of the model are still under discussion. A future draft will more precisely define the complete model, and interactions among the new functionality.
The following concepts are the basic terms used to describe the timing model.
A time graph is used to represent the temporal relations of elements in a document with SMIL timing. Nodes of the time graph represent elements in the document. Parent nodes can "contain" children, and children have a single parent. Siblings are elements that have a common parent. The links or "arcs" of the time graph represent synchronization relationships between the nodes of the graph.
Note that this definition is preliminary.
The time model description uses a set of adjectives to describe particular concepts of timing:
More information on the supported events and the underlying mechanism is described in the DOM section of this draft [SMIL-DOM].
In scheduled timing, elements are timed relative to other elements. The timebase for an element A is the other element B to which element A is relative. More precisely, it is the begin or end of the other element. The timebase is not simply a scheduled point in time, but rather a point in the time graph.
Note that this definition is preliminary. The name may also change.
"Sync-arc" is an abbreviation for "synchronization arc". Sync-arcs are used to relate nodes in the time graph, and define the timing relationship between the nodes. A sync-arc relates an element to its timebase. The sync-arc may be defined implicitly by context, explicitly by id-ref or event name, or logically with special syntax.
Note that this definition is preliminary.
A Clock is a particular timeline reference that can be used for synchronization. A common example that uses real-world local time is referred to as wall-clock timing (e.g. specifying 10:30 local time). Other clocks may also be supported by a given presentation environment.
During playback, an element may be activated automatically
by the progression of time, via a hyperlink, or in response to an event.
When an element is activated, playback of the element begins.
SMIL includes support for declaring media, using element syntax defined in [SMIL-MEDIA]. The media that is described by these elements is described as either discrete or continuous:
Using simple, scheduled timing, a time graph can be described in which all the times have a known, defined sync relationship to the document timeline. We describe this as determinate timing.
When timing is specified relative to events or external clocks, the sync relationship is not initially defined. We describe this as indeterminate timing.
A time is resolved when the sync relationship is defined, and the time can actually be scheduled on the document time graph.
Indeterminate times that are event-based are resolved when the associated event occurs at runtime - this is described more completely below. Indeterminate times that are defined relative to external clocks are usually resolved when the document playback begins, and the relationship of the document timeline to the external clock reference is defined.
A determinate time may initially be unresolved, e.g. if it is relative to an unknown end such as the end of a streaming MPEG movie (the duration of an MPEG movie is not known until the entire file is downloaded). When the movie finishes, determinate times defined relative to the end of the movie are resolved.
While a document is playing, network congestion and other factors will sometimes interfere with normal playback of media. In a SMIL 1.0 hard sync environment, this will affect the behavior of the entire document. In order to provide greater control to authors, SMIL Boston extends the hard and soft sync model to individual elements. This support allows authors to define which elements and time containers must remain in strict or "hard" sync, and which elements and time containers can have a "soft" or slip sync relationship to the parent time container.
A significant motivation for SMIL Boston is the desire to integrate declarative, determinate scheduling with interactive, indeterminate scheduling. The goal is to provide a common, consistent model and a simple syntax.
Note that "interactive" content does not refer simply to hypermedia with support for linking between documents, but specifically to content within a presentation (i.e. a document) that is activated by some interactive mechanism (often user-input events, but including local hyperlinking as well).
SMIL Boston represents an evolution from earlier multimedia runtimes. These were typically either pure, static schedulers or pure event-based systems. Scheduler models present a linear timeline that integrates both discrete and continuous media. Scheduler models tend to be good for storytelling, but have limited support for user-interaction. Event-based systems, on the other hand, model multimedia as a graph of event bindings. Event-based systems provide flexible support for user-interaction, but generally have poor scheduling facilities; they are best applied to highly interactive and experiential multimedia.
The SMIL 1.0 model is primarily a scheduling model, but with some flexibility to support continuous media with unknown duration. User interaction is supported in the form of timed hyperlinking semantics, but there was no support for activating individual elements via interaction.
To integrate interactive content into SMIL timing, the SMIL 1.0 scheduler model is extended to support several new concepts: indeterminate timing and event-activation.
With indeterminate timing, an element is described as a child of a time container, but with an undefined begin or end time. The element still exists within the constraints of the time container, but the begin or end time is determined by some external activation (such as a user-input event). From a scheduling perspective, the time can be thought of as unresolved.
The event-activation support provides a means of associating an event with the begin or end time for an element. When the event is raised (e.g. when the user clicks on something), the associated time is resolved to a determinate time. For event-based begin times, the element becomes active (begins to play) at the time that the event is raised. The element plays from the beginning of the media (subject to any explicit clipBegin). For event-based end times, the element becomes inactive (stops playing) when the associated event is raised.
The constraints imposed on an element by its time container are an important aspect of the event-activation model. In particular, when a time container is itself inactive (e.g. before it begins or after it ends), no events are passed to the children. No event-activation takes place unless the time container of an element is active. For example:
<par begin="10s" end="15s"> <audio src="song1.au" beginEvent="btn1.onClick" /> </par>
If the user clicks on the "btn1" element before 10 seconds, or after 15 seconds, the audio element will not play. In addition, if the audio element begins but would extend beyond the specified end of the <par> container, it is effectively cut off by the end of the <par> container. Finally, an endEvent cannot happen until an element has already begun (any specified endEvent is ignored before the element begins).
Related to event-activation is link-activation. Hyperlinking
has defined semantics in SMIL 1.0, and when combined with indeterminate timing,
yields a variant on interactive content. In particular, hyperlinking is not
constrained by the time container as event-activation is. This is because
a hyperlink will seek the document timeline as needed to ensure that the
time container is active.
SMIL 1.0 defines the model for timing, including markup to define element timing, and elements to define parallel and sequence time containers. This version introduces some syntax variations and additional functionality, including:
The complete syntax is described here, including syntax that is unchanged from SMIL 1.0.
SMIL Boston specifies three time containers: <par>, <seq>, and <excl>.
The <par> element supports all element timing.
Reviewers - Note the proposed semantics above that constrain the child elements of a seq to not use timebase specification. This simplifies the model for seq. This proposal is still under discussion.
The <seq> element supports all element timing.
The new time container, <excl>, is defined here. A normative description is given first, followed by an informative discussion of the container's behavior.
SMIL 1.0 does not allow optional content to be defined nor does it permit playback of a subsection of a presentation in isolation. All content defined in a SMIL 1.0 document is played back unless the current presentation is stopped or replaced with a different presentation. To simulate the above use cases, the author would have to hyperlink to another SMIL document containing the shared parts of the presentation plus the new content.
<par> <excl> <par id="TopStory"> <video src="video1.mpg" .../> <text src="captions.html" .../> </par> <par id="Weather"> <img src="weather.jpg" .../> <audio src="weather_rpt.mp3" .../> </par> </excl> <a href="#TopStory"> <img src="button1.jpg" .../> </a> <a href="#Weather"> <img src="button2.jpg" .../> </a> </par>
Because the optional content is played back within the context of the presentation, the same layout regions can be reused by the children of the <excl> container.
Children of the <excl> can be activated by hyperlinks or by events. When using events, the <excl> time container must be active for child elements of the <excl> to be activated by an event. When using hyperlinks, if the <excl> is not active, a seek will occur to the begin time of the <excl> and the children of the element will be activated. If the <excl> is currently active when the hyperlink is selected, a seek does not occur and playback of the child element begins. Playback of other active elements outside the scope of the <excl> is unaffected.
In the example above, an external link to the "Weather" child of the <excl> would activate the <par> containing the <excl>, as well as the target of the hyperlink. The two images would display, and weather.jpg and weather_rpt.mp3 would play back in parallel.
A pause functionality has been proposed as an option on exclusive time containers. With this, instead of stopping an element when another begins, the first element would be paused while the new element plays. When the new element completes, the previously playing element would resume. Open issues are:
endSync
The end of the <excl> container occurs when no more child elements
are playing. Used with the stacking pause, this means that at the point when
no element is playing, the <excl> time container is defined to end.
The implicit duration of a time container is defined in terms of the children of the container. The children can be thought of as the "media" that is "played" by the time container element. The semantics are specific to each of the defined time container variants.
By default, a <par> will play until all the contained children have completed. More formally, the implicit duration of a <par> element is defined by the maximum extent of the children. The extent of an element is the sum of any begin offset and the active duration. The begin offset is the computed offset relative to the begin of the <par> container (this may be different from the delay value, if the timebase for a child is not the par container).
If any child of a <par>is defined with an indefinite active duration (e.g. it repeats indefinitely), then the default duration of the <par> container is also indefinite. If any child of a par container has an interactive (event-based) begin or end, the default duration of the <par> container is indefinite. Reviewers: This entire paragraph is under scrutiny for compliance with SMIL 1.0.
The duration of a <par> container can also be controlled using the endSync attribute. The end of the <par> can be tied to the end of a particular child element, or to the end of the first child that finishes, or to the end of the last child to finish (which corresponds to the default behavior using maximum extent). Reviewers: What if the referenced child has an indefinite duration?
By default, a <seq> will play until the desired end of the last child of the <seq>. If any child of a sequence has an indefinite desired end and the child refers to continuous media, the implicit end of the sequence is also indefinite.
The implicit duration of an <excl> container is defined much the same as for a <par> container. Since the default timing for children is interactive, the typical case will define an indefinite implicit duration for <excl>. This is consistent with the common use-cases for interaction having open-ended durations.
SMIL 1.0 defined constraints on sync-arc definition (e.g., begin="id(image1)(begin)"), allowing references only to qualified siblings. SMIL Boston explicitly removes this constraint. SMIL Boston also adds event-based timing. Both sync-arcs and event-timing are constrained by the parent time container of the associated element as described above.
While a sync-arc is explicitly defined relative to a particular element, if this element is not a sibling element, then the sync is resolved as a sync-relationship to the parent. If the defined sync would place the element effective begin before the parent time container begin, part of the element will simply be cut off when it first plays. This is not unlike the behavior obtained using clipBegin. However unlike with clipBegin, if the sync-arc defined child element also has repeat specified, only the first iteration will be cut off, and subsequent repeat iterations will play normally.
Note that in particular, an element defined with a sync-arc begin will not automatically force the parent or any ancestor time container to begin.
For the case that an element with a sync-arc is in a parent (or ancestor) time container that repeats: for each iteration of the parent or ancestor, the element is played as though it were the first time the parent timeline was playing. This may require a reset of some sort in the implementation to ensure that the sync relationship to the parent time container is recalculated.
The parent time container must be active for the child element to receive
events.
This section defines the set of timing attributes that are common to all of the SMIL synchronization elements.
The syntax follows the XPointer syntax, using "id()" to specify an element,
followed by an optional time-point ("begin" or "end"), and/or an optional
offset value.
If no time-point is specified, "begin" is assumed.
If no offset value is specified, "0" as assumed.
This is renamed from "event-value" to disambiguate from
event timing which has a more general connotation.
Note that the syntax is extended to support offsets from either begin or
end, and to support signed offsets.
This defines the start time to be 3:45 in the afternoon, in local time.
The timebase is the lexical predecessor within the parent time container.
If there is no predecessor, the parent begin is used as a timebase.
If no offset value is specified, "0" as assumed.
The syntax follows the XPointer syntax, using "id()" to specify an element,
followed by an optional time-point ("begin" or "end"), and/or an optional
offset value.
If no time-point is specified, "begin" is assumed.
If no offset value is specified, "0" as assumed.
This is renamed from "event-value" to disambiguate from
event timing which has a more general connotation.
Note that the syntax is extended to support offsets from either begin or
end, and to support signed offsets.
This defines the start time to be 3:45 in the afternoon, in local time.
The timebase is the lexical predecessor within the parent time container.
If there is no predecessor, the parent begin is used as a timebase.
If no offset value is specified, "0" as assumed.
Only one of dur and end should be specified. If both are specified
(and are otherwise legal), the simple duration is defined to be the minimum
of the specified end, and the time computed from the desired begin and dur.
Only one of dur and end should be specified. If both are specified
(and are otherwise legal), the simple duration is defined to be the minimum
of the specified end, and the time computed from the desired begin and dur.
Legal values are clock values greater than
0.
For continuous media, the implicit duration is typically a function of the media itself - e.g. video and audio files have a defined duration. For all discrete media, the implicit duration is defined to be 0. Note the related example.
If the author specifies an explicit duration (using either end or dur) that is longer than the intrinsic duration for a continuous media element, the ending state of the media (e.g. the last frame of video) will be shown for the remainder of the explicit duration. This only applies to visual media - aural media will simply stop playing. See also the discussion of the fill attribute, below.
There are problems with separating the begin offset
from the timebase. It is good because it more closely matches the SMIL-DOM
that will be exposed, but it is bad because it requires two attributes.
We will also consider a syntax that specifies the offset after the ID:
beginWith="video1+5s".
Legal values are element IDs within the current document. We could also move
this over to the XPointer syntax.
No more than one of beginWith, beginAfter or beginEvent should be specified.
Legal values are element IDs within the current
document. We could also move this over to the XPointer
syntax.
No more than one of beginWith, beginAfter or beginEvent should be specified.
Elements can be specified to begin and/or end in response to an event. The event is specified with a new attribute, to clearly distinguish the form of timing being used. In this example, the audio element begins when the event is received (in this case, when the element "btn1" is clicked by the user):
<audio src="song1.au" beginEvent="btn1.onClick" />
It is possible to combine scheduled and interactive timing, e.g.:
<par dur="30s"> <img id="mutebutton" src="mute.jpg"/> <text src="description.html" /> <audio src="audio.wav" endEvent="mutebutton.onClick"/> </par>
The image and the text appear for the specified duration of the <par> (30 seconds). The audio will stop early if the image is clicked; otherwise it will play normally. Note that if the audio is stopped, the <par> still appears until the specified duration completes.
While an element can only have one defined begin (e.g. a defined time, or a beginEvent), it is possible to define both a determinate end or duration, as well as an endEvent. This facilitates what are sometimes called "lazy interaction" use-cases, such as a slideshow that will advance on its own, or in response to user clicks:
<seq> <img src="slide1.jpg" dur="10s" endEvent="onClick" /> <img src="slide2.jpg" dur="10s" endEvent="onClick" /> <img src="slide3.jpg" dur="10s" endEvent="onClick" /> <!-- etc., etc. --> </seq>
In this case, the end of each element is defined to be the earlier of the specified duration, or a click on the element. This lets the viewer sit back and watch, or advance the slides at a faster pace.
If an event-timed element has begun and then receives a second begin event before it completes, it can either ignore the second event or restart, as though it had not received the first event. This behavior is controlled with the eventRestart attribute. Note that if an event timed element receives an event and then completes its duration, it can be restarted by another event (independent of eventRestart). This came up in many user scenarios where authors tied an element beginEvent to a button, but did not want to restart (e.g. music) on every click. It is particularly useful when the beginEvent is mouseOver, which has a tendency to fire continuously...
The specific syntax used is still under review. Current proposals are:
begin=id(element)(event-name) and end=id(element)(event-name). These build upon the SMIL 1.0 syntax. This approach maintains a smaller set of attributes, but may define a more complex syntax for these attributes. In addition, there is a conflict with the semantics of end and the semantics of endEvent described below. The end attribute controls the simple duration, and the endEvent attribute controls the active duration.
More than one event may be specified. The element will begin when the first event among the set is raised.
If the argument value is "none", this element will simply wait to be turned
on (e.g. by script or a local hyperlink).
Only one timebase may be specified for the begin of a given element (i.e.
beginEvent cannot be combined with begin). If more than one timebase is
specified, only the (lexical) first specification is used; all others are
ignored.
Legal values are:
E.g. beginEvent="id(button1)(onclick)(3s)".
Note that if the id-ref is omitted, the current element is assumed.
The delay value may be omitted; it defaults to 0.
An alternative syntax would follow ECMAScript conventions:
[id-ref "." ]? event-ref [ "+"|"-" clock-val ]?
E.g. beginEvent="button1.onclick+3s"
Note that negative delay values may not be used.
More than one event may be specified. The element will end when the first
event among the set is raised.
This attribute may be combined with a scheduled specification for the element
end and/or a repeat specification.
If a finite active duration is defined for the element (with the end or dur
attributes and/or repeatCount/repeatDur), the element will end at the earlier
of the scheduled duration or the endEvent time. This allows authors
to specify an interactive end, but with a maximum active duration.
If the named event is "none", and no end time has been
specified this element will simply wait to be
turned off (e.g. by script or hyperlinking).
Legal values include:
E.g.endEvent="id(button1)(onclick)(3s)".
Note that if the id-ref is omitted, the current element is assumed.
The delay value may be omitted; it defaults to 0.
endEvent uses the same arg-value name as beginEvent,
but endEvent does not allow signed clock values. We need to clean this
up.
An alternative syntax would follow ECMAScript conventions:
[id-ref "." ]? event-ref [ "+"|"-" signed-clock-val ]? E.g.
endEvent="button1.onclick+3s"
Argument values are Booleans.
The default value is true.
SMIL 1.0 introduced the repeat attribute, which is used to repeat a media
element or an entire time container. SMIL Boston introduces two new controls
for repeat functionality that supercede the SMIL 1.0 repeat attribute.
The new attributes, repeatCount and repeatDur, provide a semantic that more
closely matches typical use-cases, and the new attributes provide more control
over the duration of the repeating behavior. The SMIL 1.0 repeat attribute
is deprecated in SMIL Boston (it must be supported
in SMIL document players for backwards compatibility).
The repeatCount and repeatDur attributes are used to cause an element to
copy or loop the contents of the element media (or an entire timeline in
the case of a time container). Using repeatCount causes the element
to repeat the simple duration of the element, effectively multiplying the
simple duration by the value of the repeatCount attribute. In this
example, the first 3 seconds of the "snd1" audio will play three times in
succession for a total of 9 seconds:
<audio src="snd1.au" dur="3s" repeatCount="3" />
The repeatDur attribute is used to specify that an element should repeat just as with repeatCount, but for a specified total duration. This can be useful when matching a repeat duration the duration of other elements. In this simple example, the "snd2" audio will repeat for a total of 10 seconds:
<audio src="snd2.au" dur="3.456s" repeatDur="10s" />
The repeatCount and repeatDur attributes can also be used to repeat an entire timeline, e.g.:
<seq begin="5s" repeat="indefinite" >
<img src="img.jpg" end="5s" />
<img src="img2.jpg" dur="4s" />
<img src="img3.jpg" dur="4s" />
</seq>
The sequence has an implicit duration of 13 seconds. It will begin to play after 5 seconds, and then will repeat indefinitely (i.e. subject to the constraints of the parent time container of the <seq>).
The repeatCount and repeatDur attributes modify the active duration of an element. If repeatCount is specified, the active duration is the simple duration multiplied by the repetition count. If a repeatDur is specified, the active duration is equal to the specified repeat duration.
Need to create normative examples that demonstrate new the controls, and the interaction with implicit and explicit simple durations. Examples must also demonstrate the interaction of repeating behavior and time container constraints.
A repeat count of less than 1 will cut short the specified simple duration.
A repeat count of 1 is a no-op.
Legal values are integer or fractional iterations, greater than 0.
A repeat duration less than the simple duration will cut short the duration.
A repeat duration equal to the simple duration is a no-op.
Legal values are clock values greater than
0.
For both attributes, "indefinite" may be specified to indicate that the element
should repeat indefinitely (subject to the time container semantics).
At most one of repeatCount or
repeatDur should be specified (if both are
specified, the repeat duration is defined as the minimum of the specified
repeatDur, and the simple duration multiplied by repeatCount.
This causes the element (including any begin delay) to play repeatedly for
the specified number of times. It is equivalent to a seq element
with the stated number of copies of the element without "repeat" attribute
as children.
Legal values are integer iterations, greater than 0, and "indefinite".
See also the SMIL 1.0 specification.
The default value is generally "remove", but is dependent upon the parent
time container and the use of indeterminate durations.
Setting this attribute to "remove" ensures that the complete duration will
not exceed the active duration. Setting this to "freeze" will extend the
complete duration by "freezing" the element state at the active end, and
showing this for the remainder of the complete duration. The actual fill
duration is subject to the constraints of the parent time container.
This attribute only has effect on visual media elements. Non-visual media
elements (audio) should ignore this.
Links are still active during fill="freeze". See also the
SMIL 1.0 specification.
In the model for time manipulations, the element's local time can be filtered or modified. The filtered time affects all descendents. Any filter that changes the effective play speed of element time may conflict with the basic capabilities of some media players. The use of these filters is not recommended with linear media players, or with time containers that contain linear media elements.
The proposed extensions support use-cases commonly associated with graphic animation.
There are a number of unresolved issues with this kind of time manipulation, including issues related to event-based timing and negative play speeds, as well as many media-related issues.
Legal values are signed percentage values. The default is +100%.
Legal values are percentage values between 0 and 100.
The default value is 0% (no deceleration).
Legal values are percentage values between 0 and 100.
Argument values are Booleans.
The default value is false (i.e. play normally).
Proposed new support in SMIL Boston introduces finer grained control over the runtime synchronization behavior of a document. The syncBehavior attribute allows an author to describe for each element whether it must remain in a hard sync relationship to the parent time container, or whether it can be allowed slip with respect to the time container. Thus, if network congestion delays or interrupts the delivery of media for an element, the syncBehavior attribute controls whether the media element can slip while the rest of the document continues to play, or whether the time container must also wait until the media delivery catches up.
The syncBehavior attribute can also be applied to time containers. This controls the sync relationship of the entire timeline defined by the time container. In this example, the audio and video elements are defined with hard or "locked" sync to maintain lip sync, but the "speech" <par> time container is allowed to slip:
<par>
<animation src="..." />
...
<par id="speech" syncBehavior="canSlip" >
<video src="speech.mpg"
syncBehavior="locked" />
<audio src="speech.au"
syncBehavior="locked" />
</par>
...
</par>
If either the video or audio must pause due to delivery problems, the entire "speech" par will pause, to keep the entire timeline in sync. However, the rest of the document, including the animation element will continue to play normally. Using the syncBehavior attribute on elements and time containers, the author can effectively describe the "scope" of runtime sync behavior, defining some portions of the document to play in hard sync without requiring that the entire document use hard synchronization.
This functionality also applies when an element first begins, and the media must begin to play. If the media is not yet ready (e.g. if an image file has not yet downloaded), the syncBehavior attribute controls whether the time container must wait until the element media is ready, or whether the element begin can slip until the media is downloaded.
The syncBehavior can affect the effective begin and effective end of an element, but the use of the syncBehavior attribute does not introduce any other semantics with respect to duration.
When the syncBehavior attribute is combined with interactive begin timing
for an element, the syncBehavior only applies once the sync relationship
of the element is resolved (e.g. when the specified event is raised). If
at that point the media is not ready and syncBehavior is specified as "locked",
then the parent time container must wait until the media is ready. Once an
element with an interactive begin time has begun playing, the syncBehavior
semantics described above apply as thought the element were defined with
scheduled timing.
Note that the semantics of syncBehavior do not describe or require a particular
approach to maintaining sync; the approach will be implementation dependent.
Possible means of resolving a sync conflict may include:
Additional control is provided over the hard sync model using the syncTolerance attribute. This specifes the amount of slip that can be ignored for an element. Small variance in media playback (e.g. due to hardware innaccuracies) can often be ignored, and allow the overall performance to appear smoother.
Legal values are:
When this value is used, any syncTolerance attribute is ignored.
locked
syncTolerance
The syncMaster attribute only applies when an element is active. If more than one element within the syncBehavior scope has the syncMaster attribute set to true, and the elements are both active at any moment in time, the behavior will be implementation dependent.
The default value is false.
The associated property is read-only, and cannot be set by script.
Clock-val ::= Full-clock-val | Partial-clock-val | Timecount-val Full-clock-val ::= Hours ":" Minutes ":" Seconds ("." Fraction)? Partial-clock-val ::= Minutes ":" Seconds ("." Fraction)? Timecount-val ::= Timecount ("." Fraction)? ("h" | "min" | "s" | "ms")? ; default is "s" Hours ::= DIGIT+; any positive number Minutes ::= 2DIGIT; range from 00 to 59 Seconds ::= 2DIGIT; range from 00 to 59 Fraction ::= DIGIT+ Timecount ::= DIGIT+ 2DIGIT ::= DIGIT DIGIT DIGIT ::= [0-9]
The following are examples of legal clock values:
3h = 3 hours
45min = 45 minutes
30s = 30 seconds
5ms = 5 milliseconds
A fraction x with n digits represents the following value:
x * 1/10**n
Examples:
00.5s = 5 * 1/10 seconds = 500 milliseconds
00:00.005 = 5 * 1/1000 seconds = 5 milliseconds
We may want to add an additional informative document that is more of an authoring guide.
Consider inclusion of algorithm to support normative description.
A document with SMIL timing is parsed incrementally and during that process a graph structure is built.
More to come here, explaining precisely how syntax is translated to formal semantics and graph structure.
When an element is parsed, it is introduced into the graph according to the temporal relation where it appears. In order to clarify the process of graph creation and graph consistency, we must consider the way the graph is built. When an element is parsed, the insertion into the graph follows these operations:
Arc creation is a source of potential inconsistencies. These must be detected and resolved according to a set of fixed rules, to ensure consistent performance across implementations.
More to come here.
This section includes a set of examples that illustrate both the usage of the SMIL syntax, as well as the semantics of specific constructs. This section is informative.
Note: In the examples below, the additional syntax related to layout and other issues specific to individual document types is omitted for simplicity.
All the children of a <par> begin by default when the <par> begins. For example:
Elements "i1" and "i2" both begin immediately when the par begins, which is the default begin time. "i1" ends at 5 seconds into the <par>. "i2" ends at 10 seconds into the <par>. The last element "i3" begins at 2 seconds since it has an explicit begin offset, and has a duration of 5 seconds which means it ends 7 seconds after the <par> begins.
Each child of a <seq> begins by default when the previous element ends. For example:
The element "i1" begins immediately, with the start of the <seq>, and ends 5 seconds later. Note: specifying a begin time of 0 seconds is optional since the default begin offset is always 0 seconds. The second element "i2" begins, by default, 0 seconds after the previous element "i1" ends, which is 5 seconds into the <seq>. Element "i2" ends 10 seconds later, at 15 seconds into the <seq>. The last element, "i3", has a begin offset of 1 second specified, so it begins 1 second after the previous element "i2" ends, and has a duration of 5 seconds, so it ends at 21 seconds into the <seq>.
<par> <excl> <par id="p1"> ... </par> <par id="p2"> ... </par> </excl> <a href="p1"><img src="Button1.jpg"/></a> <a href="p2"><img src="Button2.jpg"/></a> </par>
This example models jukebox-like behavior. Clicking on the first image activates the media items of parallel container "p1". If the link on the second image is traversed, "p2" is started (thereby deactivating "p1" if it would still be active).
Shouldn't we say, here, exactly where the elements of the selected par in the excl should begin when a click happens, e.g., if we are 10 seconds into the outer par and we click on button 2, does the MPG video in p2 start 10 seconds into its stream (in-sync), or does it start at its time 0?
<par> <excl> <par beginEvent="btn1.onclick"> ... </par> <par beginEvent="btn2.onclick"> ... </par> </excl> <img id="btn1" src=... /> <img id="btn2" src=... /> </par>
The same jukebox example, using event-based activation.
In these two examples event-based and anchor-based activation look almost identical, maybe we should come up with examples showing the difference and the relative power of each.
<excl> <ref id="a" begin="0s" ... /> <ref id="b" begin="5s" ... /> </excl>
In the example above, the beginning of "b" deactivates "a" (assuming that a is still active after 5 seconds). Note that this could also be modeled using a sequence with an explicit duration on the children. While the determinate syntax is allowed, this is not expected to be a common use-case scenario.
Issue - should we preclude the use of determinate timing on children of
excl? Other proposals would declare one child (possibly the first)
to begin playing by default. Proposals include an attribute on the
<excl> container that indicate one child to begin playing by default.
For all discrete media, the implicit duration is defined to be 0. This can lead to surprising results, as in this example:
<seq>
<img src="img1.jpg" />
<video src="vid2.mpg" />
<video src="vid3.mpg" />
</seq>
This will not show the image at all, as it defaults to a duration of 0, and so the second element will begin immediately. Authors will generally specify an explicit duration for any discrete media elements.
There is an important difference between the semantics
of endEvent and end/dur.
The end and dur attributes, in conjunction with the
begin time, specify the simple duration for an element.
This is the duration that is repeated when the element also has a repeat specified. The attribute endEvent on the other hand overrides the active duration of the element. If the element does not have repeat specified, the active duration is the same as the simple duration. However, if the element has repeat specified, then the endEvent will override the repeat, but will not affect the simple duration. For example:
<seq repeat="10" endEvent="stopBtn.onClick"> <img src="img1.jpg" dur="2s" /> <img src="img2.jpg" dur="2s" /> <img src="img3.jpg" dur="2s" /> </seq>
The sequence will play for 6 seconds on each repeat iteration. It will play through 10 times, unless the user clicks on a "stopBtn" element before 60 seconds have elapsed.
When an implementation supports the SMIL-DOM, it will be possible to make an element begin or end using script or some other browser extension. When an author wishes to describe an element as interactive in this manner, the following syntax can be used:
<audio src="song1.au" beginEvent="none" />
The element will not begin until the SMIL-DOM beginElement() method is called.
SMIL 1.0 supported a means of defining one element to begin relative to the begin or end of another element. This was referred to as "event" timing in SMIL 1.0, however the syntax described a determinate synchronization relationship, and did not require an implementation to use events. To reduce confusion with more traditional events such as user-input events, the SMIL 1.0 description and syntax for this has been deprecated (although conforming SMIL Boston players will support the SMIL 1.0 syntax).
We have not yet formally agreed upon this, but there seemed to be some growing consensus on the mailing list for the need to disambiguate event-based timing in the sense of interactive content, and SMIL 1.0 "event" based timing (which is really just a terminology for describing sync-arcs).
B.4 - preface to examples - resolved
When the same event is specified for both the beginEvent and the endEvent, the semantics of the "active" state define the behavior. If the element is not active, then the beginEvent is sensitive, and responds to the event, making the element active. Since the endEvent is not sensitive when the element is not active, it does not respond to this initial event. When the element is active, the endEvent is sensitive and responds to a second event, making the element inactive. This supports the common use-case of clicking an element to turn it on, and clicking it again to turn it off.
Linking to children of an <excl> actually violates the notion
that the children of the <excl> can have any determined
relationship with the parent.
What happens when child #2 has a determined start time of 15s (w.r.t. the
parent) and then the user follows a link at time 14s (w.r.t.the parent) to
child #3. Does child #3 get replaced by child #2 when 15s is reached? Highly
annoying if you've just followed a link to it. Does child #3 continue playing,
thus violating the determined start time of child #2.
We may require some extra information in the link specification (e.g. multiple
source link ends) to allow the author to specify the wished-for behavior.
It may only require that authors are aware that they may sometimes have to
introduce an extra layer of structure to obtain the behavior they want.
Again, there is the choice of whether we implement pausing, and how we model it, that will influence this.
B.8 - Precise definition of timing relative to another node Resolved.
B.9 - Alternative syntax for begin and end - Described in section on Alternative begin/end syntax.
The proposal partially described above is that we support the same notion
that the linking introduces, but for children of the excl. This is,
if an element is playing when another begins (or is begun), that the playing
element can optionally be made to stop and then resume when the new element
completes. This is useful for situations where you define a primary
program and some potential interruptions (like commercials). You want
to pause the primary timeline and then resume it when the insertion
completes. This is useful for the same reasons that the linking behavior
is useful, but supports the control over a specific timeline segment rather
than on an entire document. The requirement came from someone who wants
to use the time syntax for another XML application, rather than in a SMIL-like
scenario. We are still discussing where this behavior should be described
(on the element that is interrupted, or on the inserted element). There
are arguments and use-cases for both.