Grouping clips is the fundamental way to organize a presentation timeline. For example, you can play clips one after another, or display several clips at the same time. This chapter describes how to use the basic group tags to organize a presentation. Once you understand how groups work, you can use the timing commands described in later chapters to modify group behavior.
Within a SMIL presentation, you can organize clips into three types of groups. The presentation can have any number of these groups:
In a sequence, clips play one at a time, one after the other. When one clip stops, the next clip begins, and so on until the sequence finishes. In SMIL, a <seq>
tag indicates the start of a sequence. A corresponding </seq>
tag denotes the end of the sequence. The section "Playing Clips in Sequence" explains sequences.
![]() |
View it now!
(requirements for viewing this sample)
Watch this sample to see a simple sequence of videos. |
In a parallel group, all clips play together. For example, a parallel group could include a video and a RealText clip that provides subtitles. When you create a parallel group, you need to define a layout that specifies where each clip appears onscreen. A <par>
tag starts a parallel group, and a </par>
tag ends the group. See the section "Playing Clips in Parallel" for more information.
![]() |
View it now!
(requirements for viewing this sample)
Watch this sample to see a parallel group consisting of a video with RealText subtitles. |
In an exclusive group, only one clip plays at a time. This type of group is typically created for interactive presentations. For example, a presentation may include several buttons, each of which selects a different video. Depending on which button the viewer clicks, a different clip from the group is selected. An exclusive group is created between <excl>
and </excl>
tags. The section "Creating an Exclusive Group" explains exclusive groups.
One of the powerful features of SMIL is the ability to nest groups within
groups. For example, you can combine <seq>
and <par>
tags in various ways to
create many types of presentations. The organization of these tags greatly
affects playback, though, and you need to be careful when creating deeply
nested groups. In the following example, clip 1 plays first. When it finishes,
clip 2 and clip 3 play together. When both clip 2 and clip 3 have finished
playing, clip 4 plays:
<seq> |
You get very different results, though, if you switch the <seq>
and <par>
groupings. In the next example, clips 1, 2, and 4 all begin at the same time.
When clip 2 finishes, clip 3 starts:
<par> |
The following illustration shows the difference between these groupings.
A sequence is the simplest type of group to create. Just list the clips within
<seq>
and </seq>
tags in the order that you want them to play. The following
example shows the entire SMIL markup required to play three audio clips in
sequence:
<smil xmlns="http://www.w3.org/2001/SMIL20/Language"> |
In the preceding example, the second clip begins when the first clip finishes, and the third clip begins when the second clip finishes. A sequence can include any number of clips, and the clips can be of any type. You could add a RealVideo or Flash clip to the sequence shown above, for example. When using visual clips, however, you should also define a layout as described in Chapter 12.
When you enclose clips in <seq>
and </seq>
tags, RealOne Player treats the
sequence as a single presentation. If each clip in the preceding example is two
minutes in length, for example, the RealOne Player status bar indicates that
the presentation is six minutes long. Because RealOne Player treats the
sequence as a single presentation, viewers can use the timeline slider to seek
through all the clips, but cannot choose individual clips through the RealOne
Player Play>Next Clip command.
![]() |
View it now!
(requirements for viewing this sample)
Play this sample to hear a sequence of three audio clips that uses a <seq> group. Each clip
lasts 15 seconds. Note that RealOne Player indicates that the
presentation lasts 45 seconds, and that you cannot use the
Play>Next Clip command.
|
It is not always necessary to group clips within <seq>
and </seq>
tags.
Whenever clips are not listed in a group, RealOne Player automatically plays
them in sequence. For instance, the following markup, which has no <seq>
and
</seq>
tags, plays three audio clips in sequence just like the preceding example:
<smil xmlns="http://www.w3.org/2001/SMIL20/Language"> |
When you do not use a <seq>
group, however, RealOne Player treats each clip
as a separate presentation. Suppose that each clip in the preceding example
lasts two minutes. When the sequence starts, the RealOne Player status bar
indicates that the presentation lasts two minutes. When the first clip ends,
RealOne Player's timeline slider resets, the second clip starts, and the status
bar indicates another two-minute presentation. This action repeats when the
third clip plays. At any point, the viewer can select a different clip with the
RealOne Player Play>Next Clip command.
![]() |
View it now!
(requirements for viewing this sample)
Play this sample to hear a sequence of three audio clips that does not use a <seq> group.
Each clip lasts 15 seconds, and the timeline slider resets after
each clip plays. You can also use the Play>Next Clip command.
|
<seq>
tag can include a title
, author
, copyright
, or abstract
attribute just like a clip source tag. For more information, see "Adding Clip and Group Information".begin
attribute to delay playback. For more information, see "Setting Begin and End Times".dur
attribute to control the total playing time. For more information, see "Setting Durations".repeatDur
and repeatCount
attributes to repeat a sequence or a clip within a sequence. See "Repeating an Element" for more information.<seq>
tag can have timing attributes, it is easier to set all necessary timing attributes in the clip source tags first, so that they operate as you want them to within the sequence. Then, after determining how long the sequence will last, use timing attributes within the <seq>
tag to modify the group behavior if necessary.You can play two or more clips at the same time by grouping the clip source
tags between <par>
and </par>
tags. The following example creates a parallel
group that combines a RealVideo clip with a RealText clip:
<smil xmlns="http://www.w3.org/2001/SMIL20/Language"> |
In the preceding example, the RealVideo and the RealText clips play at the
same time. A parallel group can include any number of clips, but you need to
define a playback region for each visual clip as described in Chapter 12. (Audio
clips do not need to play in regions.) Each region defined in the layout must
have a unique id="
ID
"
attribute. You then assign each clip to a region with a
region="
ID
"
attribute in the clip source tag.
<par>
tag can include a title
, author
, copyright
, or abstract
attribute just like a clip source tag. For more information, see "Adding Clip and Group Information".endsync
attribute, as described in "Ending a Group on a Specific Clip".begin
attribute to delay playback. For more information, see "Setting Begin and End Times".dur
attribute to control the total playing time. For more information, see "Setting Durations".repeatDur
and repeatCount
attributes to repeat a parallel group. See "Repeating an Element" for more information.readindex
attributes, you can change the order that assistive reading devices read attributes of clips in parallel groups. See "Setting the Clip Read Order" for more information.Under normal circumstances, Helix Universal Server keeps clips within a parallel group synchronized, as long as you have authored your presentation so that its timeline runs smoothly, and it doesn't consume more bandwidth than its target audience has available. The following table summarizes the optional attributes you can add to elements within parallel groups to modify playback behavior, especially under adverse conditions.
Attribute | Value | Function | Reference |
---|---|---|---|
syncBehavior |
canSlip|default| |
Determines if clips can fall out of synchronization. | click here |
syncBehaviorDefault |
canSlip|independent| |
Sets default synchronization for a group. | click here |
syncTolerance |
default| time_value |
Loosens synchronization for locked elements. | click here |
syncToleranceDefault |
default| time_value |
Sets a default synchronization tolerance for a group. | click here |
Adding syncBehavior="independent"
to a clip in a parallel group keeps the clip
completely unsynchronized from other clips in the group. In fact, the clip acts
like a live broadcast. Moving the RealOne Player timeline slider does not fast-
forward or rewind the clip. In the following parallel group, the RealText clip
has an independent synchronization behavior. It begins to play along with the
RealAudio and Flash clips, but if the viewer fast-forwards or rewinds the
presentation, only the RealAudio and Flash clips are affected:
<par> |
![]() |
View it now!
(requirements for viewing this sample)
This sample plays two RealText clips, one of which uses syncBehavior="independent" to keep it unsynchronized
from the group.
|
Note that a parallel group's overall timing still applies to a clip that uses
syncBehavior="independent"
. In the following example, the parallel group plays
first, lasting for five minutes because of the dur
attribute in the <par>
tag. A
video then follows the group in sequence. If the viewer moves the timeline
slider to the five-minute mark, for instance, all clips in the parallel group end,
and the video plays. So even if it lasts 10 minutes, the RealText clip ends when
the group ends, regardless of its syncBehavior="independent
value:
<body> |
The independent
value is the only syncBehavior
value that has a visible effect on
how a parallel group plays under normal circumstances. As described in the
following sections, the other syncBehavior
values affect clips in a parallel group
only under difficult streaming conditions.
RealOne Player generally compensates well for changing network conditions
to keep a presentation streaming smoothly. Under highly adverse conditions,
though, it may have to suspend playback of a group until more data arrives.
With the syncBehavior
attribute, you can influence how RealOne Player
handles these situations. Think of these attributes as defensive measures: they
don't affect how your presentation plays under normal circumstances, just
how it handles adverse situations. The following table describes the attribute
values.
Value | Function |
---|---|
canSlip |
RealOne Player can suspend playing this clip as long as necessary until more clip data arrives. It then fast-forwards the clip so that it catches up with the group timeline. Other clips continue playing without regard to the state of this clip. |
locked |
The clip must stay synchronized with the group. If the clip's data stream stops, RealOne Player halts the group playback until new clip data arrives. You can also add a tolerance value, as described in "Loosening the Synchronization for Locked Elements". |
independent |
Clip playback is entirely independent of group playback. See "Creating an Independent Timeline". |
default |
The clip behavior is controlled by the group tag's syncBehaviorDefault attribute, as described in "Specifying Synchronization Behavior Default Values". You do not need to set this value explicitly if you also set a syncBehaviorDefault value because clips will inherit the default value automatically. |
![]() |
Note:
If you do not set any syncBehavior values, elements behave
as if they are set to the canSlip value.
|
In most cases, you'll want to use a combination of canSlip
and locked
as the
syncBehavior
value for clips within parallel groups. Consider the following
example, in which a Flash clip, a RealAudio clip, and a RealText clip play in
parallel. This example could be a training movie in which the Flash animation
displays visual information, the RealAudio clip provides an audio narration,
and the RealText clip supplies translated audio subtitles:
<par> |
The Flash clip in the preceding example can slip, meaning that RealOne Player will suspend playback for this clip first if bandwidth drops too low. RealOne Player will resume playing the clip when more bandwidth is available. At that point, it will fast-forward the Flash clip to bring it into synchronization with the RealAudio and RealText clips. The viewer will notice that the Flash clip has paused, but the audio and the subtitles will continue to play as long as conditions do not get too bad.
The RealAudio soundtrack and the RealText subtitles in the preceding example are locked with the group. This means that RealOne Player does everything it can to keep these clips synchronized and flowing smoothly. As described above, RealOne Player's first suspends the Flash clip if necessary. If that action does not provide enough bandwidth, and the RealAudio stream also runs dry, RealOne Player halts the entire group until it has received enough data to continue playing the RealAudio and the RealText clips. It brings the Flash clip up to the group's current position whenever conditions allow.
Just as you can synchronize clips within groups, you can also synchronize groups within groups. Suppose that the preceding example is modified so that it plays a sequence of RealAudio clips, rather than just one clip, in parallel with the Flash and RealText clips:
<par> |
In the preceding example, the syncBehavior
attribute is used in the <seq>
tag to
lock the entire sequence of RealAudio clips with the parallel group. Because of
group nesting, synchronization can become complex, as shown in the
following abstract example:
<par id="master_group"> |
To understand how this hypothetical grouping works, look at the outer <par>
group first. You can see that this group contains three elements: clip_A
,
group_X
, and group_Y
. The syncBehavior
attributes on these elements determine
the presentation's overall synchronization. Because clip_A
and group_X
are
locked, RealOne Player ensures that these elements stay synchronized. Under
adverse conditions, it first halts playback of group_Y
if necessary.
Within group_X
, clip_B
is locked. Hence, clip_B
will continue to play in step
with clip_A
unless network conditions greatly deteriorate. Because clip_C
can
slip, RealOne Player's second line of defense is to halt playback for clip_C
while
keeping clip_A
and clip_B
playing. When network conditions improve, RealOne
Player first restores clip_C
, then group_Y
to the presentation. Note, however
that both clip_D
and clip_E
are locked in group_Y
. This means that RealOne
Player won't restore group_Y
until it can play both clips.
The group attribute syncBehaviorDefault
is useful for setting synchronization
behaviors with groups that contain many clips, or with nested groups. In a
group tag, the syncBehaviorDefault
attribute determines which synchronization
behavior is used if a group element does not specify a syncBehavior
value, or
uses syncBehavior="default"
. In the following example, the group tag has a
locked
synchronization behavior set by default:
<par |
In the preceding example, the RealAudio clip does not specify a syncBehavior
attribute, and the RealText clip uses syncBehavior="default"
. Both clips
therefore use the default value (locked
) set in the group tag. The Flash clip
specifies a different synchronization behavior, though, which overrides the
default setting.
A group tag's syncBehaviorDefault
attribute can have the values locked
, canSlip
,
or independent
, which are described in the table "syncBehavior Attribute
Values". The attribute's default value is inherit
, which you can also set
explicitly in a group tag. This inherit value is useful with nested groups, as
shown in the following abstract example:
<par id="master_group" syncBehaviorDefault="canSlip"> |
In this example, group_X
and group_Y
both inherit the master group's
syncBehaviorDefault
value of canSlip
. Elements within these two groups will use
the canSlip
behavior unless another value is specified in their tags. On the
other hand, group_Z
overrides the master group's behavior and sets a default of
locked
. Elements within group_Z
will use the locked behavior unless they
explicitly specify a different value.
When you have several levels of nested groups that use syncBehavior
and
syncBehaviorDefault
, it's important to understand how the groups and their
elements interact. Because elements inherit a syncBehaviorDefault
value by
default, the interactions can be difficult to grasp unless you look at all levels
of the nested groups. Consider the following abstract example:
<par id="master_group" syncBehaviorDefault="canSlip"> |
The master group sets a syncBehaviorDefault
value of canSlip
. The elements
within this master group have the following syncBehavior
values:
group_X
set to canSlip
group_X
inherits the default value of canSlip
from master_group
, and passes that value to the clips it contains, one of which overrides the value:
group_Y
set to locked
group_Y
sets its own behavior to locked
. However, it inherits the default value of canSlip
from master_group
, and passes that value to both clips it contains:
group_Z
set to canSlip
group_Z
inherits the default value of canSlip
from master_group
. However, it changes the default value for the elements it contains to locked
. One of the clips overrides that value:
When you add syncBehavior="locked"
to elements within a group, RealOne
Player keeps those elements, whether clips or groups, tightly synchronized.
You can loosen the synchronization by adding syncTolerance="
time_value
"
to
the containing group. A tolerance value is useful if the elements do not need
to be highly synchronized: the higher the tolerance, the less likely that
RealOne Player will have to halt the entire group to rebuffer data. The
following example adds a three-second tolerance to the locked elements:
<par |
In the preceding example, the locked RealAudio and RealText clips can fall at least three seconds out of synchronization before RealOne Player stops the group to rebuffer the data streams. Base the amount of time to set for a tolerance on your judgment of how far the clips can fall out of synchronization without the group playback becoming too confusing for the viewer.
![]() |
For More Information: SMIL timing values are described in "Specifying Time Values". |
Similar to syncBehaviorDefault
, the group attribute syncToleranceDefault
can set
synchronization tolerances for nested groups. In the following example, the
master containing group sets a syncToleranceDefault
value of three seconds:
<par id="master_group" |
In the preceding example, group_X
includes syncTolerance="inherit"
and group_Y
does not have a syncTolerance
value. Both groups therefore inherit the master
group's tolerance value of three seconds. However, group_Z
sets its own
tolerance value of five seconds, which overrides the master group's default.
Note that the master group has both a syncTolerance
and a syncToleranceDefault
value. When you use synchronization tolerance values, it's important to keep
in mind what these values do:
syncTolerance
value determines the tolerance value used for elements within the group. In the preceding example, the syncTolerance
value for the master group affects the tolerance applied to group_X
, group_Y
, and group_Z
, but not to the elements within those groups.syncToleranceDefault
value sets the tolerance on each subgroup's elements, as long as group_X
, group_Y
, or group_Z
inherits the value and does not override it with its own tolerance value.locked
synchronization on the clip that provides the audio. Viewers are more likely to stay tuned to a presentation in which visuals stop and start if the audio continues to flow smoothly.The <excl>
and </excl>
tags create an exclusive group in which only one
element plays at a time. In a <seq>
group, only one element plays at a time, too,
but the playback order always proceeds from the first to the last element. In
contrast, an <excl>
group has no predefined playback order. The playback
order depends wholly on the SMIL timing commands defined for each
element in the group.
You use an exclusive group for different purposes than you use a parallel
group or a sequence. With <par>
and <seq>
tags, you can construct a single
timeline that flows continuously throughout the entire presentation. Using
an exclusive group, though, you can break up a timeline through two features:
interruption and interactivity.
As an example of both interruption and interactivity, imagine a group of videos in which each video plays only when the viewer clicks an icon for the video. This is interactivity. Then, as it plays, a selected video pauses intermittently as advertising clips play, automatically resuming when each ad clip finishes. This is interruption. An exclusive group may define just one of these features, or both.
![]() |
Tip: To understand how exclusive groups work, you'll need to know about timing attributes. You may therefore want to read Chapter 13 and Chapter 14 first. |
Adding interactivity to a presentation is a main function of an exclusive
group. In the following example, an exclusive group of videos plays in parallel
with three images. All the video clips in the exclusive group use interactive
begin
values to start playback only when the viewer clicks an image. Hence all
three images appear as soon as the parallel group becomes active, but each
video does not become visible until an image is clicked:
<par> |
Note that the exclusive group in the preceding example uses dur="indefinite"
,
which keeps the group active indefinitely. A timing command such as this is
required because an <excl>
has an intrinsic duration of 0 seconds when its
elements use interactive timing. You therefore need to use timing commands
in the <excl>
tag to control the group's overall duration. Another option is to
use endsync="all"
to keep the group active only until all of its elements have
played.
![]() |
View it now!
(requirements for viewing this sample)
To illustrate the preceding example, this sample lets you click a numbered image to select a video. The next sample uses an exclusive group and interactive timing to create a simple slideshow in which the next image displays when the current image is clicked. |
![]() |
For More Information:
The begin value used to start a clip with a
mouse click is described in "Defining a Mouse Event". For
more on endsync="all" , see "Stopping a Group After the Last
Clip Plays".
|
The following example demonstrates a simple exclusive group with basic clip
interruption. As with a <seq>
group, only one clip from this <excl>
group will
play at a time. Unlike a <seq>
group, though, the order in which you list the
clips does not matter because the timing attributes completely control
playback. In the following example, clips play in the reverse order from which
they are listed:
<excl> |
In the preceding example, number3.png
plays first. Its begin="0s"
value means
that it plays as soon as the <excl>
group becomes active. Its dur="5s"
value
makes it play for five seconds. The number2.png
clip starts playing three
seconds after the group becomes active, however. Because only one group
element can play at a time, the begin="3s"
value for number2.png
overrides the
dur="5s"
value for number3.png
. When number2.png
starts to play, it stops
number3.png
. Likewise, when number1.png
starts, it stops number2.png
.
![]() |
View it now!
(requirements for viewing this sample)
To illustrate the preceding example, this sample shows clip interruption in an exclusive group. |
![]() |
For More Information:
For more on the begin attribute, see
"Setting Begin and End Times". Durations are explained in
"Setting Durations".
|
By defining priority classes, you can control how clips in an exclusive group
interrupt each other. In an exclusive group that does not use priority classes,
an interrupting clip stops the interrupted clip. By defining priority classes,
though, you can pause the interrupted clip instead, so that its playback
resumes once the interrupting clip finishes. You define a priority class with
<priorityClass>
and </priorityClass>
tags. Between these tags, you list the media
clips within that priority class, as shown here:
<excl> |
When you create priority classes, the order of clips within the <excl>
group
becomes important. The first priority class has the highest priority, the last
class has the lowest priority. All clips within a priority class have the same
priority, and are called peers.
Once you define priority classes, you can use the attributes summarized in the
following table to set the interruption behavior for clips in each class. A
<priorityClass>
tag can have an id
attribute and any of the following attributes,
but no others. You cannot include timing attributes in a <priorityClass>
tag, for
example.
Attribute | Value | Default | Function | Reference |
---|---|---|---|---|
peers |
defer|never| |
stop |
Controls how clips within the same class interrupt each other. | click here |
higher |
pause|stop |
pause |
Determines how clips with higher priority interrupt clips in the class. | click here |
lower |
defer|never |
defer |
Specifies how interrupting clips with lower priority affect playback. | click here |
pauseDisplay |
disable|hide| |
show |
Sets a clip's appearance if the clip is paused. | click here |
The peers
attribute for a priority class determines how clips within that
priority class interrupt each other. The peers
attribute can have one of the
values given in the following table.
For example, to have clips within an exclusive group pause each other instead
of stop each other during interruptions, you can define a single priority class
and use peers="pause"
as shown here:
<excl> |
![]() |
For More Information:
For more on pauseDisplay , see "Specifying
How Paused Clips Display".
|
For priority classes other than the highest priority class, you can use the higher
attribute in the <priorityClass>
tag to determine how any clip in a higher
priority class interrupts a clip in the current priority class. The higher
attribute
can take one of the values listed in the following table.
In the following example, the first priority class (class1
) has higher priority.
The second priority class (class2
) uses higher="stop"
to specify that if a clip
from class1
interrupts a clip from class2
, the class2
clip will stop. Note, though,
that class2
also uses peers="pause"
. This means that if a clip from class2
interrupts another clip from that class, the interrupted clip will pause, not
stop:
<excl> |
![]() |
For More Information:
For more on pauseDisplay , see "Specifying
How Paused Clips Display".
|
For priority classes other than the lowest priority class, you can use the lower
attribute in the <priorityClass>
tag to determine how a clip from a lower
priority class acts if it attempts to interrupt a clip in the current priority class.
The lower
attribute can take one of the values listed in the following table.
In the following example, the first priority class (class1
) has higher priority
and uses lower="never"
to specify that if a clip from class2
attempts to interrupt
a clip from class
1, the class2
clip will not play at all. Note, though, that class2
also uses peers="defer"
. This means that if a clip from class2
interrupts another
clip from that class, the interrupting clip will play after the interrupted clip
finishes:
<excl> |
When you set peers="pause"
or higher="pause"
in a <priorityClass>
tag, you can
also set the pauseDisplay
attribute, which determines how a clip appears when
it pauses. This attribute, which has no effect on audio-only clips, can take one
of the values listed in the following table.
In the following example, each clip that interrupts another clip causes that clip to pause and disappear. After the interrupting clip finishes playing, the interrupted clip reappears and resumes playback:
<excl> |
<excl>
group can have one or several priority classes.<excl>
group must belong to a priority class. You cannot mix clips that are within priority classes and clips that are outside of priority classes.
![]() |
©2002 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. |