This section is informative
The SMIL 2.1 specification leaves the Time Manipulations Module[SMIL20-timemanipulations] unchanged.
This section is informative
This module introduces new attributes for advanced manipulation of timebehavior, such as controlling thespeed orrate of time foran element. These time manipulations are especially suited toanimation and non-linear or discrete media. Not all continuous media typeswill fully support time manipulations. For example, streaming MPEG 1 videowill not generally support backwards play. A fallback mechanism is describedfor these kinds of media.
Four new attributes add support for time manipulations to SMIL timingmodules, including control over the speed of an element, and support foracceleration and deceleration. The impact on overall timing andsynchronization is described. A definition is provided for reasonablefallback mechanisms for media players that cannot support the timemanipulations.
An accessibility requirement for control of the playback speed is relatedto the speed control, but may also be controlled through some other mechanismsuch as DOM interfaces.
This section is informative
A common application of timing supports animation. The recent integrationof SMIL timing with SVG is a good example of the interest in this area. Animation in the more general sense includes the time-based manipulation ofbasic transforms, applied to a presentation. Some of the effects supportedinclude motion, scaling, rotation, color manipulation, as well as a host ofpresentation manipulations within a style framework like CSS.
Animation is often used to model basic mechanics. Many animation use-casesare difficult or nearly impossible to describe without a simple means tocontrol pacing and to apply simple effects that emulate common mechanicalphenomena. While it is possible to build these mechanisms into the animationbehaviors themselves, this requires that every animation extension duplicatethis support. This makes the framework more difficult to extend andcustomize. In addition, a decentralized model allows any animation behaviorto introduce individual syntax and semantics for these mechanisms. Theinconsistencies that this would introduce make the authoring model muchharder to learn, and would complicate the job of any authoring tool designeras well. Finally, an ad hoc, per-element model precludes the use of suchmechanisms on structured animations (e.g. applying time manipulations to atime container of synchronized animation behaviors).
A much simpler model for providing the necessary support centralizes theneeded functionality in the timing framework. This allows all timed elementsto support this functionality, and provides a consistent model for authorsand tool designers. The most direct means to generalize pacing and relatedfunctionality is to transform the pacing oftime for a givenelement. This is an extension of the general framework for element time(sometimes referred to as "local time"), and of the support to convert fromtime on one element to time on another element. Thus, to control the pacingof a motion animation, a temporal transform is applied that adjusts thepacing of time (i.e., therate of progress) for the motion element.If time is scaled to advance faster than normal presentation time, the motionwill appear to run faster. Similarly, if the pacing of time is dynamicallyadjusted, acceleration and deceleration effects are easily obtained.
The time manipulations are based upon a model of cascading time. That is,each element defines its active and simple time as transformations of theparent simple time. This recurses from the root time container to each "leaf"in the time graph. If a time container has a time manipulation defined, thiswill be reflected in all children of the time container, since they definetheir time in terms of the parent time container. In the following example asequence time container is defined to run twice as fast as normal (i.e. twiceas fast as its respective time container).
<seq speed="2.0"> <video src="movie1.mpg" dur="10s" /> <video src="movie2.mpg" dur="10s" /> <img src="img1.jpg" begin="2s" dur="10s"> <animateMotion from="-100,0" to="0,0" dur="10s" /> </img> <video src="movie4.mpg" dur="10s" /></seq>
The entire contents of the sequence will be observed to play (i.e., toprogress) twice as fast. Each video child will be observed to play at twicethe normal rate, and so will only last for 5 seconds. The image child willbe observed to delay for 1 second (half of the specified begin offset). Theanimation child of the image will also "inherit" the speed manipulation fromthe sequence time container, and so will run the motion twice as fast asnormal, leaving the image in the final position after only 5 seconds. Thesimple duration and the active duration of the sequence will be 21 seconds(42 seconds divided by 2).
This section is informative
Three general time manipulations are defined:
This section is normative
When the speed of time isfiltered with any of the timemanipulations, this affects how a document time is converted to an elementsimple time. To understand this, think of the contents of an elementprogressing at a given rate. An unmodified input time value isconverted to anaccumulated progress for the element contents.Elementprogress is expressed asfiltered time. This allowsthe effect of any rate (including acceleration and deceleration) to cascadeto any timed children. If element progress is advancing at a constant rate(e.g. with a speed value of 2), the filtered time calculation is just theinput time multiplied by the rate. If the rate is changing, the filtered timeis computed as an integral of the changing rate. The equations used tocalculate the filtered time for a given input time are presented inConverting document time to elementtime.
Theaccelerate and
TheautoReverse feature isapplied directly to the simple duration, and doubles a declared orimplicit simple duration. Thus if the simple duration is defined (accordingto the normal timing semantics) to be 5 seconds, setting the
Thespeed attribute scales theprogress of element time for the element. When applied to a time container,the contents of the time container collectively play at the scaled speed. Ifan element plays twice as fast as normal, the observed simple duration willbe only half as long as normal. This may or may not affect the activeduration, depending upon how it is defined for the element. The attributesrepeatDur,
Note that aspeed attribute on anelement does not affect the element begin time. Offset values for the
When these time manipulations are applied to a time container, they affectthe way that the entire contents of the time container proceeds - i.e. theyaffect all timed descendents of the time container. As a global time isconverted to element time, the time manipulations for each ancestor areapplied, starting with the root of the timegraph and proceeding down to theparent time container for the element. Thus the simple time and active timefor a given element are ultimately computed as a function of the timemanipulations of all ascendant time containers, as well as any timemaniuplations defined on the element itself. This is described morecompletely inDetails of timing modelarithmetic.
Thenet cascaded speedof an element is a function of any timemanipulations on the element and all of its ascendant time containers.Although this can becomputeddirectly from the described values, the speed can also be thought of as thederivative of the rate of time (i.e. the rate of progress) at any point.
This section is informative
This model lends itself well to an implementation based upon "sampling" atimegraph, with non-linear media (also called "random access"media). The time manipulations model is based upon a model commonly used ingraphics and animation, in which an animation graph is "sampled" to calculatethe current values for the animation, and then the associated graphics arerendered. Some linear media players may not perform well with thetime manipulations (e.g. players that can only play at normal play speed). Afallback mechanism is described in which the timegraph and syncbase-valuetimes are calculated using the pure mathematics of the time manipulationsmodel, but individual media elements simply play at the normal speed ordisplay a still frame.
Some of the examples below include animation elements such as
This section is normative
These attributes define a simple acceleration and deceleration of elementtime, within the simple duration. The values are expressed as aproportion of the simple duration (i.e. between 0 and 1), and aredefined such that the length of the simple duration is not changed by the useof these attributes. The normal play speed within the simple duration isincreased to compensate for the periods of acceleration and deceleration(this is how the simple duration is preserved). The modified speed is termedtherun rate. As the simple duration progresses (i.e., plays back),acceleration causes the rate of progress to increase from a rate of 0 up tothe run rate. Progress continues at the run rate until the decelerationphase, when progress slows from the run-rate down to a rate of 0. This isillustrated in Figure 1, below:
<animation dur="10s" accelerate="0.3" decelerate="0.3" .../>
Figure 1: Effect of acceleration and deceleration upon the rate ofprogress.
These attributes apply to the simple duration; if these attributes arecombined with repeating behavior, the acceleration and/or deceleration occurswithin each repeat iteration.
The sum ofaccelerate anddecelerate must not exceed 1. Ifthe individual values of the
If the simple duration of the element is not resolved or if it is resolvedto be indefinite, then the
For details of computing the run-rate, and for converting from parentsimple time to element simple time when
In this example, a motion path will accelerate up from a standstill overthe first 2 seconds, run at a faster than normal rate for 4 seconds, and thendecelerate smoothly to a stop during the last 2 seconds. This makes themotion animation look more realistic.
<img ...> <animateMotion dur="8s" accelerate=".25" decelerate=".25" .../></img>
In the following example, the image will "fly in" from offscreen left, andthen decelerate during the last second to "ease in" to place. This assumes alayout model that supports positioning (for example CSS positioning, or theposition of aregion in SMILLayout).
<img ...> <animate attributeName="left" dur="4s" decelerate=".25" from="-1000" to="0" additive="sum" /></img>
Another common mechanical phenomenon is that of a process that advancesand reverses. Some examples include:
Because so many common use-cases apply repeat to the modified local time(as in the examples above), this function is modeled as modifying the simpleduration. As such,autoReversedoubles the declared or implicit simple duration. When combined withrepeating behavior, each repeat iteration will play once forwards, and oncebackwards.
When this is applied to a time container, it will play the time containerforwards and then backwards. The semantics of playing a time containerbackwards are detailed inImplications of time manipulations on time containers.
TheautoReversetime manipulation does not initially require a resolved simple duration,although it will not begin playing backwards until the simple duration isresolved and has completed. This can happen when the simple duration isdefined by an unresolved implicit simple duration (such as the intrinsicmedia duration). In this case, the element will continue to play forwarduntil the implicit simple duration is resolved (or until the active durationor the parent time container cuts short the simple duration, as described intheTiming section of SMIL 2.1). Ifthe implicit simple duration becomes resolved before the end of the activeduration, then the simple duration will be resolved to 2 times this implicitduration, and the implicit simple duration will play backwards.
Any time that the element will play backwards, including thesecond part of theautoReversemanipulation, the simple duration must be resolved. See alsoThe speed attribute.
In this example, a motion path will animate normally for 5 seconds movingthe element 20 pixels to the right, and then run backwards for 5 seconds(from 20 pixels to the right back to the original position). The repeatingbehavior causes it to repeat this 2 more times, finally leaving the elementat its original location. The computed simple duration of the animation is 10seconds, and the active duration is 30 seconds.
<img ...> <animateMotion by="20, 0" dur="5s" autoReverse="true" repeatCount="3"/></img>
In the following example the motion path will behave as above, but willend at the earlier of 15 seconds or when the user clicks on the image. If theelement ends at 15 seconds (if the user does not click), the motion path willleave the element at the end of the defined path, 20 pixels to the right.Since the active duration is defined by the
<img ...> <animateMotion by="20, 0" dur="5s" autoReverse="true" repeatDur="15" end="click" fill="freeze"/></img>
Theaccelerate and
<img ...> <animateMotion by="20, 0" dur="4s" autoReverse="true" accelerate=".25" decelerate=".25" /></img>
This will produce a kind of elastic motion with the path accelerating for1 second from the original position as it moves to the right, moving slightlyfaster than normal for 2 seconds, and then decelerating for 1 second as itnears the points 20 pixels to the right. It accelerates back towards theoriginal position and decelerates to the end of the reversed motion path, atthe original position.
The following example of a rotation (based upon the SVGanimateTransform element) also demonstrates the combination of
<animateTransform type="rotate" from="20" to="-20" dur="1s" repeatCount="indefinite" accelerate=".5" decelerate=".5" autoReverse="true" ... />
The pendulum swings through an arc in one second, and then back again in asecond. The acceleration and deceleration are applied to the unmodifiedsimple duration, andautoReverseplays this modified simple duration forwards and then backwards. The effectis to accelerate all the way through the downswing, and then decelerate allthrough the upswing. The
Thespeed attribute controls thelocal playback speed of an element, to speed up or slow down the effectiverate of play relative to the parent time container. The
Values less than 0 are allowed, and cause the element to play backwards.An element can only play backwards if there is sufficient information aboutthe simple and active durations. Specifically:
If the cascaded speed value for the element is negative and if either ofthe above two conditions is not met, the element will begin and immediatelyend (i.e. it will behave as though it had a specified active duration of 0).If there is amin attribute specified,the time container will simply be frozen at the initial state for thespecified minimum duration.
The details of the effect of the element
The following motion animation will move the target twice as fast asnormal:
<animateMotion dur="10s" repeatCount="2" speed="2.0" path= ... />
The target will move over the path in 5 seconds (simple dur/speed =10s/2.0= 5s), and then repeat this motion (because
Whenspeed is applied to a timecontainer, it scales the rate of progress through the time containertimeline. This effect cascades. When descendents also specify a
<par speed=2.0> <animate begin="2s" dur="9s" speed="0.75" .../></par>
The observed rate of play of the
The following example shows how an event based
<par speed="2.0"> <animate begin="2s" dur="9s" speed=0.75 repeatCount="4" end="click" .../></par>
This behaves as in the first example, but the
<par speed="2.0"> <img dur="30s" .../> <animate dur="9s" speed="0.75" repeatCount="4" end="click; foo.end .../></par>
The image will display for 15 seconds. The
Note that in the examples above, the default duration of the
The following example illustrates an important effect of offset timescaling:
<par speed="2.0"> <img dur="30s" .../> <animate begin="2s" dur="9s" speed="0.75" repeatCount="4" end="foo.end+6s" .../></par>
The image will display for 15 seconds, as above. The
This section is normative
When the time manipulation attributes are used to adjust the speed and/orpacing within the simple duration, the semantics can be thought of aschanging the pace of time in the given interval. An equivalent model is theseattributes simply change the pace at which the presentationprogressesthrough the given interval. The two interpretations are equivalentmathematically, and the significant point is that the notion of "time" asdefined for the element simple duration should not be construed as real worldclock time. For the purposes of SMIL Time manipulations (as for SMIL Timingand Synchronization), "time" can behave quite differently from real worldclock time.
In the following discussion, several symbols are used as shorthand:
Leta be the value of
Letdur be the value of the simple duration as defined bythe Timing and Synchronization model. This is the actual simple duration, andnot simply thedur attribute. This valuedoes not account for the effect of any time manipulations.
Letdacc be the duration of the acceleration phase, andddec be the duration of the deceleration phase. These valuesare computed as a function of the unmodified simple duration. Note that withthe described model for acceleration and deceleration, the observed durationduring which time accelerates and/or decelerates may be greater thandacc andddec respectively.
dacc = dur * addec = dur * d
In order to preserve the simple duration, the speed through the simpleduration must be increased to account for acceleration and deceleration. Tocompute the run rate over the course of the simple duration, the followingformula is used. The run rater is then:
r = 1 / ( 1 - a/2 - b/2 )
Thus, for example, if the value of
r(t) is the speed modification due to acceleration anddeceleration, at any timet within the simple duration. Theparameter timet mustnot already be modified toaccount for acceleration and deceleration. In the terms of the discussionbelow,Converting document time toelement time, the parameter timet is in thetsu' space. The speed modification is definedas a function of the run rater, as follows:
In the acceleration interval, where (0 <= t < dacc)r(t) = r * ( t / dacc )In the run-rate interval, where (
dacc <= t <= ( dur - ddec ))r(t) =rIn the deceleration interval, where (
( dur - ddec ) < t <= dur)r(t) =r * (dur -t ) / (ddec )
The run-rate only describes the modification applied to account for anyacceleration and deceleration. This is combined with any element speed, aswell as the speed inherited from the parent time container. The combined or"net" speed is defined in the sectionComputing the net cascaded speed for anelement.
To convert a document time to an element time, the original time isconverted to a simple time for each time container from the root timecontainer down to the parent time container for the element. This recursivealgorithm allows for a simple model of the conversion from parent simple timeto element active and element simple time. The first step calculates elementactive time, and the second step calculates element simple time.
These steps are based upon a simpler, general model for time conversionthat applies to the timing model independent of the time manipulationsfunctionality (see also theTimingsection of SMIL 2.1). The steps below describe the modified arithmetic forconverting times, taking into account the semantics of time manipulations.
The steps below assume that the associated times are resolved and notindefinite. If a required time is not resolved or is indefinite, then theconversion is not defined, and cannot be performed.
In order to reflect the semantics of element speed, the element activetime must be adjusted. The adjusted time is called thefiltered activetime, and is used by the element where the timing semantics refer to"element active time". The
The input time is a time in parent simple time. This is normalized to theelement active duration, adjusting for the accumulated synchronization offset(described inTheaccumulated synchronization offset).
Lettps be a time in parent simple time, andB be the begin time, andO be the accumulated synchronization offset for an element, measured in parent simple time. LetAD be theActive Duration.The unfiltered active timetau for any child element is:
tau =tps - B - O
Given an unfiltered activetau, the filteredactive timetaf is only a function of thespeed for the element (this is the value specified in aspeed attribute, or the default, and not the net cascaded speed):
If(speed> 0 ) i.e. if the local speed is forwardstaf =tau * speedElse i.e. if the local speed is backwards
taf =AD - tau * ABS( speed )
As expected, if the speed value is 1 (the default), this is an identityfunction, and sotaf =tau. When speed is less than 0 (in the backwardsdirection), the active duration proceeds from the end of the active durationtowards 0.
In order to reflect the semantics of the
The element simple time is the time that is used to establish runtimesynchronization for a media element, or to compute an animation function'sinput value or sampling time. If the element is a time container, this isalso the time that is seen by all children of a time container (as the timecontainer element's simple time).
The input time is a filtered active timetaf.
Letdur' be the modified simple duration that accounts for the effect of the autoReverse attribute. It is computed as follows:If autoReverse is false:dur' = dur
Else (if autoReverse is true)
dur' = dur * 2
The steps to compute the filtered simple time are described below.
If there is no repeating behavior:
tsu = taf
Else, if the modified simple durationdur' is fixed and does not vary (ideal case):
tsu = REMAINDER( taf, dur' )
whereREMAINDER( t, d ) is defined as(t - d*floor(t/d)).
Else, if the modified simple durationdur' varies from repeat iteration to repeat iteration, or if it is unknown, then the unfiltered simple time is just computed from the begin time of the most recent iteration - call thistlast-repeat. Some other mechanism (such as endsync logic or a media player) must note when the simple duration ends, and reset the value oftlast-repeat. If the element has not yet repeated, a value of 0 is used in place oftlast-repeat.
tsu = taf - tlast-repeat
Else if autoReverse is true (note that the following steps use the unmodified durationdur, and notdur'):
Iftsu < durtsu' = tsuElse (tsu >= dur )
tsu' = dur - ( tsu - dur ) = 2*dur - tsu
The filtered simple timetsf is computed as a function of the input timetsu' and the run rates in effect over the interval from 0 totsu'. The filtered simple time is theaccumulated progressup to the input time, and is computed as the integral of the acceleration, run-rate and deceleration rates. Since the rate of acceleration and deceleration are constant, the integral simplifies to a function of theaverage rate of progress for each of the three intervals defined by the acceleration and deceleration values. The steps below compute the filtered time by multiplying the input time and the average rates of progress. In the acceleration interval, since acceleration is constant and the rate changes from 0 tor, the average rate is just 1/2 of the instantaneous rater(t) defined above:average rate = (r(t) + r(0) ) / 2) = r(t)/2In the deceleration interval, the average rate is similarly computed. In the run-rate interval the rate is constant, and so the average rate is equal to the run-rate.
In the acceleration interval, where (0 <= tsu' < dacc ), the filtered simple time is the input time multiplied by the average run-rate during the acceleration interval:
tsf = tsu' * r(tsu') / 2In the run-rate interval, where (dacc <= tsu' <= ( dur - ddec ) ), the filtered simple time is computed from the input time and the rates in the acceleration and run-rate intervals. This adds the accumulated progress in the acceleration interval to the progress within the run-rate interval:
tsf = dacc * r / 2 + ( tsu' - dacc ) * r= r * ( dacc / 2 + ( tsu' - dacc ))
= r * ( tsu' - dacc / 2 )
In the deceleration interval, where (( dur - ddec ) < tsu' <= dur ), the filtered simple time is computed from the input time and the rates in all three intervals. This sums the total progress in the acceleration interval, the total progress within the run-rate interval, and the progress within the deceleration interval.
To simplify the expressions, we definetdec, the time spent in the deceleration interval:
tdec = tsu' - ( dur - ddec )We also define the proportional duration within the deceleration interval as:
pd = tdec / ddecThe filtered time within the deceleration interval is then:
tsf = dacc * r / 2
+ ( dur - dacc - ddec ) * r
+ tdec * (( r + r*(1 - pd )) / 2 ))= r * ( dur - dacc / 2 - ddec
+ tdec * ( 2 - pd ) / 2 )
To convert from one element timespace to another, the time for the firstelementte1 must first be converted to a simpletime on the closest ascendant time container that contains both elements.Converting from an element time to the parent time reverses the processdescribed above. Again, it is recursive, and so the conversions are describedgenerically from element simple to element active time, and from elementactive to parent simple time.
To convert from element simple time to element active time requires thebegin time of the most recent iteration,tlast-repeat. If the element does not repeat orhas not yet repeated, a value of 0 is used in place oftlast-repeat.
ta = ts +tlast-repeat
Conversion from element active time to parent simple time uses theassociated begin of the element and the accumulated synchronizationoffset.
tps =ta + B +O
Note that the pure conversions do not take intoaccount the clamping of active durations, nor the effects of fill (where timeis frozen).Global to local time conversionsused to translate between timespaces must ignore these issues, and so mayyield a time in the destination local timespace that is well before or wellafter the simple duration of the element.
An alternate form of the conversion is used whenactually sampling the time graph.A timecontainer is only sampled if it is active or frozen, and so no times will beproduced that are before a time container begins. If the global to local timeconversion for a time container yields a time during which the time containeris frozen, the time is clamped to the value of the active end.
The net cascaded speed for a given element at a given point in time can beused to set the correct playback rate for a media element. It is nototherwise used directly in the time manipulations model.
To compute the net cascaded speedspeednc(t)for an element at a given point in time, we combine the net cascaded parentspeed at the point in timespeednc-parent(t) withthe element speed valuespeed and the instantaneous run rater(t) computed from any acceleration and deceleration. If theelement has no time parent, use1 forspeednc-parent(t).
Note that the net cascaded parent speed will be computed in simple timefor the parent, and so the element simple time will have to be converted to aparent simple time. This is described above in Converting element time to documenttime.
The parameter time value must be in the range of the simple duration. Thetime value mustnot already be modified to account for accelerationand deceleration. In the terms of the discussion above,Converting document time to elementtime, the parameter time is in thetsu'space.
The net cascaded speedspeednc(t) for a givenunfiltered simple time tsu'is then:
speednc(tsu') = speednc-parent(tsu') * speed * r(tsu')
This definition is recursive up to the root of the time containmenthierarchy, and so accounts for any speed settings on the parent and all otherascendant time containers.
This section is informative
A theoretical model can be described that assumes that all element localtimelines (including any media elements) are completely non-linear and haveunconstrained ballistics (i.e. they can be sampled at any point at anymoment, and can adjust the observed playback rate instantaneously). Thisideal model can be applied to many applications, including pure renderedgraphics, text, etc. Nevertheless, many common applications also includemedia with linear behavior and other limitations on playback. When thetimegraph includes media elements that have linear behavior, the timemanipulations model must accommodate these real world limitations.
While the model doessupport timegraphs with a mix of linear andnon-linear behavior, and defines specific semantics for media elements thatcannot support the ideal non-linear model, it isnot a goal toprovide an ideal alternative presentation for all possible timegraphs withsuch a mix. It is left to authors and authoring tools to apply the timemanipulations in appropriate situations. This section describes both theideal model as well as the semantics associated with linear-mediaelements.
This section is informative
In the ideal model, the pace or speed of local time can be manipulatedarbitrarily. The graph advances (or is sampled, depending upon yourperspective) as the presentation time advances. A time container samples eachof its children in turn, so that a graph traversal is performed for eachrender time. Elements that are neither active nor frozen may be pruned fromthe traversal as an optimization. As the traversal moves down the graph (fromtime containers to children), each local timeline simply transforms thecurrent time from the parent time-space to the local time space, and thensamples the local timeline at the transformed current time. Note that thespeed and effects of the time filters effectively cascade down the timegraph, since each element transforms element time and element speed foritself and all descendents.
This is the model that is described by the arithmetic model inDetails of timing model arithmetic.
When linear media are added to this model and the "current time" (sample)traversal encounters a media element, the media element is effectively toldto "sample" at a particular position and a particular rate. Given that linearmedia can not sample arbitrarily (i.e., they cannot immediately seek to anddisplay an arbitrary frame or sample) , the media element player may not beable to match the ideal model.
Many media elements cannot play off-speed (i.e. at other than normal playspeed), and so must simply ignore the requested speed. As the element plays,it will fall out of sync with the sync relationship defined in the timingsyntax. Within the limits defined by the SMIL syncTolerance attribute,divergence from the theoretical timeline position may be ignored. However,for further divergence beyond this tolerance the element will be consideredout of sync; if the element is defined withsyncBehavior="locked", the playback engine will try to enforcethe runtime synchronization semantics (and this will probably not yield adesirable presentation playback). Authors applying time manipulations tolinear media or to time containers that include linear media will likely wishto specify the
This section is normative
The fallback semantics depend upon how much or how little the media playeris capable of. Some players for some media may play forwards and backwardsbut only at the normal rate of play, others may only support normal forwardplay speed.
If the element speed (i.e. the cascaded value) is not supported by themedia element, the media should play at the closest supported speed ("besteffort"). If the element cannot play slower or faster than the normal playspeed, the closest supported speed will be the normal play speed.
In any case, the computed simple duration,as modified by thetime filters, is respected.
The semantics ofclipBegin andclipEnd are not affected by timemanipulations. TheclipBegin andclipEnd semantics are alwaysinterpreted in terms ofnormal forwardplay speed. They areevaluated before any effects of time filters have been applied to the timemodel. This is consistent with the model that they can be evaluated by themedia element handler, independent of the time model.
This section is informative
In this fallback model, some media elements may not be able to play at thecomputed speed defined by the time graph. The fallback semantics may causethe media element to fall out of visual synchronization with respect to therest of the timegraph. For example, if an image element is defined to begin10 seconds after a video element begins, and then a speed of 2.0 is appliedto a time container for both elements, the image element will begin at 5seconds (10s/2.0). If the video cannot play at twice the normal speed, itwill not be 10 seconds into the video when the image shows up, and so thepresentation may appear to be out of sync.
When time manipulations are used with linear media, authors can usemedia-marker-values to define the sync relationships. This can help tomaintain the "visual" sync regardless of the fallback behavior. Since themedia-marker-values are defined to happen when a particular point in themedia is played, this timing will respect the actual behavior of the media,rather than the computed speed behavior.
This section is normative
The time manipulations can apply to any element, including timecontainers. There are two primary implications of this for the time model:
The following discussion is based upon the semantics of begin and endinstance lists and the interpretation of lists of begin and end timesdescribed in theTiming section ofSMIL 2.1
If the time container can play backwards (based upon the generalconstraints for backwards play upon the simple and active durations), thenthe children must play the defined intervals in reverse order. This isaccomplished with the following modified life cycle for child elements. Inthe following description, the terms "begin" and "end" for intervals are usedrelative to the normal play direction. When used as a verb ("the intervalbegins"), begin and end refer to the current interval becoming active andinactive, respectively. Intervals are described as playing from theend of the interval to thebeginning, and so theybeginat the interval end, andend at the interval begin.
When a time container is defined to play backwards, a child element maydefine additional time manipulations that affect the speed, or even thedirection of play. Any such additional time manipulations on the childelement do not impact the model described above.
The life cycle is restarted each time the parent (or any ascendant) timecontainer repeats or restarts, just as for the normal play direction.
Because of the reversed evaluation of intervals, some cyclic timedependencies that would correctly propagate forwards when played normallywill not propagate correctly when played backwards. The rules for evaluatingand halting cycles in the time graph are unchanged by the semantics of timemanipulations.