previous next

Chapter 11: Groups

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.

Understanding Groups

Within a SMIL presentation, you can organize clips into three types of groups. The presentation can have any number of these groups:

Groups Within 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>
clip 1
<par>
clip 2
clip 3
</par>
clip 4
</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>
clip 1
<seq>
clip 2
clip 3
</seq>
clip 4
</par>

The following illustration shows the difference between these groupings.

Different Playback Results with Nested Groups

Different Playback Results with Nested Groups

Playing Clips in Sequence

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">
<body>
<seq>
<audio src="song1.rm"/>
<audio src="song2.rm"/>
<audio src="song3.rm"/>
</seq>
</body>
</smil>

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.

Creating Sequences Without Sequence Tags

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">
<body>
<audio src="song1.rm"/>
<audio src="song2.rm"/>
<audio src="song3.rm"/>
</body>
</smil>

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.

Tips for Creating Sequences

Playing Clips in Parallel

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">
<head>
<layout>
...region layout defined as described in Chapter 12...
</layout>
<body>
<par>
<video src="song.rm" region="region1_ID"/>
<textstream src="lyrics.rt" region="region2_ID"/>
</par>
</body>
</smil>

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.

Tips for Creating Parallel Groups

Synchronizing Playback in Parallel Groups

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.

Parallel Group Synchronization Attributes
Attribute Value Function Reference
syncBehavior canSlip|default|
independent|locked
Determines if clips can fall out of synchronization. click here
syncBehaviorDefault canSlip|independent|
inherit|locked
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

Creating an Independent Timeline

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>
<audio src="soundtrack.rm" .../>
<ref src="training.swf" .../>
<textstream src="translation.rt" syncBehavior="independent" .../>
</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>
<seq>
<par dur="5min">
<audio src="soundtrack.rm" .../>
<ref src="training.swf" .../>
<textstream src="translation.rt" syncBehavior="independent" .../>
</par>
<video src="conclusion.rm" .../>
</seq>
</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.

Setting the Synchronization Behavior

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.

syncBehavior 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.

Synchronizing Clips

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>
<audio src="soundtrack.rm" syncBehavior="locked" .../>
<ref src="training.swf" syncBehavior="canSlip" .../>
<textstream src="translation.rt" syncBehavior="locked" .../>
</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.

Synchronizing Groups

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>
<seq syncBehavior="locked">
<audio src="soundtrack1.rm" .../>
<audio src="soundtrack2.rm" .../>
<audio src="soundtrack3.rm" .../>
</seq>
<ref src="training.swf" syncBehavior="canSlip" .../>
<textstream src="translation.rt" syncBehavior="locked" .../>
</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">
<ref id="clip_A" syncBehavior="locked" .../>
<par id="group_X" synchBehavior="locked" .../>
<ref id="clip_B" synchBehavior="locked" .../>
<ref id="clip_C" synchBehavior="canSlip" .../>
</par>
<par id="group_Y" syncBehavior="canSlip">
<ref id="clip_D" synchBehavior="locked" .../>
<ref id="clip_E" synchBehavior="locked" .../>
</par>
</par>

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.

Specifying Synchronization Behavior Default Values

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 syncBehaviorDefault="locked">
<audio src="soundtrack.rm" .../>
<ref src="training.swf" syncBehavior="canSlip" .../>
<textstream src="translation.rt" syncBehavior="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.

Setting Groups to Inherit Synchronization Defaults

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">
<par id="group_X" syncBehaviorDefault="inherit">
...group_X clips played in parallel...
</par>
<par id="group_Y">
...group_Y clips played in parallel...
</par>
<par id="group_Z" syncBehaviorDefault="locked">
...group_Z clips played in parallel...
</par>
</par>

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.

Nested Group Interactions with Synchronization Behaviors

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">
<par id="group_X" syncBehaviorDefault="inherit">
<ref id="clip_A" .../>
<ref id="clip_B" syncBehavior="locked" .../>
</par>
<par id="group_Y" syncBehavior="locked">
<ref id="clip_C" .../>
<ref id="clip_D" .../>
</par>
<par id="group_Z" syncBehaviorDefault="locked">
<ref id="clip_E" .../>
<ref id="clip_F" syncBehavior="canSlip" .../>
</par>
</par>

The master group sets a syncBehaviorDefault value of canSlip. The elements within this master group have the following syncBehavior values:

Loosening the Synchronization for Locked Elements

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 syncTolerance="3s">
<audio src="soundtrack.rm" syncBehavior="locked" .../>
<ref src="training.swf" syncBehavior="canSlip" .../>
<textstream src="translation.rt" syncBehavior="locked" .../>
</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".

Specifying Synchronization Tolerance Default 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" syncTolerance="4s" syncToleranceDefault="3s">
<par id="group_X" syncBehavior="locked" syncTolerance="inherit">
...group_X clips played in parallel...
</par>
<par id="group_Y" syncBehavior="canSlip">
...group_Y clips played in parallel...
</par>
<par id="group_Z" syncBehavior="canSlip" syncTolerance="5s">
...group_Y clips played in parallel...
</par>
</par>

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:

Tips for Synchronizing Clips

Creating an Exclusive Group

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.

Defining Interactive Begin Times

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>
<img src="number1.gif" id="button1" .../>
<img src="number2.gif" id="button2" .../>
<img src="number3.gif" id="button3" .../>
<excl dur="indefinite">
<video src="video1.rm" begin="button1.activateEvent" .../>
<video src="video2.rm" begin="button2.activateEvent" .../>
<video src="video3.rm" begin="button3.activateEvent" .../>
</excl>
</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".

Using Clip Interruption

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>
<img src="number1.png" region="images" begin="6s" dur="5s"/>
<img src="number2.png" region="images" begin="3s" dur="5s"/>
<img src="number3.png" region="images" begin="0s" dur="5s"/>
</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".

Modifying Clip Interruption Behavior

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>
<priorityClass...>
...clips in the higher priority class...
</priorityClass>
<priorityClass...>
...clips in the lower priority class...
</priorityClass>
</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.

<priorityClass> Attributes
Attribute Value Default Function Reference
peers defer|never|
pause|stop
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
show Sets a clip's appearance if the clip is paused. click here

Controlling How Peers Interact

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.

peers Attribute Values
Value Function
defer An interrupting clip does not start until the currently playing clip stops.
never An interrupting clip does not start at all.
pause The interrupting clip pauses the playing clip. After the interrupting clip finishes, the paused clip resumes playback. The pauseDisplay attribute sets the appearance of the paused clip.
stop The interrupting clip stops the playing clip. This is the default if you leave the peers attribute out of the <priorityClass> tag, or you do not define any priority classes within an <excl> group.

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>
<priorityClass peers="pause">
<video src="video1.rm" .../>
<video src="video2.rm" .../>
<video src="video3.rm" .../>
</priorityClass>
</excl>

For More Information: For more on pauseDisplay, see "Specifying How Paused Clips Display".

Setting Interactions with Higher Priority Classes

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.

higher Attribute Values
Value Function
pause An interrupting clip from a higher priority class pauses the playing clip. After the interrupting clip finishes, the paused clip resumes playback. This is the default if you do not use the higher attribute. The pauseDisplay attribute sets the appearance of the paused clip.
stop An interrupting clip from a higher priority class stops the playing clip.

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>
<priorityClass id="class1">
...clips in the higher priority class...
</priorityClass>
<priorityClass id="class2" higher="stop" peers="pause">
...clips in the lower priority class...
</priorityClass>
</excl>

For More Information: For more on pauseDisplay, see "Specifying How Paused Clips Display".

Setting Interactions with Lower Priority Classes

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.

lower Attribute Values
Value Function
defer An interrupting clip from a lower priority class does not start until the end of the current clip, as well as any higher-priority clips that play after the current clip. This is the default if you do not use the lower attribute.
never An interrupting clip from a lower priority class does not play at all.

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 class1, 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>
<priorityClass id="class1" lower="never">
...clips in the higher priority class...
</priorityClass>
<priorityClass id="class2" peers="defer">
...clips in the lower priority class...
</priorityClass>
</excl>

Specifying How Paused Clips Display

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.

pauseDisplay Attribute Values
Value Function
disable The paused clip appears visible but disabled in RealOne Player. It does not respond to mouse clicks until it resumes playback.
hide The paused clip disappears until it resumes playback.
show The paused clip remains visible in RealOne Player, and it continues to respond to mouse clicks. This is the default if you do not use the pauseDisplay attribute.

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>
<priorityClass peers="pause" pauseDisplay="hide">
<video src="video1.rm" .../>
<video src="video2.rm" .../>
<video src="video3.rm" .../>
</priorityClass>
</excl>

Tips for Defining Exclusive Groups and Priority Classes


RealNetworks, Inc. ©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.
previous next