previous next

Chapter 8: SMIL Basics

When your streaming presentation contains multiple clips—such as a video and streaming text played together—you use Synchronized Multimedia Integration Language (SMIL) to coordinate the parts. Pronounced "smile," SMIL is a simple but powerful markup language for specifying how and when clips play. This chapter introduces you to SMIL, its advantages, and its syntax rules.

Tip: For a streamlined introduction to basic SMIL features, download Introduction to Streaming Media from

For More Information: Once you are familiar with SMIL, you can refer to "Appendix D: SMIL Tag Summary" when you write your SMIL files.

Understanding SMIL

Recommended by the World Wide Web Consortium (W3C), SMIL is designed to be the standard markup language for timing and controlling streaming media clips. SMIL works for a media player similar to the way that HTML works for a Web browser. And just as HTML markup displays in any browser, the standardized SMIL language fosters interoperability between media players. You can find the official SMIL 2.0 specification at the W3C Web site:

For More Information: To learn more about multiplayer support, read "Interoperability Between SMIL-Based Players".

Advantages of Using SMIL

SMIL enables you to create complex media presentations without using scripting languages such as Javascript. Because scripting is not required, you do not have to embed SMIL presentations in a Web page. Additionally, SMIL presentations can play in RealPlayers that reside on consumer devices that do not include browsers. The following points explain a few of the major advantages of using SMIL:

SMIL 1.0 and SMIL 2.0

SMIL 1.0 debuted in 1998. SMIL 2.0, introduced in 2001, updates and expands the SMIL 1.0 capabilities. RealOne Player through RealPlayer 10 can play SMIL 1.0 files and SMIL 2.0 files. RealPlayer G2, RealPlayer 7, and RealPlayer 8 can play only SMIL 1.0 files, though. If these older RealPlayers encounter a SMIL 2.0 file, they autoupdate to RealPlayer 10 before displaying the presentation. However, as described in "Combining SMIL 2.0 with SMIL 1.0", you can add SMIL 2.0 features to a SMIL 1.0 file that still plays in RealPlayer 7 or 8.

Note: This guide describes SMIL 2.0 only. For information on SMIL 1.0, see RealSystem iQ Production Guide for Release 8.

SMIL 2.0 Modules

SMIL defines a number of functional areas, such as timing and hyperlinking. Each functional area breaks down into one or more modules. In turn, each module defines certain attributes and values. The following table lists all the SMIL 2.0 modules, and indicates whether RealPlayer supports them. You may find this information useful if you are familiar with the SMIL 2.0 specification. You do not need to know this information to create a SMIL 2.0 presentation that plays in RealPlayer, however.

SMIL 2.0 Supported Modules
Functional Area Module Supported? Reference
Timing AccessKeyTiming yes click here
BasicInlineTiming yes click here
BasicTimeContainers yes click here
EventTiming yes click here
ExclTimeContainers yes click here
FillDefault yes click here
MediaMarkerTiming yes click here
MinMaxTiming yes click here
MultiArcTiming yes click here
RepeatTiming yes click here
RepeatValueTiming yes click here
RestartDefault yes click here
RestartTiming yes click here
SyncbaseTiming yes click here
SyncBehavior yes click here
SyncBehaviorDefault yes click here
SyncMaster no n/a
TimeContainerAttributes yes click here
WallclockTiming yes click here
Time Manipulations TimeManipulations yes (animations only) click here
Animation BasicAnimation yes click here
SplineAnimation no n/a
Content Control BasicContentControl yes click here
CustomTestAttributes no n/a
PrefetchControl yes click here
SkipContentControl yes tbd
Layout AudioLayout yes click here
BasicLayout yes click here
HierarchicalLayout yes click here
MultiWindowLayout yes click here
Linking BasicLinking yes click here
LinkingAttributes yes click here
ObjectLinking no n/a
Media Objects BasicMedia yes click here
BrushMedia yes click here
MediaAccessibility yes click here
MediaClipping yes click here
MediaClipMarkers yes click here
MediaDescription yes click here
MediaParam yes click here
Metainformation Metainformation yes tbd
Structure Structure yes click here
Transitions BasicTransitions yes click here
InlineTransitions no n/a
TransitionModifiers yes click here

SMIL 2.0 Profiles

SMIL also defines profiles, which are collections of modules that an application can support. RealPlayer supports the SMIL 2.0 Language Profile, which incorporates most of the SMIL modules listed in the preceding section. The other main profile is the SMIL 2.0 Basic Profile, which is designed primarily for smaller devices, such as mobile phones and portable disc players. The basic profile requires support for only the following modules:

Interoperability Between SMIL-Based Players

Because SMIL is an standard markup language, any media player can adopt SMIL as its means for coordinating media clips. Although this allows interoperability between SMIL-based media players, it does not automatically mean that every presentation created for RealPlayer can play in other SMIL- based media players, and vice versa. The following sections explain differences in SMIL presentations that may prevent them from playing in all SMIL-based players.

SMIL Version

SMIL 1.0 and SMIL 2.0 differ significantly. Although most media players that support SMIL 2.0 (including RealPlayer) can also play SMIL 1.0 files, media players that support only SMIL 1.0 (including RealPlayer G2, RealPlayer 7, and RealPlayer 8) cannot play SMIL 2.0 content. Be sure you know whether your target media players support SMIL 1.0, SMIL 2.0, or both.

SMIL Profile

As described in "SMIL 2.0 Profiles", a SMIL-based media player can support different SMIL profiles. A media player that supports only the smaller module set of the SMIL 2.0 Basic Profile will not handle all of the attributes defined in the more robust SMIL 2.0 Language Profile. Hence, a presentation developed for RealPlayer may not play to its full capacity in a player based on the SMIL 2.0 Basic Profile. That player should just ignore the SMIL attributes it does not support, however.

Clip Support

SMIL binds different types of clips together, and each SMIL-based media player must also be able to play the presentation's clips, regardless of the player's support for SMIL. For example, RealAudio and RealVideo clips are proprietary formats that play only in RealPlayer. For interoperability, you must stream clips that all of your various target media players can play.

Note: Although RealPlayer can play proprietary formats used by other media players, such as Windows Media and QuickTime, it does not support the use of SMIL with these formats. When streaming one of these formats to RealPlayer, you must author presentations using the markup conventions supported by Windows Media Player or QuickTime Player, respectively.

Media Player Launch Methods

Viewers typically launch streaming media presentations through a Web page hyperlink configured to start a specific player. For example, Web pages that launch RealPlayer link to a Ram file (extension .ram), rather than to a SMIL file. If you link directly to the SMIL file, the application registered with the browser to handle the file extension .smil launches and attempts to play the presentation. This is not recommended, however, because the launched application may not be one of your target media players.

Tip: RealNetworks recommends that, even with a single SMIL file that plays in multiple media players, you create a separate Web page hyperlink to launch each of your target players. Your viewers can then decide which player they want to use.

For More Information: For more about starting RealPlayer with a Web page hyperlink, refer to "Launching RealPlayer with a Ram File".

Creating a SMIL File

This section explains the basics of SMIL markup, introducing you to the rules you need to follow when creating a SMIL presentation. If you are familiar with other Web-based markup languages, such as HTML, you will pick up SMIL quickly. You need to be careful, though, because SMIL is less forgiving than HTML. Lapses that may not matter in HTML markup, such as missing quotation marks, missing slashes, or missing end tags, will prevent a SMIL file from working properly.

Tip: You can write a SMIL file with any text editor that can save the file as plain text. Save the file with the file extension .smil. Do not include spaces in the file name.

Note: With many Web servers, you can use GZIP encoding for large SMIL files. For more information, see "GZIP Encoding for Large Text Files".

View it now! (requirements for viewing this sample)
This sample explains the basic aspects of writing a SMIL 2.0 file.

The SMIL 2.0 Tag and Namespace

Rule 1: To create SMIL 2.0 files as described in this guide, the <smil> tag must include the XML namespace for SMIL 2.0.

A SMIL file starts with a <smil> tag and ends with a </smil> tag. If the opening tag is just <smil>, the file is SMIL 1.0:

...SMIL 1.0 markup...

To create a SMIL 2.0 file and use all the SMIL features described in this guide, the <smil> tag must look like the following:

<smil xmlns="">
...SMIL 2.0 markup...

SMIL is based on Extensible Markup Language (XML), which provides the means for defining any number of standard or customized markup languages. The xmlns attribute shown above defines an XML namespace. This namespace has just one purpose: to tell RealPlayer that the file is SMIL 2.0 rather than SMIL 1.0. The namespace identifier is in the form of a URL only to ensure uniqueness. RealPlayer does not contact the URL.

Header and Body Sections

Rule 2: A SMIL body section is required, but the header section is optional.

Between the <smil> and </smil> tags, a SMIL file breaks down into two basic subsections: the header and the body. The header is defined between <head> and </head> tags, while the body section falls within <body> and </body> tags, as shown here:

<smil xmlns="">
...optional section with all header markup...
...required section with all body markup...

The optional header section is used to give presentation information, to create the layout, and to define features that are used repeatedly. To include a fade- to-black transition effect in your presentation, for example, you first define the transition type in the header. You can think of the header as defining your presentation's form.

The header section is optional because it's not needed for very simple SMIL files. The following SMIL presentation, for example, simply plays three audio clips in sequence. Although the presentation could have a header section that provides presentation information, it doesn't need a layout or any other features that must be defined in the header:

<smil xmlns="">
<audio src="rtsp://"/>
<audio src="rtsp://"/>
<audio src="rtsp://"/>

Within the required body section, you list the clips that you want to play, creating your presentation timeline in the process. Within the body section, you apply the features you defined in the header. For instance, you apply a fade-to-black transition defined in the header to clips listed in the body. You can think of the body as defining your presentation's content and timeline.

The header and body may each have their own subsections. The header may have a layout section defined between <layout> and </layout> tags, for example, while the body section uses <par> and </par> tags to define clips that play together. Other chapters in this guide describe the tags that you can use within the header and body sections.

Tags, Attributes, and Values

Both the header and body of a SMIL file contain tags that have the following form:

<tag attribute="value"/>

Aside from the angle brackets and a possible closing slash, there are three basic parts to a SMIL tag:

tag The tag name comes just after a left angle bracket. Some tags may consist of just the name, as in the <body> tag. Other tags may have attributes.
attribute Each attribute defines one aspect of the tag. If a tag has several attributes, the order of attributes doesn't matter.
"value" Most SMIL attributes include an equals sign (=) followed by a value in double quotation marks. In some cases, you choose from a list of predefined values. In other cases, you define your own value. Values may be integers, percentages, names, and so on, depending on what types of values are appropriate for the attribute.

Rule 3: Lowercase or camel case text is required for most tags and attributes.

SMIL tags and attributes must be lowercase. When an attribute or predefined value consists of a compound word, the first letter of all words after the first word is generally capitalized, as in soundLevel or whenNotActive. This is referred to as "camel case."

A few attributes, such as root-layout, are hyphenated. These attributes carry over from SMIL 1.0. They have been kept the same for consistency. Some new SMIL 2.0 attributes, such as accesskey, are meant to be compatible with HTML 4.0 and, in accordance with the HTML 4.0 specification, do not capitalize letters in compound words.

Rule 4: Attribute values must be enclosed in double quotation marks.

Attribute values, such as video_region in region="video_region", must be enclosed in double quotation marks. Do not add any blank spaces between the quotation marks and the value they enclose.

Rule 5: File names and paths must observe letter cases.

In clip source tags, paths and file names can be uppercase, lowercase, or mixed case. All of the following path and file name examples are allowable, for example:

<audio src="rtsp://"/>
<audio src="rtsp://"/>
<audio src="rtsp://"/>

However, the path and file name in the tag should match the clip's path and file name exactly as it appears on the server computer's operating system. For instance, the following clip source tag may not work if the clip is actually named SONG.rm:

<audio src="rtsp://"/>

Binary and Unary Tags

Rule 6: All tags must have an end tag or close with a forward slash.

Some SMIL tags, called binary tags, have a corresponding end tag. For example, the <body> tag has the end tag </body>. When a tag has no corresponding end tag, it is called a unary tag, and it must close with a forward slash as shown in this example:

<audio src="first.rm"/>

Warning! Omitting a closing slash where it's needed, or adding it where it's not required is one of the easiest ways to create an error in a SMIL file. Take care always to include a closing slash with a unary tag, and to leave it out of the first tag in a binary pair.

Changing a Unary Tag to a Binary Tag

Several SMIL tags can be either binary or unary, depending on how they operate. For example, a unary <video/> tag plays a video clip:

<video ...specifies a video to play, and closes with a forward slash... />

However, you can also include a hyperlink with <video/> tag to link the clip to another clip or a Web page. To do this, you change the <video/> tag from unary to binary so that it can enclose an <area/> tag, as shown here:

<video ...specifies a video to play, and uses an end tag... >
<area ...defines an image map, and closes with a forward slash... />

This guide tells you which tags can be both unary and binary, and explains the circumstances under which you use the unary or binary version.

SMIL Recommendations

Although not strict rules, the following recommendations will help you keep your SMIL markup organized and understandable.

Recommendation 1: Use HTML-style comments to annotate your SMIL file.

As in HTML, SMIL has a comment tag that starts with these characters:


and ends with these characters:


The ending does not include a forward slash:

<!-- This is a comment -->

A comment can be any number of lines long. It can start and end anywhere in a SMIL file. Multiple comments cannot be nested, though. Use comments to describe what various sections of your SMIL presentation are meant to do. This helps other people understand your presentation more easily.

Recommendation 2: Use indentation to clarify how your SMIL file is organized.

Although indenting SMIL markup is not required, it helps you to keep track of the SMIL file's structure. You typically indent markup by pressing the Tab key once for each level of indentation. In a clip group, for example, the group tags are indented one level from the body tags, and the clip tags are indented one level from the group tags, as shown here:

<audio src="rtsp://"/>
<audio src="rtsp://"/>

SMIL Tag ID Values

Any SMIL tag can have an ID in the form id="value". Some SMIL tags require IDs. For example, each region in the layout requires an ID that you use to assign clips to play in the region. For other tags, IDs are optional depending on whether another SMIL element interacts with that tag. The following are rules and suggestions that apply to the IDs of all SMIL tags:

Using Customized SMIL Attributes

SMIL can be customized, and RealNetworks has developed many extensions to SMIL 2.0 functionality. SMIL regulates how customizations can be added, though, to avoid potential conflicts between different media players. A customized attribute always has a prefix, and takes the following form:


The prefix is user-defined, but the attribute name is always predefined. The following is an example of RealNetworks' backgroundOpacity attribute, using a prefix of rn:


When RealPlayer encounters this tag, it recognizes that backgroundOpacity is a valid attribute, but not a standard SMIL attribute. It uses the rn prefix to match the attribute to a namespace declared in the <smil> tag. The namespace must therefore use the same user-defined prefix as the attribute. You can add the additional namespace to the <smil> tag after the SMIL 2.0 namespace:

<smil xmlns="" 

If RealPlayer recognizes the namespace, it knows how to handle the customized attribute. This allows RealPlayer to support any number of customized attributes developed by RealNetworks or other parties.

RealNetworks Extensions Namespace

RealNetworks has created many customized attributes that you can use in SMIL 2.0 files played in RealPlayer. To use these attributes, you must declare the following namespace in the <smil> tag:


This guide always uses rn: as the attribute prefix for RealNetworks extensions. If you decide to use a different prefix, it's best to use a short, single word, or just a few letters.

System Component Namespace

The system component namespace allows you to mark elements that should play only in RealPlayer. This lets you add SMIL 2.0 elements to a SMIL 1.0 presentation that can still play in RealPlayer 7 or 8. Unlike SMIL 2.0 namespaces, this namespace requires the use of the cv prefix:


For More Information: See "Combining SMIL 2.0 with SMIL 1.0" for an explanation of how to use this namespace.

A Closer Look at Namespaces

Namespaces and prefixes for customized attributes are not hard to declare and use, but they can be confusing at first if you are not familiar with XML. The following sections delve more deeply into namespaces and their associated prefixes for those who want a better understanding of this issue. When in doubt, though, just follow the examples in this guide, using the given prefixes when defining a namespace and a custom attribute.

Why does SMIL use namespaces?

Each customized attribute is defined in conjunction with a unique namespace so that SMIL-based media players can use different attributes that happen to have the same name. An attribute named find might perform one function when defined with one namespace, and a different function when defined with another namespace. This allows different parties to create customized SMIL attributes without being concerned about duplicate attribute names.

Why are prefixes used?

A prefix ties an attribute to a namespace. Consider the example of two different find attributes in the same SMIL file. When RealPlayer has to interpret what a particular find attribute does, it matches the attribute to its namespace through the prefix. If there were no prefix, RealPlayer would not know which namespace goes with which attribute.

Why are prefixes user-definable?

If the parties who developed custom attributes also defined specific prefixes, there could be duplicate attribute names and prefixes that RealPlayer could not resolve. Suppose that two parties developed two new SMIL attributes, both called fd:find, but each defined against a different namespace. If you used both fd:find attributes in your presentation, RealPlayer would not know which attribute goes with which namespace.

Because prefixes are user-definable, though, you could change the prefix for one of the attributes, making it xy:find, for example. You would then use the same xy prefix in the associated namespace so that RealPlayer could match each find attribute to its namespace. This provides flexibility for parties developing customized attributes, but it also places responsibility on the SMIL author to match customized attributes to namespaces through prefixes.

Tips for Defining Namespaces

Viewing SMIL Source Markup

RealPlayer has a File>Clip Properties>Clip Source command that shows the SMIL markup of the current presentation. Using this command is a good way to learn how a SMIL presentation is put together. The Helix Server or Web server hosting the presentation sends the markup as an HTML page that opens in a RealPlayer pane, or your default Web browser.

Access to SMIL source information is denied for secure presentations that require a user name and password. The Helix Server administrator may also disallow access to the SMIL source file, or allow access to the source file but conceal the full paths of clips. When access is allowed, the Web page showing the SMIL syntax includes a hypertext link for each clip in the presentation. Clicking a link displays a new Web page with information about the corresponding clip, including its size, buffer time, and streaming bit rate.

Playback Differences from SMIL 1.0

If you have created SMIL 1.0 presentations for playback in RealPlayer G2, RealPlayer 7, or RealPlayer 8, this section will help bring you up-to-date with changes in SMIL 2.0.

Behavioral Changes

The SMIL 2.0 specification requires changes to RealPlayer's handling of some basic features that carry over from SMIL 1.0:

Updating SMIL 1.0 Files to SMIL 2.0

A SMIL 1.0 presentation created for an earlier version of RealPlayer will play in RealOne Player or later. If you want to update a SMIL 1.0 presentation to SMIL 2.0, however, you have to change the <smil> 1.0 tag to a SMIL 2.0 tag:

<smil xmlns="">

The following table provides a quick reference for changing other SMIL 1.0 tags and attributes to their SMIL 2.0 equivalents. Once you make these changes, you can add any other SMIL 2.0 features to your presentation. Your SMIL file will play only in RealOne Player or later, however.

Tag and Attribute Changes from SMIL 1.0 to SMIL 2.0
SMIL 1.0 Element SMIL 2.0 Tag or Attribute Reference
Layout Tags and Attributes
background-color backgroundColor click here
Clip Source Tags and Attributes
?bitrate=nnnn <param name="bitrate" value="nnnn" rn:delivery="server"/> click here
?reliable=true <param name="reliable" value="true" rn:delivery="server"/> click here
?bgcolor=RRGGBB <param name="bgcolor" value="RRGGBB"/> click here
Timing Tags and Attributes
repeat repeatCount click here
clip-begin clipBegin click here
clip-end clipEnd click here
endsync="id(ID)" endsync="ID" click here
Hyperlinking Tags and Attributes
<anchor/> <area/> click here
show="new" external="true" sourcePlaystate="play" click here
show="pause" external="true" sourcePlaystate="pause" click here
target="ID" URL#ID click here
Switch Tag Attributes
system-bitrate systemBitrate click here
system-language systemLanguage click here
system-captions systemCaptions click here

RealNetworks, Inc. ©2002, 2004 RealNetworks, Inc. All rights reserved.
For more information, visit RealNetworks
Click here if the Table of Contents frame is not visible at the left side of your screen.
previous next