When your streaming presentation contains multiple clipssuch as a video and streaming text played togetheryou 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 http://service.real.com/help/library/encoders.html.|
|For More Information: Once you are familiar with SMIL, you can refer to "Appendix D: SMIL Tag Summary" when you write your SMIL files.|
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".|
Because a SMIL file lists a separate URL for each clip, you can put together presentations using clips stored on any server. You can use a video clip on a Helix Server, for example, and an image clip on a Web server. Using SMIL eliminates the need to merge multiple clips into a single streaming file.
SMIL provides powerful timing features that let you easily manage your presentation's timeline. You can keep clips rigidly synchronized, for example, or start an audio clip playing at 2.5 seconds into its internal timeline without changing the encoded clip.
Using RealNetworks' extensions to SMIL, you can easily add transparency to clips, and stack them on top of each other. You can turn an opaque graphic into a semi-transparent logo that hovers over a video, for example.
SMIL's extensive hyperlinking capabilities allow you to link a streaming presentation to other streaming clips, or to Web pages. Web pages can display automatically at any time during the presentation, or may load only when the viewer clicks a link.
SMIL lets you stream different clips to different audiences based on criteria such as language preference or available bandwidth. This lets you create multiple presentations, but still have just one link on your Web page. When a viewer clicks that link, the viewer's RealPlayer reads the options in the SMIL file and chooses the appropriate presentation.
|Note: SureStream also lets you support multiple bandwidth connections within a single clip. For more information, see "SureStream RealAudio and RealVideo".|
Using SMIL's transition effects and animations, you can create special effects, such as fading one clip into another, or moving a clip around the screen. This lets you duplicate special effects found in advanced video editing programs without making any changes to your streaming clips.
Because a SMIL file is a simple text file, you can generate it automatically for each visitor. You can therefore create different presentation parts, assembling a customized SMIL file for each visitor.
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 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.
|Time Manipulations||TimeManipulations||yes (animations only)||click here|
|Content Control||BasicContentControl||yes||click here|
|Media Objects||BasicMedia||yes||click here|
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:
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 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.
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.
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.|
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".|
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.
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 |
|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.
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:
To create a SMIL 2.0 file and use all the SMIL features described in this guide,
<smil> tag must look like the following:
SMIL is based on Extensible Markup Language (XML), which provides the
means for defining any number of standard or customized markup languages.
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.
</smil> tags, a SMIL file breaks down into two basic
subsections: the header and the body. The header is defined between
</head> tags, while the body section falls within
as shown here:
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:
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> tags, for example,
while the body section uses
</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.
Both the header and body of a SMIL file contain tags that have the following form:
Aside from the angle brackets and a possible closing slash, there are three basic parts to a SMIL tag:
||The tag name comes just after a left angle bracket. Some tags may consist of just the name, as in the |
||Each attribute defines one aspect of the tag. If a tag has several attributes, the order of attributes doesn't matter.|
||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.|
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
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.
Attribute values, such as
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.
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:
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
Some SMIL tags, called binary tags, have a corresponding end tag. For
<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:
|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.|
Several SMIL tags can be either binary or unary, depending on how they
operate. For example, a unary
<video/> tag plays a video clip:
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:
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.
Although not strict rules, the following recommendations will help you keep your SMIL markup organized and understandable.
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.
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:
Any SMIL tag can have an ID in the form
". 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:
<region/>tags, for example, each tag must have a unique ID. No
<region/>tag can have the same ID as a
<transition/>tag or a
<video/>tag, for instance.
id="videoRegion"are different, for example. It is a good idea to follow a consistent practice, such as always making IDs lowercase.
id="video3"as an ID, but not
regionfor all region IDs, for example, or a
transition_prefix for all transition effect IDs.
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
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:
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 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
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.
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
|For More Information: See "Combining SMIL 2.0 with SMIL 1.0" for an explanation of how to use this namespace.|
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.
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.
A prefix ties an attribute to a namespace. Consider the example of two
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.
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,
fd:find, but each defined against a different namespace. If you used
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
xy prefix in the associated namespace so that RealPlayer could match
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.
<smil>tag, you can declare each namespace on a separate line for easier reading. SMIL ignores extra spaces, carriage returns, line breaks, and tabs used simply to align text in a file. Just make sure that the closing angle bracket of the
<smil>tag appears after the last namespace.
<smil>tag even if you don't use any customized attributes associated with that namespace.
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.
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.
The SMIL 2.0 specification requires changes to RealPlayer's handling of some basic features that carry over from SMIL 1.0:
endattribute to make these clips display at all. For information on durations, see "Setting Durations".
fillattribute defaults to
fill="auto", which can be equivalent to
fill="freeze"depending on the circumstance. See "Setting a Fill".
fill="freeze"attribute displays a clip only until the group ends. If the presentation ends when the group ends, the clip does not stay frozen on the screen as it did in SMIL 1.0. Instead, it is removed once the group is no longer active. To display a clip after its group ends, use
erase="never"in the clip tag. For more information on these new attributes and values, see "Displaying a Clip Throughout a Presentation".
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:
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.
|SMIL 1.0 Element||SMIL 2.0 Tag or Attribute||Reference|
|Layout Tags and Attributes|
|Clip Source Tags and Attributes|
|Timing Tags and Attributes|
|Hyperlinking Tags and Attributes|
|Switch Tag Attributes|
©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.