The World Wide Web Consortium’s Synchro-nized Multimedia Integration Language for-

mat for encoding multimedia presentations fordelivery over the Web is a little-known but widelyused standard. First released in mid-1998, SMILhas been installed on approximately 200,000,000desktops worldwide, primarily because of its adop-tion in RealPlayer G2, Quicktime 4.1, and Inter-net Explorer 5.5. In August 2001, the W3Creleased a significant update with SMIL 2.0.1

In a two-part report on SMIL 2.0, I will discussthe basics of SMIL 2.0 and compare its featureswith other formats. This article will focus onSMIL’s basic concepts and structure. Part two, inthe January–March 2002 issue, will look atdetailed examples of SMIL 2.0, covering both sim-ple and complex examples. It’ll also contrast thefacilities in SMIL 2.0 and MPEG-4.

Design goalsWe can partition the goals for SMIL 2.0’s

design across three broad categories:

❚ Extend SMIL 1.0’s functionality. The designers ofSMIL’s first version purposefully kept the lan-guage simple and relatively frills-free. SMIL 2.0provides some desirable additions, includingsupport for increased interaction, enhancedtiming semantics, extended content controland layout facilities, and new animation andtransitions primitives.

❚ Maintain a declarative, XML format. Althoughintegrating multimedia content is its mainfunction, SMIL 2.0 was developed to remain afully declarative rather than a procedural for-mat. Therefore, a SMIL description doesn’tdefine how to implement a presentation butleaves the specification’s implementation upto the SMIL player. Also, in keeping withSMIL’s first version, SMIL 2.0 is fully XML-compliant.

❚ Introduce a module-based structure. SMIL 1.0 wasa simple, 29-page specification, but SMIL 2.0has more than 50 modules (in more than 500pages) that users can partition into 13functional groups. Using a module structure,we can integrate key aspects of SMIL 2.0 intoother XML-based languages without requiringsupport for the entire SMIL 2.0 specification.Even before the SMIL 2.0 languagespecification’s release, parts of SMIL have beenintegrated into several other XML languages(such as Scalable Vector Graphics), and we canexpect more examples of module reuse.

As of this summer, several commercial versionsof SMIL 2.0 were available. Oratrix released thefirst, its Grins SMIL 2.0 player (http://www.oratrix.com/GRiNS), in September 2000.2 Majormass-market media companies such as RealNet-works and Microsoft have also announced sup-port for all or some of SMIL 2.0’s features. TheThird Generation Partnership Project (3GPP) con-sortium, the standardization body coordinatingthe deployment of next-generation wirelessdevices, recommended that industry use SMIL 2.0as the basis for wireless multimedia devices.

What it isn’t (and is)Often, multimedia presentations are charac-

terized by their content rather than their compo-sition. Because of this, there has been someconfusion about what a SMIL presentation is andisn’t. It’s easy to summarize what SMIL 2.0 isn’t:

❚ SMIL 2.0 isn’t a Flash substitute. Flash (http://www.macromedia.com/flash) is a proprietarycontent media type that is primarily used forsmall animations. SMIL 2.0 isn’t a contentmedia type because it doesn’t define any par-ticular type of media (such as vector or rasterimages, videos, text, or audio data). Instead ofmedia content, SMIL describes media compo-

82 1070-986X/01/$10.00 © 2001 IEEE

Standards Editor: Peiya LiuSiemens Corporate Research

Dick C.A.Bulterman

OratrixDevelopment, The

Netherlands

SMIL 2.0Part 1: Overview, Concepts, and Structure

sition. A SMIL presentation can include Flashobjects.

❚ SMIL 2.0 isn’t an MPEG-4 substitute. MPEG-4 is ahighly touted (but lightly implemented anddeployed) format for describing a media object’scontent and interaction.3 More precisely,MPEG-4 is a family of protocols that covers awide range of media-related concerns but not aspecific solution to any one class of media pre-sentation. As we’ll see, researchers have doneconsiderable work to coordinate the develop-ment of SMIL 2.0 and MPEG-4 through theExtensible MPEG-4 Textual (XMT)4 formatspecification.

❚ SMIL 2.0 isn’t a Dynamic HTML5 substitute. D-HTML was introduced as a way to introducelocal time and animation effects into staticHTML Web pages. Although some of theanimation primitives in SMIL 2.0 resemble thefunctionality of some D-HTML uses, SMIL’sscope is much broader than the local nature ofD-HTML.

What is SMIL 2.0 then? It’s a collection of XMLelements and attributes that we can use todescribe the temporal and spatial coordination ofone or more media objects. SMIL 2.0 lets usersdefine how independent media objects should beintegrated during a presentation’s lifetime. Forexample, that presentation may be delivered via astreaming server or played locally.

SMIL 2.0 defines 10 major functional groupingsof elements and attributes (see Figure 1). Of these,the timing and synchronization grouping is thecore of the SMIL specification. The functionalgroupings represent collections of individual SMIL2.0 modules, each of which defines elements andattributes intended to address specific multimedia

issues in a reusable manner. The number of mod-ules per functional grouping varies from two toabout 20. Generally, the more modules per group-ing the finer each module’s granularity.

SMIL 2.0’s developers intended for its modu-larization to facilitate the reuse of SMIL function-ality in other XML languages and help define anumber of SMIL profiles. Each profile provides acollection of modules that users can customize toits primary goal. The initial partitioning of SMIL2.0 profiles includes SMIL 2.0 language, SMILbasic, and XHTML+SMIL. Of these, the SMIL 2.0language and basic profiles completed therequired review and implementation require-ments of the W3C for the summer 2001 release ofSMIL 2.0. The XHTML+SMIL profile,6 which inte-grates SMIL timing, animation, and transitionsmodules (among others) into XHTML, wasn’tcompleted and remains under development bythe W3C. In addition to the three SMIL profiles,W3C also released a version of SMIL Animation inJuly 2001 for final review by its members.

Structure, timelines, and SMILA SMIL presentation is a structured composi-

tion of autonomous media objects. As Figure 2(next page) shows, we can use three basic timingcontainers in a SMIL presentation:

❚ seq, or sequential time container. A seq con-tainer’s children are rendered so that a succes-sor child can’t begin before its predecessorchild completes. A successor child might havean additional start delay, but this delay can’tresolve to be negative in relation to the endtime of its predecessor. (See Figure 2a).

❚ par, or parallel time container. A par contain-er’s children are all rendered in parallel. Interms of a SMIL’s timing model, this doesn’t

83

Octo

ber–D

ecemb

er 2001

Animation Contentcontrol Layout Linking Media

objects

Meta-information Structure Time

manipulation TransitionsTiming andsynchronization

Figure 1. SMIL 2.0’s

functional grouping of

module sets.

mean that they get rendered at the same timebut that they share a common timebasedefined by the par container, and any or all ofthe children can be active at any time that theparent par is active. The par is the most gener-al SMIL time container. (See Figure 2b).

❚ excl, or exclusive time container. Only one of thechildren of an excl can be active at a time. Thechildren’s activation order depends on the beginattribute of the excl’s children. Typically, eachwill have an event-based start condition (such asbegin=“button1.activateEvent”) that letsone of the children start on demand. The exclcontainer is new in SMIL 2.0. (See Figure 2c).

We can nest the three basic time container typesin a presentation hierarchy. That is, any child of apar, seq, or excl can be a simple media object or anembedded par, seq, or excl container. As in SMIL1.0, the hierarchy can represent relatively static pre-sentation timing. Introducing event-based activa-tion or termination in SMIL 2.0 also lets usersdefine a dynamic activation path. Note that mostother multimedia formats only support a par-likesemantic, not the seq or excl semantics.

A fundamental property of multimedia presen-tations is that they contain media objects requir-ing some notion of time for correct presentation.To model presentations, we often use a timelinemetaphor. To understand SMIL 2.0, we can apply

the timeline metaphor to containers that holdonly static objects for which we know all timinginformation (including activation time, termina-tion time, and object duration) at the time ofauthoring. For containers like the excl where theactivation or termination time is unknown untilthe object actually starts, or for par’s containingobjects with unresolved begin or end times, thetimeline metaphor is essentially useless. While thispresents a challenge to authoring software design-ers, it provides a SMIL 2.0 document with unprece-dented temporal flexibility and adaptabilitybecause the effective presentation timeline is deter-mined at runtime, based on the individual mediaobjects activated and their activation order.

Unlike media formats that force users to explic-itly define when each object begins and ends rel-ative to a single timeline, SMIL provides a logicaltiming framework in which we can use the struc-tured relationship of objects to define most tim-ing relationships among objects.7 When writing aSMIL file, authors don’t have to worry about theexact starting or ending times because these canbe gleaned from the presentation’s par, seq, andexcl structure. In a SMIL specification, the objects’structured composition determines the timeline,rather than the timeline being the basic composi-tional unit.

The decoupling of timing resolution from apresentation specification lets, for example, a pre-sentation’s entire timing be changed based on the

84

IEEE

Mul

tiM

edia

Standards

<seq>

<img id="a" dur="6s"

begin="0s" src="..." />

<img id="b" dur="4s"

begin="0s" src="..." />

<img id="c" dur="5s"

begin="2s" src="..." />

</seq>

<par>

<img id="a" dur="6s"

begin="0s" src="..."/>

<img id="b" dur="4s"

begin="0s" src="..."/>

<img id="c" dur="5s"

begin="2s" src="..."/>

</par>

<excl>

<img id="a" dur="6s" src="..."

begin="0s;x.activateEvent" />

<img id="b" dur="4s" src="..."

begin="y.activateEvent" />

<img id="c" dur="5s" src="..."

begin="z.activateEvent" />

</excl>

(a) (b) (c)

a b c

seq

t

a

b

cpar

t

t

a

t

b

t

cexcl

Figure 2. SMIL 2.0 time containers. (a) A SMIL seq container plus a SMIL 2.0 code fragment. Note that begin times are relative to the

predecessor’s end. (b) A par container, with the same timing offsets. Note that begin times are relative to the containing par. (c) An excl

container. Object a starts at time 0 of the excl and whenever object x (not shown) is activated. Objects b and c start only when objects

y and z (not shown) are activated. Because the actual activation times depends on event activity, we can’t use a common timeline to

model the relationships among a, b, and c.

content’s dynamic associations. Consider the fol-lowing SMIL 2.0 code fragment:

<par endsync=“select”>

<img id=“btn_a” src=“...” dur=“10s” />

<img id=“btn_b” src=“...” dur=“5s” />

<excl id=“select”>

<text src=“.../todays_txt.html”

begin=“btn_a.activeEvent”

dur=“25s”/>

<video src=“.../todays_video.mpg”

begin=“btn_b.activeEvent” />

</excl>

<audio src=“.../todays_tune.mp3”

repeat=“indefinite”/>

</par>

The outer par contains two button images(btn_a and btn_b), an audio object reference,and an excl container (named select). The exclcontains text and video object references. Notethat each of the media object references is indi-rect: they point to external data that can changeon a hourly, daily, or weekly basis.

The button images display for 10 and 5 sec-onds, respectively, when the par starts. The back-ground music also begins and repeatsindefinitely—that is, it repeats until the contain-ing par ends. Because the par contains the direc-tive endsync=“select”, it will end when theselect object ends. The select object endswhen either the text or the video object ends,depending on which one the presentation vieweractivates. (If the viewer selects btn_a, the textobject will show for 25 seconds; if the viewerselects btn_b, the video object will play for thatobject’s intrinsic duration, whatever that is.) Allthe while, the background music keeps repeating.

SMIL 2.0 timing and synchronizationThe timing and synchronization functional

group represents the core of SMIL 2.0 functional-ity. The group consists of 19 modules, each ofwhich defines a collection of XML elements andattributes that control some timing aspect.

We’ve already discussed the three basic SMIL2.0 timing elements seq, par, and excl. Each ofthese elements form parent timing containers inwhich we can place media objects or other timingcontainers. For any content within a container(whether a media object or structure container),these are the primary issues:

❚ When does the element begin?

❚ How long is it active?

❚ What happens to it when it’s no longer active?

❚ Other than strict temporal, are there otherconditions that cause an element to end?

We answer these questions by specifying a set ofattribute values on either the parent time con-tainer or any of its children. SMIL 2.0 has anextensive set of attributes to control timing, mostof which carry sane defaults so that we can easilyaccomplish basic timing and synchronizationoperations.

Figure 3 gives the basic collection of timingand synchronization attributes. Note that not allthe SMIL 2.0 profiles support all the attributes,and the syntax of defining and setting theattribute values can vary, but the core functional-ity of timing, extended activation control, objectpersistence, and repeating element control are rea-sonably universal. A design objective of SMIL 2.0was that each attribute should have a well-definedsemantic that remains constant across profiles.

Begin, end, and durThe begin and end attributes are similar in

terms of syntax and semantics. The primary dif-ferences between these attributes in SMIL 1.0 andSMIL 2.0 is that SMIL 2.0 lets us specify multiplevalues for begin and end. (Figure 2 shows an exam-ple of this.) The first satisfied begin/end value willcause a corresponding element to start or end. It’spossible to mix both scheduled and event-basedactivation/termination in one attribute. For exam-ple, begin=“3s;button.activateEvent” willcause the associated element to start either at 3 sec-onds after the default time at which the elementwould otherwise be able to start, or when theactivateEvent event associated with anotherelement with an ID of button occurs (typically viaa mouse click). (The default begin time varies with

85

Octo

ber–D

ecemb

er 2001Timing control - begin

- end

- dur

Extended activation - endsync

- min

- max

Object persistence - fill

Repeating control - repeatCount

- repeatDur

Synchronization - syncBehavior

- syncTolerance

- syncMaster

XML timing integration - timeContainer

- timeAction

Figure 3. Primary

SMIL 2.0 timing and

synchronization

attributes.

the parent time container. For a par and excl, it’swhen the container starts. For a seq, it’s when theprevious element in the seq ends or the first childelement starts.)

Once started, an element will have a certainduration, which we can determine in severalways (see Figure 4). Generally, so-called discretemedia (media without an inherent notion oftime, such as images or a page of text) have adefault 0-second duration, and continuousmedia (media with an inherent notion of dura-tion, such as an audio or video object) use thatinherent duration as a default. (Some implemen-tations of SMIL 1.0 used 5 seconds for the defaultduration of a discrete-media item. All SMIL 2.0implementations should use the real defaultvalue of 0.)

An object with a 0-second duration wouldn’tordinarily be visible during a presentation. Suchobjects can be displayed if the fill attribute is setto a value of “freeze.” A frozen object is displayedafter the end of its active duration until its parenttime container ends. For discrete media, this willbe the image or text, for continuous media, it willbe the last frame or sample. Consider this:

<par dur=“10s”>

<img begin=“3.5s” fill=“freeze”

src=“...” />

</par>

It will display an image 3.5 seconds after the par-ent par begins. The object’s active duration will be0 seconds, but the object will remain visible for6.5 seconds (until the parent par ends). Two fill

values define a render-ing duration thatextends beyond theparent: transition andhold.

As in SMIL 1.0, if apar has multiple chil-dren active, it can spec-ify that the entire parends when the firstchild ends, the lastchild ends, or a namedchild ends. We do thiswith the endsync

attribute. (The defaultis endsync=“last”.)

SMIL 2.0 has twonew attributes that pro-vide extra duration

control: min and max. We can use these attributes,which developed out of the SMIL 2.0 and MPEG-4 integration work, to define a lower or upperbound on the active duration, regardless of thatelement’s timing characteristics.

What goes around, comes aroundThe default behavior of all elements is that

they play once, for either an implicit or explicitduration. The SMIL 2.0 repeatCount attributelets an iteration factor be defined that acts as amultiplier of the object’s simple duration. We canuse a special value indefinite to specify that anelement repeat continually until the parent timecontainer ends. (Although it’s tempting to definethis as forever, this isn’t correct: the parent timecontainer defines the context of indefinite.) TherepeatDur attribute defines a duration for all therepeated iterations.

Synchronization behaviorIn a perfect world, a SMIL 2.0 player would per-

fectly implement all the defined timing in a spec-ification. Unfortunately, the world is imperfectand unpredictable. To provide some measure ofcontrol in the face of unpredictably, SMIL 2.0 pro-vides three high-level synchronization controlattributes:

❚ syncBehavior lets a presentation definewhether there can be slippage in implement-ing the presentation’s composite timeline,

❚ syncTolerance defines how much slip isallowed, and

86

IEEE

Mul

tiM

edia

Standards

<audio src="x.rm" />

repeatCount="2" fill="freeze" />

<audio src="x.rm" dur="6s" />

<audio src="x.rm" dur="6s"

<audio src="x.rm" dur="6s"

Inherent duration

Simple duration

Active duration

Rendered duration

repeatCount="2" />

t

Figure 4. Various SMIL 2.0 duration concepts. (a) The inherent duration is the duration of the media

object, if any. In this example, the inherent duration is 4 seconds. (b) The simple duration is the inherent

duration modified by the dur attribute. (c) The active duration is the simple duration modified by the

repeatCount (and repeatDur) attributes. (d) The perceived duration is an element’s visual behavior after

its active duration and before its parent time container ends.

❚ syncMaster lets a particular element becomethe master timebase against which all othersare measured.

XML integrationWhen used in a native SMIL 2.0 document

(one in which the outer XML tag is <smil>), thenature and meaning of various timing elements isclear. When integrating SMIL timing into otherXML languages, we require a mechanism to iden-tify timing containers. The SMIL 2.0 specificationdoes this using the timeContainer and timeAc-tion attributes.

Events and hyperlinkingIn the normal course of processing, a SMIL 2.0

document’s activation hierarchy determines therendering of document elements. The user caninfluence the elements selected by using SMIL 2.0events. The event architecture lets document com-ponents that are waiting be activated or terminat-ed to actually start or stop. SMIL 2.0 allows severaluses of events, but the most important new seman-tic in the language is the combination of events andthe begin and end attributes. In further combina-tion with the excl element, events provide a pow-erful mechanism for conditional content activation.

SMIL 2.0 also supports a rich hyperlinkingarchitecture. Unlike links in HTML or XHTML,the fundamental concept of the SMIL link is thatit models a temporal seek in a presentation.Rather than simply activating a target element,the target play state that is activated is identical tothe state that the presentation would have beenin if the target point had been arrived at naturally.(One exception is that all event-based activationis ignored.) This means that all nodes temporallybetween the link’s source and destination must beevaluated to see if they would have contributed tothe final target play state. The temporal seekingand activation facility allows polished presenta-tion construction, but its implementation in theplayer isn’t for the faint of heart.

Content control elements and attributesOne of the major innovations of SMIL is sup-

port for conditional content via the switch ele-ment:

<switch>

<video src=“...”

systemBitrate=“115200”/>

<seq systemBitrate=“57344”>

<img src=“img1.png” dur=“5s”/>

...

<img src=“img12.png” dur=“9s”/>

</seq>

<text src=“desc.html” dur=“30s”/>

</switch>

In this fragment, a video object is rendered if thesystem bit rate (actual or configured) is set at 112Kbytes or above. If the bit rate is 56 Kbytes or above,but below 112 Kbytes, a player shows a sequence ofimages instead. If no other element had been select-ed in the switch, a player shows a text object.

One of the SMIL 1.0 switch element’s limita-tions was that it only allowed selection based ona predefined list of system attributes. SMIL 2.0extends this notion with a user-defined set of testattributes: custom test attributes. The authorcan define the custom test attributes, and theuser can select them directly or indirectly via theplayer. SMIL 2.0 also lets test attributes be used in-line—that is, outside the switch element. Anymedia object reference containing a system orcustom test attribute will be evaluated as if itwere wrapped into a single-element switch.

To a first approximation, both the event mech-anism and the content control facilities provide ameans for dynamically selecting objects in a pre-sentation. The basic difference between thesefacilities is that the event mechanism works onobjects that the SMIL 2.0 scheduler recognizes,while the content control facility determineswhich object the scheduler gets to evaluate. Theactual selection process associated with the con-ditional control primitives can be static or dynam-ic. That is, the selection can be done at parse time(when the document is loaded) or at each itera-tion through the document. The specific selectionpolicy is a property of the SMIL player.

Transitions and animationSMIL 2.0 significantly extends the facilities

available for performing local operations on mediaobjects in a document. Two of the most visible ofthese are support for transitions and animation.SMIL’s transition support allows a set of basic tran-sitions to be defined as part of the SMIL head ele-ment and then to instance one of the availabletransition types as an input or output transition ona media object. For example, consider the SMIL 2.0fragment in Figure 5 (next page). We can applytransitions to all visual media or collections ofmedia. Each transition can have certain timingproperties (duration) and other transition-specificproperties (direction).

87

Octo

ber–D

ecemb

er 2001

Animation in SMIL 2.0 comes in two flavors.First, some animations apply to attributes and ele-ments in the SMIL presentation. This includes ani-mating the position of a rendering region or abackground color. A second type of animationsupport is the SMIL 2.0 animation specification,which gives generalized temporal animation sup-port for integration into XML languages.

LayoutUnlike HTML, which uses an indirect layout

model via cascading style sheets, SMIL also sup-ports a direct layout model for managing a pre-sentation’s visual and audio rendering space. InSMIL 2.0, the SMIL basic layout mechanism issupported with elements and attributes that letsusers specify layout as a hierarchy of renderingregions and support multiple top-level presenta-tion windows. Supporting hierarchical layout isespecially important when integrating animationinto a presentation. We can move content that islogically grouped together in concert by animat-ing the common parent region’s position. Multi-ple top-level windows let a single presentationsegment control and render operations in differ-ent parts of the screen in a coordinated manner.

Another enhancement to SMIL 2.0 layout isthe support for subregion positioning. This facili-ty lets users place an object at a particular (X, Y)offset within a region or aligned to a registrationpoint. (In SMIL 1.0, we had to place all objects ata region’s top left corner.) The placement occursin-line, as part of the media object reference. SMIL2.0 also supports an alignment mechanism forcontent in regions. This lets us center a set ofimages of varying size at a specific point in aregion. SMIL 2.0 also lets multiple objects beactive in a region simultaneously, relaxing arestriction from SMIL 1.0.

ConclusionThere are several places to obtain SMIL 2.0

players. The W3C maintains a Web site with linksto available players, editors, and other tools (seehttp://www.w3.org/AudioVideo/.) The facilitiesavailable in SMIL, combined with the increasingavailability of connection bandwidth, provideauthors with a new toolbox of presentation con-trol primitives. The diversity of expected futuredelivery environments (such as broadband, con-ventional modem, and wireless) demand such atoolbox so that we can build reusable and tailoredpresentations.

In part 2 of this article, we’ll look at how wecan use SMIL 2.0’s features to build various pre-sentations for multiple target platforms, includ-ing Microsoft’s IE-6, Real’s new RealONE player,and Oratrix’s Grins environment. MM

References1. J. Ayers et al., Synchronized Multimedia Integration

Language (SMIL) 2.0, World Wide Web Consortium

Recommendation, Aug. 2001, http://www.w3.org/

TR/2001/REC-smil20-20010807/.

2. D.C.A. Bulterman et al., “GRiNS: A GRaphical INter-

face for Creating and Playing SMIL Documents,”

Proc. 7th Int’l World Wide Web Conf. (WWW7), Elsevi-

er Science Publishers, Amsterdam, 1998.

3. R. Koenen, ed., ISO/IEC JTC1/SC29/WG11, Overview

of the MPEG-4 Standard, Int’l Organization for Stan-

dardization, Geneva, Mar. 2001.

4. M. Kim et al., “eXtensible MPEG-4 Textual Format,”

contribution to ISO-IEC JTC1/SC29/WG11

MPEG00/6110, Int’l Organization for Standardiza-

tion, Geneva, May 2000.

5. Dynamic HTML in Netscape Communicator, Netscape

Corp., http://developer.netscape.com/docs/manuals/

communicator/dynhtml, 1997.

6. D. Newman, P. Schmitz, and A. Patterson,

“XHTML+SMIL Profile,” W3C Working Draft, World

Wide Web Consortium, Aug. 2001, http://www.

w3.org/TR/2001/WD-XHTMLplusSMIL-20010807/.

7. L. Hardman, D.C.A. Bulterman, and G. van Rossum,

“Structured Multimedia Authoring,” Proc. ACM Multi-

media 93, ACM Press, New York, 1993, pp. 283-290.

Readers may contact Bulterman at Oratrix Development,

Amsterdam, The Netherlands, email Dick.Bulterman@

oratrix.com.

Contact Standards editor Peiya Liu, Siemens Corporate

Research, 755 College Rd. East, Princeton, NJ 08540, email

pliu@scr.siemens.com.

88

IEEE

Mul

tiM

edia

Standards

<?xml version="1.0" encoding="ISO-8859-1"?>

<smil xmlns="http://www.w3.org/SMIL20/Language">

<head>

<layout>

...

</layout>

<transition id="fade" type="fade" dur=î1sî/>

<transition id="push" type="pushWipe" dur=î0.5sî/>

</head>

<body>

...

<img src="..." transIn="fade"/>

...

<video src="..." transOut="push"/>

...

</body>

</smil>

Figure 5. Transitions

architecture in SMIL

2.0. We can define the

transitions in the head

section and reference

them in the body section

as either input or

output transitions.