Chapter 8: Clip Source Tags

For every clip you play in your presentation, such as an audio clip, video clip, or text clip, you add a source tag to your SMIL file. This chapter explains the basics of clip source tags, explaining how to write URLs that tell RealONE Player where to find clips. It also tells how to modify certain characteristics, such as background transparency, when clips play.

Creating Clip Source Tags

Each time you want a clip to appear in a presentation, you write a clip source tag that tells RealONE Player where to find the clip. The source tag URL may point RealONE Player to a clip on RealServer, a Web server, or even the viewer's local computer. A typical clip tag looks like this:

<audio src="rtsp://realserver.example.com:554/audio/song1.rm"/>

Within each clip source tag, a src attribute lists the clip location. The section "Writing Clip Source URLs" explains how to specify a URL with the src attribute. As described in subsequent chapters, clip source tags can also contain other attributes that control clip timing and layout. The following table lists the different clip source tags you can use in a presentation.

Clip Source Tags
Clip Tag	Used For
`<animation/>`	animation clips such as a Flash Player file (`.swf`)
`<audio/>`	audio clips such as RealAudio (`.rm`)
`<brush/>`	color block used in place of a clip (See "Creating a Brush Object".)
`<img/>`	JPEG (`.jpg`), GIF (`.gif`), or PNG images (`.png`) (See "Setting a Clip's Streaming Speed".)
`<ref/>`	miscellaneous clip type, such as RealPix (`.rp`) or Ram (`.ram`) file
`<text/>`	static text clips (`.txt`)
`<textstream/>`	streaming RealText clips (`.rt`)
`<video/>`	video clips such as RealVideo (`.rm`)

The particular clip source tag you use does not affect clip playback because RealONE Player determines the actual clip type by other means. Specifying a video clip with an <audio/> tag, for example, does not prevent RealONE Player from recognizing that the clip contains video. Although using a tag appropriate to the clip's contents helps you keep track of clips, you could specify all clips with <ref/> tags, for example. Other clip tags cannot be used in place of the <brush/> tag, however.

Adding a Clip ID

RealNetworks recommends that every clip source tag include a user-defined ID in the form id="ID". Clip IDs are not always necessary, but you will need to use them when building complex presentations in which other SMIL elements refer to clips. Clicking a hyperlink, for example, can start a clip playing. In this case, the hyperlink uses the clip's ID to identify which clip to start. RealONE Player never displays IDs onscreen. Here is an example of a clip ID:

<video src="video1.rm" id="video1"/>

For More Information: For information about selecting ID values, see "SMIL Tag ID Values".

Setting a Clip's Streaming Speed

Clips such as audio, video, and animation have a streaming speed set by the tools used to encode or tune the clips. For these clips, never use SMIL to set a streaming speed. For static clips such as images (GIF, JPEG, or PNG) and text (static text files and streaming RealText files), however, you can use SMIL to change the clip's streaming bandwidth from the default of 12 Kilobits per second (approximately 12000 bits per second). This works only when streaming from RealServer. With Web server hosting, there is no way to set a static clip's streaming speed.

Tip: Small text files stream so quickly that they rarely interfere with other clips. Therefore, you generally do not need to set the streaming bandwidth for text files. You should set a streaming bandwidth for image files larger than 5 Kilobytes, if the 12 Kbps default value is too high or too low for your target audience.

For More Information: For background information on streaming speeds, see "Audience Bandwidth Targets" and "Clip Bandwidth Characteristics".

Using the bitrate Parameter

To set a static clip's streaming speed, you modify the clip source tag to use binary tags, as described in the section "Binary and Unary Tags". Within the binary clip tag, you add a <param/> tag with the name bitrate, and specify the speed in bits per second. The following example sets an image to stream at approximately 5 Kilobits per second:

<img src="poster.jpg" region="image_region" dur="15s">
  <param name="bitrate" value="5000"/>
</img>

RealONE Player does not display an image clip until it has received all the clip's data, and the clip is scheduled to display according to the SMIL timeline. For clips that have no intrinsic duration, such as images and text files (though not RealText clips), you must specify a duration.

For More Information: For more on image durations, see "Setting Durations".

Example of Streaming Images Slowly

Using the bitrate parameter, you can set a high streaming speed for a clip to take advantage of available bandwidth and stream the image quickly. Or you can set a low bit rate to ensure that streaming the image does not interfere with playing another clip at the same time. The following example shows three sequential image files set to stream at 1000 Kbps to ensure that a video playing in parallel does not stall:

<par>
  <video src="video.rm" region="video_region"/>
  <par>
    <seq>
      <img src="ad1.gif" begin="30s" dur="60s" region="ad_region">
        <param name="bitrate" value="1000"/>
      </img>
      <img src="ad2.gif" dur="120s" region="ad_region">
        <param name="bitrate" value="1000"/>
      </img>
      <img src="ad3.gif" dur="60s" region="ad_region">
        <param name="bitrate" value="1000"/>
      </img>
    </seq>
  </par>
</par>

For More Information: For more on SMIL timing, see Chapter 12. Chapter 10 explains group tags such as <par> and <seq>.

Ensuring Reliable Clip Transmission

You can use the reliable value in a <param/> tag to indicate that a clip must be delivered to RealONE Player under any circumstances. During extremely adverse network conditions, RealSystem will halt the presentation if necessary rather than drop the clip. The following example shows the reliable parameter set for an image:

<img src="poster.jpg">
  <param name="bitrate" value="5000"/>
  <param name="reliable" value="true"/>
</img>

Tip: Use the reliable parameter sparingly, and only for small, important elements of your presentation. Even without this parameter, RealSystem generally ensures that very little data loss occurs in transmission.

Warning! The reliable parameter is not for use with large clips such as videos. These clips are designed to play well even if some data is lost in transmission. Using the reliable parameter with these clips may cause your presentation to stall.

Creating a Brush Object

The <brush/> tag lets you create a colored area that displays in a region. It functions just like a clip source tag. For example, you can control when the brush object appears by using SMIL timing commands, and you can change its size and color with SMIL animation tags. Because it does not link to an external clip, though, the <brush/> tag does not use a src attribute. Instead, it uses a color attribute to define the color used:

<brush color="blue" region="region_1" dur="5s"/>

Black is the default color for a brush object. To specify a different color, use a predefined color name, a hexadecimal color value, or an RGB value.

Tip: Appendix D explains the types of color values that you can use with SMIL color attributes.

View it now! (requirements for viewing this sample)
Click this sample to see a simple sequence of brush objects.

Using a Ram File as a Source

A Ram file (.ram) is typically used to launch RealONE Player and give it the URL of the clip or SMIL presentation to play. But you can also use a Ram file as a source of content within a SMIL file. Because a Ram file can list several clips in sequence, you may find it useful to specify a Ram file (a different Ram file from the one used to launch the presentation) within your SMIL file.

To illustrate how a Ram file is useful, suppose that your main SMIL presentation defines an online radio application that plays a preset song list that changes daily. You could list all the songs within the SMIL file in a sequence, like this:

<seq>
  <audio src="song1.rm"/>
  <audio src="song2.rm"/>
  ...more songs...
</seq>

Each day, though, you'd need to modify your main SMIL file to update the playlist. It's easier in this case to have the SMIL file request a Ram file through a <ref/> tag:

<ref src="songs.ram"/>

You then modify the Ram file each day with your new playlist. The Ram file simply gives the full URL to each song in the order in which they play:

rtsp://realserver.example.com/song1.rm
rtsp://realserver.example.com/song2.rm
...more songs...

When you use a Ram file as a source, you can add SMIL timing and layout attributes to the <ref/> tag. In a playlist of videos, for example, you could assign all the videos to play in the same region, which your main SMIL presentation would define. Or you could use timing attributes to give the entire sequence of clips a maximum duration, for instance. You cannot use SMIL attributes within a Ram file, however.

For More Information: For more on Ram files, see "Launching RealONE Player with a Ram File". Note that a Ram file can also list other Ram or SMIL files, as well as clips.

Using a SMIL File as a Source

A SMIL file can also use another SMIL file as a source. Simply use a <ref/> tag to refer to the secondary SMIL file:

<ref src="rtsp://realserver.example.com/presentation2.smil"/>

Unlike a Ram file, a SMIL file can do more than list a simple sequence of clips. A secondary SMIL file can play clips in parallel, for example, and use SMIL timing and layout attributes to organize its clips.

Handling Layouts

When a secondary SMIL file contains visual clips, you assign the entire SMIL file to play within a region defined in the primary SMIL file:

<ref src="rtsp://realserver.example.com/presentation2.smil" region="region_1"/>

In this case, it's best to define the playback region in the main SMIL file (region_1) to be the same size as the root-layout area of the secondary SMIL file. If the playback region and the secondary SMIL presentation are different sizes, the playback region's fit attribute determines how the SMIL presentation fits the region.

For More Information: For information on defining layouts and assigning clips to play in regions, see Chapter 11.

Using Timing Attributes

Timing attributes in the primary SMIL file can override the timeline of the secondary SMIL file. Suppose that presentation2.smil lasts 10 minutes when played by itself, but you set a 5-minute duration in the <ref/> tag in the main SMIL file:

<ref src="rtsp://realserver.example.com/presentation2.smil" dur="5min"/>

In this case the duration specified in the main SMIL file cuts off the last half of presentation2.smil.

For More Information: Timing attributes are described in Chapter 12.

Writing Clip Source URLs

Every clip source tag, except for a <brush/> tag, requires an src attribute that provides the URL for the clip. RealONE Player uses this URL to request the clip from a server. The URL you specify varies depending on whether the clip resides on RealServer, a Web server, or the viewer's local machine.

Tip: As you develop a presentation on your computer, use local URLs. Then put in a base URL, or specify full URLs for each clip, when you are ready to stream your presentation. Chapter 20 explains how to move clips to a server and write a Ram file to launch RealONE Player.

Linking to Local Clips

As you develop your presentation, it is easiest to keep your SMIL file and your clips in the same directory on your local computer. Within your SMIL file, the src parameter for each clip source tag can simply give the file name:

<audio src="song1.rm"/>

Creating Relative Links to Other Directories

RealONE Player can also follow the same relative links that you can use in a Web page. For example, the following src attribute specifies a clip that resides one level below the SMIL file in the audio folder:

<audio src="audio/song1.rm"/>

The following example specifies a clip that resides one folder level above the SMIL file:

<audio src="../song1.rm"/>

The next example creates a link to a clip that resides in an audio folder that is at the same level as the folder that contains the SMIL file:

<audio src="../audio/song1.rm"/>

Tip: You can find additional information about relative directory syntax in an HTML reference guide.

Writing Absolute Links

Alternatively, you can use local, absolute links to specify exact locations. The syntax for absolute links is the same as with HTML. It varies with operating systems, however, and you should be familiar with the directory syntax for the system you are using. For example, the following absolute link syntax works for Windows computers, but not on Unix or the Macintosh:

src="file://c:\audio\first.rm"

Creating a Base URL

When you are ready to stream your presentation, you can add a base URL to your SMIL file. This is convenient if all or most of your clips reside on the same server. This preserves the local, relative syntax you used when developing your presentation, readying your presentation for streaming in a single step. You add the base URL to the file in the SMIL header section through a <meta/> tag as shown here:

<smil xmlns="http://www.w3.org/2001/SMIL20/Language">
  <head>
    <meta name="base" content="rtsp://realserver.example.com/"/>
    ...layout information...
  </head>
  <body>
    <par>
      <audio src="song1.rm"/>
      <textstream src="lyrics/words1.rt" .../>
      <img src="http://www.example.com/images/album3.gif" .../>
    </par>
  </body>
</smil>

Because the third clip in this example uses a full URL, the base target is ignored. RealONE Player requests the image from the specified Web server using the HTTP protocol. For the first two clips, however, the src values are appended to the base target, effectively giving the clips the following URLs:

rtsp://realserver.example.com/song1.rm
rtsp://realserver.example.com/lyrics/words1.rt

Using a base target is highly recommended. If no target is given, RealONE Player assumes that the clip paths are relative to the location of the SMIL file. In the preceding example, for instance, RealONE Player would look for song1.rm in the same directory that holds the SMIL file, requesting the clip with the same protocol used to request the SMIL file.

Linking to Clips on RealServer

When clips reside on RealServer, use an RTSP URL in the base target. Or, you can specify an RTSP URL in each clip's src attribute. An RTSP URL in a clip source tag looks like this:

<audio src="rtsp://realserver.example.com:554/audio/first.rm"/>

The following table explains the URL components. Your RealServer administrator can give you the RealServer address, RTSP port, and directory structure.

RealServer URL Components
Component	Specifies
`rtsp://`	RTSP protocol. Although RealServer also supports HTTP, streaming clips typically use RTSP.
`realserver.example.com`	RealServer address. This varies with each RealServer. It typically uses an identifier such as `realserver` instead of `www`. Or it may use a TCP/IP address (such as `172.2.16.230`) instead of a name.
`:554`	RealServer port for RTSP connections. Port `554` is the default, so you can leave this out of URLs unless the RealServer administrator chose a different port for RTSP communication. If the port number is required, separate it from the address with a colon.
`/audio/`	RealServer directory that holds the clip. The directory structure may be several levels deep. RealServer also uses "mount points" that invoke certain features, such as password authentication. Because these mount points appear to be directories in the URL, the request path does not mirror the actual directory path on the RealServer computer. The RealServer administrator can tell you the mount points and directories in the path.
`first.rm`	Clip file name.

For More Information: For more information on RTSP, see "The Difference Between RTSP and HTTP".

Linking to Clips on a Web Server

To use a clip hosted on a Web server, use a standard HTTP URL in the base target, or in each clip's src attribute. RealServer also supports the HTTP protocol, but for clips streaming from RealServer, you typically use the RTSP protocol or the specialized CHTTP protocol, which is described in the following section. An HTTP URL in a clip source tag looks like this:

<img src="http://www.example.com/images/logo.gif"/>

Warning! Although a Web server can host any clip, a Web server cannot perform all the functions of RealServer. For more information, see "Limitations on Web Server Playback".

Note: RealONE Player does not support secure HTTP connections directly. However, e-commerce forms created in Flash can transmit secure HTTP data through the viewer's Web browser. For more information, see "Secure Transactions".

Caching Clips on RealONE Player

RealONE Player does not cache files by default, but you can make it cache on disk any files delivered through HTTP. You may want to cache images used in different SMIL presentations that site visitors play. An example is an Internet radio station that uses GIF logos and on-screen buttons. As long as the GIFs reside in the RealONE Player 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, Flash, and RealPix clips. (RealONE Player 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 repeatedly in your presentation.

Using the CHTTP Caching Protocol

RealONE Player 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 RealONE Player reads a CHTTP URL in a SMIL file, it first checks its disk cache for the file. If the file is not present, RealONE Player requests the file through HTTP, storing the file in its cache. Because RealONE Player interprets a chttp:// URL as a special instance of HTTP, caching works for any file stored on an HTTP-compatible server.

If a file is stored in RealONE Player's cache, RealONE Player 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. 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" .../>

Example of Using CHTTP in a Presentation

When caching files, download the cached items before streaming other elements. You can do this by placing the cached elements in a SMIL <seq> group ahead of the streamed elements. In the following example, the two logos quickly download before the RealVideo and RealText clips play. If the visitor plays another presentation that also caches the two images, RealONE Player first checks its cache. If it finds the images, it skips directly to the streaming clips:

<smil xmlns="http://www.w3.org/2001/SMIL20/Language">
  ...header omitted...
  <body>
    <seq>
      <!-- First, download and cache these two logos. -->
      <img src="chttp://www.example.com/logo1.gif region="logo1" ...>
        <param name="bitrate" value="20000"/>
      </img>
      <img src="chttp://www.example.comlogo2.gif region="logo2" ...>
        <param name="bitrate" value="20000"/>
      </img>
      <par>
        <!--Second, stream these 2 clips in parallel. -->
        <textstream src="rtsp://realserver.example.com/news.rt" region="news" .../>
        <video src="rtsp://realserver.example.com/newsvid.rm" region="video1" .../>
      </par>
    </seq>
  </body>
</smil>

Controlling the RealONE Player Cache

Because RealONE Player 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 RealONE Player presentations without losing control of how these images are cached. This section describes how to use HTTP headers to control the RealONE Player cache, and how RealONE Player manages its cache. Documentation for most Web servers includes information about how to set fields in HTTP header files.

Overriding Caching with Cache-Control

The Cache-Control command of an HTTP header file can override caching of a RealONE Player 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:

Cache-Control:no-cache

Cache-Control:no-store

Cache-Control:private

Cache-Control:must-revalidate

Cache Size and Expiration Rules

RealONE Player caches files within its home directory in a folder named cache_db. This cache is independent of any Web browser cache. The default RealONE Player cache size is 4 MB. Unless an HTTP header sets a file lifetime, the cached file expires after 4 hours, although a subsequent request for a cached item restarts the item's expiration clock. As the cache fills, RealONE Player begins to delete unexpired items to reclaim needed disk space on a first- in, first-out basis.

Note: RealONE Player users can control some aspects of RealONE Player'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 RealONE Player preferences. For more information, see the RealONE Player online help.

Changing the Lifetime of a Cached File

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.

Modifying Clip Colors

The clip color attributes summarized in the following table are primarily for images in the GIF, JPEG, or PNG format. They can also be used for dynamic clips, though, especially those that include transparency, such as Flash clips. They should not be used for streaming video, however. Note that because these attributes are specific to RealONE Player, other SMIL-based media players may not recognize them.

Clip Streaming and Color Attributes
Attribute	Value	Function	Reference
`rn:backgroundOpacity`	`percentage`	Adjusts background transparency.	click here
`bgcolor`	`nnnnnn`	Substitutes color for transparency.	click here
`rn:chromaKey`	`color_value`	Turns selected color transparent.	click here
`rn:chromaKeyOpacity`	`percentage`	Adds opacity to `chromaKey.`	click here
`rn:chromaKeyTolerance`	`color_value`	Widens range of `chromaKey`.	click here
`rn:mediaOpacity`	`percentage`	Makes opaque colors transparent.	click here

For More Information: Appendix D explains the types of color values you can use with SMIL color attributes.

Adjusting Clip Transparency and Opacity

Two customized attributes let you add transparency to all opaque colors in a clip (rn:mediaOpacity), or adjust transparency in just the clip's background color (rn:backgroundOpacity). You can use these attributes separately or together. Using either of these attributes requires that you declare the following namespace in the <smil> tag:

xmlns:rn="http://features.real.com/2001/SMIL20/Extensions"

For More Information: For the basics of customized namespaces, see "Using Customized SMIL Attributes".

Adding Transparency to All Opaque Colors

The attribute rn:mediaOpacity in a clip source tag causes opaque areas in the clip to become transparent. The attribute takes a percentage value in the range from 0% (fully transparent) to 100% (fully opaque). In the following example, the opaque areas of a GIF image are rendered partially transparent, making them blend with a region's background color or an underlying clip:

<img src="button.gif" rn:mediaOpacity="50%" .../>

Note: If a clip is 50 percent or more transparent (that is, it has a value from 0 to 50 for rn:mediaOpacity), hyperlinks defined for the clip will not work. Clicking the clip will open hyperlinks on clips beneath the partially transparent clip, however. Chapter 14 explains SMIL hyperlinks.

View it now! (requirements for viewing this sample)
In RealONE Player, you can view how the mediaOpacity attribute affects an opaque clip.

Adjusting Transparency in a Clip's Background Color

Using the rn:backgroundOpacity attribute, you can modify the opacity of a clip's background, making the background color more transparent or more opaque. This attribute works only for clips that designate a specific background color, such as GIF, PNG, or RealText clips. It does not work for clips like JPEG images or RealVideo clips that do not explicitly specify a background color.

The rn:backgroundOpacity attribute takes a percentage value in the range from 0% (fully transparent) to 100% (fully opaque). In the following example, the background color specified in the image's palette, which may be fully opaque or fully transparent, is rendered partially opaque:

<img src="button.gif" rn:backgroundOpacity="50%" .../>

If the background color is partially transparent already, rn:backgroundOpacity increases the opacity. If a clip's background is 50 percent transparent already, for example, using rn:backgroundOpacity="50%" adds another 50 percent to the opacity, making the background 75 percent opaque.

Tip: If a clip's background is fully opaque, you can use just rn:mediaOpacity to render the background and all other colors transparent. If the clip's background is partially transparent already, rn:mediaOpacity will not affect the background, and you can use both rn:mediaOpacity and rn:backgroundOpacity in the same clip tag.

View it now! (requirements for viewing this sample)
In RealONE Player, you can view how the backgroundOpacity attribute adds opacity to a transparent background. You can also view semi- transparent RealText subtitles.

Substituting Transparency for a Specific Color

For clips that do not include native transparency, such as JPEG images and Flash clips, you can use three attributes to define a color (rn:chromaKey), or a range of colors (rn:chromaKeyTolerance), that RealONE Player renders transparent or partially transparent (rn:chromaKeyOpacity). Using these attributes requires that you declare the following namespace in the <smil> tag:

xmlns:rn="http://features.real.com/2001/SMIL20/Extensions"

For More Information: For background on customized attributes, see "Using Customized SMIL Attributes".

View it now! (requirements for viewing this sample)
With this sample, you can view how the chroma key attribute substitutes transparency for specified color ranges.

Selecting a Color to Render Transparent

You can use rn:chromaKey to specify a color that RealONE Player will render transparent. In the following example, the hexadecimal color #808080 is made transparent in a JPEG clip:

<img src="picture.jpg" rn:chromaKey="#808080".../>

Tip: You can specify colors by using any color value described in Appendix D. For example, the preceding attribute could use the RGB value "rgb(128,128,128)" instead of the hexadecimal "#808080".

Using Partial Transparency

You can use the rn:chromaKeyOpacity attribute to make the color value selected by rn:chromaKey partially transparent instead of fully transparent. The chromaKeyOpacity attribute uses a percentage value from 0% (the default value of full transparency) to 100% (fully opaque). In the following example, the selected color is rendered 50 percent transparent instead of fully transparent:

<img src="picture.jpg" rn:chromaKey="#808080" rn:chromaKeyOpacity="50%"/>

Expanding the Transparency Range

To achieve the desired transparency effect, you may need to use the attribute rn:chromaKeyTolerance to widen the range of colors selected by rn:chromaKey. Although rn:chromaKeyTolerance uses a value that looks like a single color designation, the value actually specifies a range of colors around (both above and below) the rn:chromaKey value.

The following example uses rn:chromaKey to turn the hexadecimal color #808080 transparent. The rn:chromaKeyTolerance attribute specifies a 1-value tolerance both above and below the designated red value of 80. So in this case, the colors #7F8080 and #818080 are rendered transparent along with #808080:

<img rn:chromaKey="#808080" rn:chromaKeyTolerance="#010000".../>

Setting Red, Green, and Blue Tolerances

In most cases, you'll want to specify tolerance ranges for red, green, and blue. When you do this, only the colors that fall within the overall range set by all the designated tolerances are rendered transparent. For example, the following three attribute pairs are all equivalent, but use different color values, which are described in Appendix D:

rn:chromaKey="rgb(128,128,128)" rn:chromaKeyTolerance="rgb(1,2,3)"
rn:chromaKey="rgb(50%,50%,50%)" rn:chromaKeyTolerance="rgb(0.4%,0.8%,1.2%)"
rn:chromaKey="#808080" rn:chromaKeyTolerance="#010203"

All of the preceding examples define a 1-value tolerance around the specified red value, a 2-value tolerance around the designated green value, and a 3-value tolerance around the selected blue value. Therefore, the colors that have the following RGB values are rendered transparent:

red RGB values 127-129(red hexadecimal values of 7F, 80, and 81)

–And–

green RGB values 126-130(green hexadecimal values of 7E, 7F, 80, 81, and 82)

–And–

blue RGB values 125-131(blue hexadecimal values of 7D, 7E, 7F, 80, 81, 82, and 83)

So, for example, the following colors would be rendered transparent because they fall within the range specified by all three tolerance settings:

rgb(127,128,130), which is equivalent to hexadecimal #7F8082

rgb(128,129,125), which is equivalent to hexadecimal #80817D

However, the following colors would not be rendered transparent because they fall outside the overall range defined by all the red, green, and blue tolerance values:

rgb(126,126,126), which is equivalent to hexadecimal #7E7E7E

This color is not rendered transparent because the red value falls outside the designated red tolerance, even though the green and blue values fall within the designated green and blue tolerances.

rgb(127,128,132), which is equivalent to hexadecimal #7F8084

This color is not rendered transparent because the blue value falls outside the designated blue tolerance, even though the red and green values fall within the designated red and green tolerances.

Tips for Expanding the Color Transparency Range

The rn:chromaKeyTolerance attribute is always used in conjunction with rn:chromaKey. If you use rn:chromaKeyTolerance without also specifying rn:chromaKey, the rn:chromaKeyTolerance value is ignored.

Although you can use any type of color value described in Appendix D for rn:chromaKeyTolerance, RGB percentages are generally the simplest means for expanding the transparency range. Instead of precisely determining in advance the range of colors you want to render transparent, select your rn:chromaKey value, then widen the range with a small percentage value:

rn:chromaKey="rgb(45,199,132)" rn:chromaKeyTolerance="rgb(5%,5%,5%)"

Check the results by playing the SMIL file in RealONE Player, and adjust the various percentage values through trial-and-error until you achieve your desired result.

As explained in the preceding section, a color must fall within the full range of the red, green, and blue tolerances to be rendered transparent. If you want to match all values for red, green, or blue, set its respective tolerance to the maximum. Consider the following equivalent examples:

rn:chromaKey="rgb(128,128,128)" rn:chromaKeyTolerance="rgb(1,255,255)"

rn:chromaKey="#808080" rn:chromaKeyTolerance="#01FFFF"

Both of these examples render transparent any color that has a red value in the RGB range of 127 to 129 (7F, 80, 81), regardless of that color's blue and green values.

Substituting a Color for Transparency

For clips that include transparency, such as GIF and PNG images, you can use bgcolor to substitute a color for the transparency. This attribute uses a <param/> tag, requiring the use of binary clip source tags. The value must be a hexadecimal color value without a leading pound sign (#), as shown in this example:

<img src="button.gif"...>
  <param name="bgcolor" value="BB21AA"/>
</img>

For More Information: For background information on binary tags, see "Binary and Unary Tags".