Chapter 6 covers the basics of SMIL, the industry-standard language for streaming multimedia. This chapter describes RealNetworks' SMIL extensions, which enhance SMIL's playback ability. These extensions work only with RealSystem, not with any other SMIL-based media player. Use them only when streaming clips from RealServer to audiences using RealPlayer.
For a still image, you can use the options listed in the following table to modify the image's streaming characteristics, or to link it to RealPlayer commands. These options are not SMIL parameters. They are extensions to the image's SMIL source tag, which is described in "Specifying Clip Locations". The table summarizes the image options, which are described in detail in the sections that follow.
A question mark operator (?) separates image options from the image URL in the SMIL source tag. To use multiple image options, insert a question mark before the first option, and separate the remaining options with ampersands (&). The order of options does not matter. The following example shows the basic syntax for adding two image options to the image source tag:
<img src="URL
?option=value&option=value
"/>
Note that image options and values are not in quotation marks because they are part of the quoted src
value. The following example combines bit rate and background color options:
<img src="button.gif?bitrate=1000&bgcolor=blue"/>
By default, an image streams at 12 Kbps until RealPlayer receives it. You can set a higher bit rate to take advantage of bandwidth availability and stream an image quickly. Or you can set a lower bit rate when streaming images in parallel with another clip so that the other clip has enough bandwidth for uninterrupted playback. The following example shows three sequential image files set to stream at a low bit rate to ensure that a video playing in parallel does not stall:
<par>
<video src="video.rm" region ="videoregion"/>
<par>
<seq>
<img src="ad1.gif?bitrate=1000
" begin="30s" dur="60s" region="adregion"/>
<img src="ad2.gif?bitrate=1000
" dur="120s" region="adregion"/>
<img src="ad3.gif?bitrate=1000
" dur="60s" region="adregion"/>
</seq>
</par>
</par>
In this example, each GIF image is set to stream at 1 Kbps. This ensures that each image consumes a small amount of bandwidth and does not interfere with video playback.
![]() |
Note |
---|
In the preceding example, the <par> tag just outside the
<seq> tag makes RealServer balance the bit rates of the
images as a combined group. For more on using <par> to
balance bandwidth, see "Smoothing Transitions
Between Clips".
|
Keep in mind that the image size divided by the maximum bit rate equals the minimum amount of time needed to stream the image. Assuming that images in the preceding example are 30 kilobits apiece, each image takes about 30 seconds to stream. For this reason, the first image is set to display 30 seconds after the video begins to play. If no begin time were defined, the video would be delayed up to 30 seconds while the first image streams to RealPlayer. As well, each successive image must be able to stream while the preceding image displays.
For GIF or PNG images that include transparency, you can use bgcolor
to substitute a color for the transparency. Choose any hexadecimal color value without the leading pound sign ("#"), or any predefined color name as described in "Adding Background Colors". If you do not set the color, the region's defined background color shows through transparent spots in the image. Here is an example of an hexadecimal background color defined for an image:
<img src="button.gif?bgcolor=BB21AA
"/>
Using the image url
and target
options, you can link an image with a fully qualified URL. When the viewer clicks the image, the URL opens in the viewer's browser or RealPlayer. The following example shows an image linked with a URL that opens in the viewer's default browser:
<img src="home.gif?url=http://www.example.com&target=_browser" region="home"/>
This next example shows an image linked with a URL that opens in RealPlayer:
<img src="go.gif?url=rtsp://realserver.example.com/media.smil&target=_player"
region="next"/>
Keep in mind that opening a URL in RealPlayer replaces the current presentation with the new clip or SMIL file.
![]() |
Note |
---|
The image hyperlink options duplicate the SMIL hyperlink features described in "Linking to Other Media". You can use either method, depending on your preference. |
With url=command:
command
&target=_player
, you can turn an image into a link that causes RealPlayer to stop, pause, play, or seek to a specific point in the presentation timeline. The following example shows three images set to appear in three separate SMIL regions. Each image issues a different RealPlayer command when clicked:
<par>
<img src="play.gif?url=command:play()&target=_player
" region="play"/>
<img src="pause.gif?url=command:pause()&target=_player
" region="pause"/>
<img src="stop.gif?url=command:stop()&target=_player
" region="stop"/>
</par>
An image can also issue a seek command that specifies a certain point in the presentation timeline:
<img src="seek.gif?url=command:seek(1:35.4)&target=_player
"
region="seek"/>
In the preceding example, clicking the image instructs RealPlayer to seek to 1:35.4 in the presentation. This option does not use SMIL shorthand timing values such as s
for seconds or min
for minutes. Instead, the time format is like the "Normal Play Time Format", except that it also accepts milliseconds and days as values:
dd:hh:mm:ss.xyz
Here, dd
is days, hh
is hours, mm
is minutes, ss
is seconds, x
is tenths of seconds, y
is hundredths of seconds, and z
is milliseconds. Only the ss
field is required.
When the time value does not include a decimal point, the last field is read as the seconds. For example, 1:30
means 1 minute and 30 seconds, whereas 1:30:00
means 1 hour and 30 minutes. Thus, all of the following values seek 90 minutes into the presentation timeline:
url=command:seek(1:30:00.0)&target=_player
url=command:seek(90:00)&target=_player
url=command:seek(5400)&target=_player
Use the reliable=true
option to indicate that an image must be delivered to RealPlayer under any circumstances:
<img src="button.gif?reliable=true
"/>
During extremely adverse network conditions, RealSystem will halt the presentation if necessary rather than drop the image. Use reliable="true"
sparingly, though, because RealSystem generally ensures that very little data loss occurs in transmission.
Using RealPlayer 7 or later, you can open as many playback windows as the computer CPU and memory allow. This way, you can keep navigation information visible in one window, for example, while playing a clip in another window. Windows pop up when a viewer clicks a specially configured hyperlink. Instead of opening a Web page or another media clip, though, the hyperlink sends an "open window" command to RealPlayer.
![]() |
Additional Information |
---|
For information on supporting both multiple windows in newer versions of RealPlayer and a single window in RealPlayer G2, see "Switching Presentations for Different RealPlayer Versions". |
You open a new RealPlayer window by using a hypertext link in a RealText, SMIL, or Flash clip. RealText, SMIL, and the Get URL command in Flash all support HTML-style hypertext links. Unlike HTML, though, RealSystem markup tags are case-sensitive. A RealSystem hyperlink that opens a new RealPlayer window uses the following format:
<a href="command:openwindow(name
,URL, playmode=value,
...
)">...</a>
When a viewer clicks a link that uses this syntax, command:openwindow
tells RealPlayer to open a new window for the given URL and stop the presentation in the current window. This command requires two arguments, name
and URL
. The playmode
arguments are optional. You can separate arguments with a comma, but this is not required. A space may precede or follow a comma. If an argument contains characters such as commas or parentheses, enclose it in single quotation marks.
The mandatory name
argument comes first. It supplies a predefined or user-defined name for the new RealPlayer window. The following table lists and describes the values for the name
argument.
Following the name
argument, the required URL
argument gives the fully qualified URL to the clip or SMIL presentation to play in the new window. You must include the protocol (rtsp://
, http://
, chttp://
, or file://
) in the URL. Note that relative URLs do not work.
The optional playmode=value
argument defines the state of the new RealPlayer window that opens. A command to open a new window can have more than one playmode
argument. The following table lists and describes the possible playmode
values.
![]() |
Note |
---|
You can also open the initial presentation in double, full-screen, or compact mode by using a Ram file. For details on doing this, as well as guidelines for using double and full-screen modes, see "Setting a Presentation's Starting Mode". |
This section provides examples of hyperlinks that open new RealPlayer windows. The first three sections illustrate how to target various windows with the hyperlink syntax. They use RealText links and Flash Get URL commands as examples. The fourth example shows a hyperlinked image in SMIL. The last sample illustrates a SMIL hotspot link for a video clip.
The following RealText link opens a URL in a new RealPlayer window named feature
. The new window is set to autosize mode:
<a href="command:openwindow(feature, rtsp://realserver.example.com/comedy.rm, autosize=true)">Comedy Hour</a>
In Flash, the Get URL command looks like this:
command:openwindow(feature, rtsp://realserver.example.com/comedy.rm, autosize=true)
When first clicked, this link creates a RealPlayer window named feature
. If another link also targets the feature
window, clicking that link starts the new URL in the feature
window. Clicking the link in the following example starts an animal program in the window running the comedy program. Note, however, that this RealText link switches the window out of autosize mode:
<a href="command:openwindow(feature, rtsp://realserver.example.com/animals.rm, autosize=false)">Sharks!</a>
The Flash Get URL version looks like this:
command:openwindow(feature, rtsp://realserver.example.com/animals.rm, autosize=false)
Each link opens a separate window if the window names are different, or you use the predefined name _new
or _blank
. The following RealText links open separate autosizing windows that play on top of all other desktop windows:
<a href="command:openwindow(_new, rtsp://realserver.example.com/comedy.rm, autosize=true, ontopwhileplaying=true)">Comedy Hour</a>
<a href="command:openwindow(_blank, rtsp://realserver.example.com/animals.rm, autosize=true, ontopwhileplaying=true)">Sharks!</a>
In Flash, the Get URL commands look like this:
command:openwindow(_new, rtsp://realserver.example.com/comedy.rm, autosize=true, ontopwhileplaying=true)
command:openwindow(_blank, rtsp://realserver.example.com/animals.rm, autosize=true, ontopwhileplaying=true)
Use either _current
or _self
to open the URL in the current window. The following example is for RealText:
<a href="command:openwindow(_self, rtsp://realserver.example.com/comedy.rm)">Comedy Hour</a>
The next RealText link plays the clip at double its encoded size:
<a href="command:openwindow(_current, rtsp://realserver.example.com/animals.rm, zoomlevel=double)">Sharks!</a>
The following are the same commands issued through Get URL in Flash:
command:openwindow(_self, rtsp://realserver.example.com/comedy.rm)
command:openwindow(_current, rtsp://realserver.example.com/animals.rm, zoomlevel=double)
A SMIL file does not display text on-screen, so it does not support the text links described in the preceding samples. However, SMIL can make hyperlinks from GIF, JPEG, and PNG images, or from any other type of clip that displays on-screen. For example, you can use an image file as a button that opens a new RealPlayer window. The following example shows a hyperlinked image file within a SMIL file:
<smil>
...
<a href="command:openwindow(_new, rtsp://realserver.example.com/animals.rm)">
<img src="launch_button.gif" region="button"/>
</a>
...
</smil>
Note that the hyperlink syntax is the same as described for RealText in the preceding sections.
![]() |
Additional Information |
---|
For basic information on SMIL hyperlinks, see "Linking to Other Media". |
With SMIL, you can create hotspot links ("image maps") over any clip. The following example defines a hotspot link over the upper-left quadrant of a RealVideo file. Clicking this hotspot activates the hyperlink URL in a new RealPlayer window:
<smil>
...
<video src="rtsp://realserver.example.com/video/video1.rm" region="video">
<anchor href="command:openwindow(_new,
rtsp://realserver.example.com/video/video2.rm)" coords="0,0,25%,25%"/>
</video>
...
</smil>
![]() |
Additional Information |
---|
See "Defining Hot Spot Links" for the basics of creating hot spots. |
Using RealPlayer 7 or later, you can cache on disk any files delivered through HTTP. You may want to cache GIF, JPEG, or PNG images that are part of a SMIL presentation, for example. Caching images is beneficial for viewers who reload or revisit presentations frequently. An example is an Internet radio station that uses GIF logos and on-screen buttons. As long as the GIFs reside in the RealPlayer cache, the server does not have to resend the files if, for example, the user clicks a link that opens a new SMIL presentation containing the same images.
Caching works only for files delivered through HTTP. You should not try to cache large clips that would be served better through RTSP, such as video, audio, RealText, Flash, and RealPix clips. (RealPlayer caches RealPix images in memory, but not on disk, for the duration of the RealPix presentation.) Nor should you cache ads or images that do not appear consistently in your presentation.
RealPlayer 7 or later caches files within the RealPlayer home directory in a folder named cache_db. Its cache is independent of any Web browser cache. The default RealPlayer cache size is 4 MB, although the user can change the size. The cache is limited in size because it is meant to hold small images such as buttons and logos, not large graphics or streaming clips.
![]() |
Note |
---|
Caching does not work with RealPlayer G2. For information on using caching with later versions of RealPlayer while still supporting RealPlayer G2, see "Switching Presentations for Different RealPlayer Versions". |
RealPlayer does not cache all items streamed by HTTP. Instead, you designate files to cache by using chttp://
instead of http://
in the file URLs. When RealPlayer reads a CHTTP URL in a SMIL file, it first checks its disk cache for the file. If the file is not present, RealPlayer requests the file through HTTP, storing the file in its cache. Because RealPlayer interprets a chttp://
URL as a special instance of HTTP downloading, caching works for any file stored on an HTTP-compatible server.
If a file is stored in RealPlayer's cache, RealPlayer reuses the file instead of requesting it again from the server as long as a CHTTP URL is used. The cached version is not used, though, if the URL starts with http://
or differs in any way from the original CHTTP URL. Also, any new file requested through RTSP, HTTP, or PNA is not cached. The following SMIL example indicates that the specified GIF image should be downloaded and cached for later use:
<img src="chttp://
www.example.com/images/image1.gif" region="image"/>
This URL causes RealPlayer to store image1.gif in the cache for later use until the cached file expires or is overwritten. For the cache expiration rules, see "Cache Size and Expiration Rules".
Because RealPlayer supports the same HTTP header fields used to control file expiration in Web browser caches, it can carry out caching directives set by Web servers. Thus, you can reuse Web page images in RealPlayer presentations without losing control of how these images are cached. This section describes how to use HTTP headers to control the RealPlayer cache, and how RealPlayer manages its cache. Documentation for most Web servers includes information about how to set fields in HTTP header files.
The Cache-Control
command of an HTTP header file can override caching of a RealPlayer file requested through chttp://
. A file requested through CHTTP is not cached if any of the following are present as meta-information in the HTTP header file:
By default, RealPlayer's HTTP cache size is set to 4 MB, although users can modify this size. Unless an HTTP header sets a file lifetime, the cached file expires after 4 hours. A subsequent request for a cached item restarts the item's expiration clock. As the cache fills, RealPlayer begins to delete unexpired items to reclaim needed disk space on a first-in, first-out basis.
Within an HTTP header, you can have Cache-Control:max-age
set the "time to live" (TTL) for a cached file, overriding the default expiration time. Expressed in seconds, the maximum age is added to the current time to yield the file's expiration time. This value must be between 60 seconds and one year. For example:
Cache-Control:max-age=172800
If you do not use the Cache-Control:max-age
field, you can have the Expires
field determine the file's expiration time. The Expires
field takes as an attribute a date string that defines when the cached element expires, relative to the caching computer's clock. The date string is formatted as follows:
Expires= Wdy, DD Mon YYYY HH:MM:SS
GMT
The weekday is optional. In the following two examples, the first example includes a weekday designation, the second one does not:
Expires= Fri, 17 Mar 2000 19:37:09 GMT
Expires= 17 Mar 2000 19:37:09 GMT
The weekday and month abbreviations are as follows:
Day of week: | Mon, Tue, Wed, Thu, Fri, Sat, Sun |
Month: | Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec |
![]() |
Note |
---|
The entry is not cached if the value in the Expires: field
predates the current date and time.
|
RealPlayer users can control some aspects of RealPlayer's cache by disabling the cache, setting the amount of disk space available for the cache, and emptying the cache. Users carry out these actions through the RealPlayer preferences. For more information, see the RealPlayer online help.
To cache files, write your SMIL file to download the cached items before other streamed elements. You can do this by placing the cached elements in a SMIL <seq>
group ahead of the streamed elements. The following SMIL extract, which omits the header information for convenience, caches two logo images. The SMIL file is for a presentation in which logos stay the same but the streaming RealVideo and RealText clips change frequently:
<smil>
...header omitted from example...
<body>
<seq>
<!-- First, download and cache these two logos. -->
<img src="chttp://www.example.com/images/logo1.gif?bitrate=20000"
region="logo1" fill="freeze"/>
<img src="chttp://www.example.com/images/logo2.gif?bitrate=20000"
region="logo2" fill="freeze"/>
<par>
<!--Second, stream these 2 clips in parallel. -->
<textstream src="rtsp://realserver.example.com/news.rt"
region="newsregion" fill="freeze"/>
<video src="rtsp://realserver.example.com/newsvid.rm"
region="videoregion"/>
</par>
</seq>
</body>
</smil>
In this example, the two logos quickly download in sequence. Next, RealServer streams a parallel group comprising the RealVideo and RealText clips. When RealPlayer plays this presentation again, it first checks its cache for the two logos. If it finds them, it skips directly to the streaming clips.