RealServer can dynamically insert ads into streaming presentations. Offering integration with any HTML-based ad serving system, RealServer uses SMIL (Synchronized Multimedia Integration Language) to lay out ads and requested content in RealPlayer. This chapter explains how to set up RealServer's ad streaming features.
RealServer requires no special programming to integrate with popular ad serving systems. Ad servers are designed to place ad URLs in requested Web pages. To get ads from a third-party ad server, RealServer simply requests HTML containing the ad URLs from the ad server. That HTML may come directly from the ad server, or through a page hosted on a Web server.
When it receives the returned HTML, RealServer extracts the ad's file URL and hypertext link URL. It then inserts these URLs into the SMIL presentation requested by RealPlayer. Through this method, any third-party ad server designed for HTML pages can serve ads to the SMIL-based RealPlayer.
RealServer can deliver single banner ads and rotating banner ads for prerecorded content or live broadcasts. With rotating banner ads, RealServer sends RealPlayer a new GIF, animated GIF, or JPEG ad at regular intervals throughout a presentation. To include ads with requested clips, content creators write a SMIL file that has one or more regions for ads. Instead of ad URLs, the SMIL file contains one or more <RealAdInsert/> tags that RealServer expands into unique ad URLs when RealPlayer requests the file. You can also use the SMIL generation feature, described below, to avoid writing SMIL by hand.
Although RealServer can deliver standard banner ads, its power lies in its ability to stream ads in formats such as RealAudio, RealVideo, RealText and Flash. The delivery mechanism for streaming media ad URLs is the same as for static image ad URLs: the ad server places URLs in HTML requested by RealServer. The only difference is that these ad URLs are for RTSP-streamed clips on a RealServer host, rather than for HTTP-downloaded image files on an ad server.
RealSystem uses SMIL for ad layout. Although you have more flexibility when writing your own SMIL files, RealServer's SMIL generation feature can automatically create or modify SMIL files that include ads. You can thereby stream ads without writing or modifying SMIL files by hand. This feature is useful if you have a large collection of existing clips or SMIL presentations for which you want to include ads. SMIL generation works for banner ads as well as lead-in ads.
RealServer comes preconfigured for inserting banner ads into streaming presentations. Follow the steps below to see a sample streaming banner ad.
yourserver.com, and RealServer's RTSP port for 554:
rtsp://yourserver.com:554/adtag/general/smilgen/banner/g2video.rm
Requesting this URL verifies that ad streaming works by playing the g2video.rm clip included with RealServer. The /smilgen/banner/ mount point in the URL causes RealServer to generate a SMIL file that defines a banner ad region and a video region. The /adtag/general/ mount point is preconfigured to pull a banner ad from a RealNetworks Web server.
You can quickly modify RealServer to pull ads from your ad serving system instead of the RealNetworks Web server. Just point RealServer to a Web page that provides the ad URLs.
/adtag/general/.
To retrieve ad URLs, RealServer can integrate directly with many ad serving systems. It can also request an HTML page on a Web server to get ad URLs. For more on these two methods, refer to "Getting Ad URLs from an Ad Server".
These mount points, which determine what type of ad RealServer streams, appear in URLs for requested content. "Configuring RealServer to Stream Ads" tells how to set up the mount points and configure ad streaming features.
If you have a lot of existing content for which you want to include ads, this optional feature can save you much time and effort. See "Generating SMIL Files for Ads" for more information.
Content creators refer to the ad chapter in RealSystem Production Guide for instructions on creating SMIL files with <RealAdInsert/> tags. They rely on you for information about RealServer's specific ad streaming features, however. You need to communicate the following to content creators:
 |
Additional Information |
|---|
| Override options are described in "Overriding Mount Point Settings through SMIL". To view RealSystem Production Guide, click Resources under Help in RealSystem Administrator. |
To stream an ad, RealServer gets the URL to the ad clip (whether a static image or a streaming clip such as video) from an ad serving system. You can integrate RealServer directly with many popular ad servers. Or RealServer can get ad URLs through a Web server integrated with an ad server. Both options are described below. The location RealServer accesses to get ad URLs is its target URL. Each target URL returns URLs (both the file URL and the clickthrough URL) for a specific type of ad.
The types of ads RealServer streams relate directly to the target URLs. To stream just one type of ad, you need just one target URL where RealServer gets all ad URLs. If you plan to stream different types of ads, such as image banner ads and streaming video clips, though, you need target URLs for each ad type. Several things determine the "ad type":
A GIF or animated GIF image has a different file format than a streaming video clip. If you host both GIF and RealVideo ads, for example, you'll need at least two target URLs, one for each file format.
For some presentations, you might insert full-size banner ads (468 pixels by 60 pixels). For others, you may include half-size banner ads (234 pixels by 60 pixels). You need to set up a different target URL for each ad size. Similarly, you'll need a different target URL for each size of RealVideo ad you stream.
You may want to use different ads based on the subjects of your streaming presentations. Streaming sports clips may have different advertisers than streaming news stories, for example. You can use different target URLs when ads are the same size and formats, but reach different audiences.
RealServer can integrate with several ad streaming systems. Each system may work differently, however. Suppose you stream just standard banner ads, but pull the ads from two different ad serving systems. You'll need two different target URLs, one for each system, even if the ads have the same format, size, and audience.
Combinations of file format, file size, audience, and ad serving system make up the types of ads RealServer gets from target URLs. As "Understanding Ad Streaming Mount Points" explains, the number of target URLs you use determines how many ad streaming mount points you set up.
The following points and guidelines apply to ad files and ad URLs used in streaming RealServer presentations:
<RealAdInsert/> tag in the SMIL file. If the file has two <RealAdInsert/> tags, for example, RealServer requests the target URL twice and uses the ad URL returned with the first request for the first <RealAdInsert/> tag, the URL returned with the second request for the second tag.
 |
Note |
|---|
| RealPlayer users can disable cookie support in their RealPlayer preferences. |
RealServer works with a number of popular ad serving systems. To integrate RealServer with the ad serving system you're using, see this document:
http://docs.real.com/docs/adapp.pdf
This document explains how to get ad URLs through HTML generated directly by different ad serving systems. Typically you do this through a target URL that causes the ad server to return the ad URLs you want. You then tie this target URL to a RealServer mount point, as described in "Creating Ad Streaming Mount Points".
Integration information is given in this separate document, rather than this manual, so that RealNetworks can provide you with the latest information. To read this document, which is in Adobe's Portable Document Format (PDF), use the free Acrobat Reader, available here:
http://www.adobe.com/products/acrobat/readstep.html
If the integration document does not cover the ad server you're using, you can set up a target HTML page on a Web server.
Integrating RealServer directly with your ad serving system is the preferred method for getting ad URLs. However, RealServer can also retrieve ad URLs by requesting an HTML page integrated with an ad serving system. This target page may be an existing Web page on your site, or a page specifically set up to provide RealServer with ad URLs. By using this page as an intermediary for exchanging ad URLs, RealServer can work with virtually any ad serving system.
You set up your HTML target page as required by your ad serving system. For example, some systems require a page to have a server-side #include tag that expands into ad URLs when the page is served. When RealServer requests the page, the returned page should have mark-up that includes an <img src=...> tag for the ad file, as well as a clickthrough hypertext link, similar to this:
<a href="http://www.real.com">
<img src="http://images.real.com/ads/adsalesrg.gif">
</a>
RealServer then replaces the requested SMIL file's <RealAdInsert/> tag with these URLs.
|
|
Additional Information |
|---|
| Refer to your ad serving system's documentation for information on how to insert ad URLs into the target HTML page each time it is requested. |
In addition to the general points listed in "Guidelines for Ads in Streaming Presentations", the following points apply when you get ad URLs through an HTML page hosted on a Web server:
realad="1" in the image source tag. The realad value "1" is a syntax requirement that simply tells RealServer which image to use. Using the realad variable requires you to configure the ad server to include the variable in the returned HTML. Here is an example:
<img src="http://www.real.com/ads/nbcconan.gif" border=0 alt="Win a Great Spring Break!" realad="1">
realad="1" value is present, RealServer uses the first <img src=...> tag in the HTML file as the ad source.
 |
Warning |
|---|
| If other hyperlinked images precede the desired ad image, RealServer may not be able to distinguish the correct URL to extract. |
As described above, the target URL typically returns ad URLs that RealServer incorporates into the requested SMIL file. However, the ad server can also return a full presentation SMIL file. To set this up, you modify your ad server to generate SMIL mark-up, including a layout, ad URLs, requested clip URLs, and any other SMIL attributes. The returned SMIL file must start with <smil> and end with </smil> as shown here:
<smil>
<body>
...all SMIL mark-up...
</body>
</smil>
RealServer recognizes that the ad server has returned SMIL mark-up rather than simple ad URLs. Instead of streaming the SMIL file RealPlayer originally requested, RealServer streams the returned SMIL mark-up in full. The requested SMIL file just needs to be a shell for a <RealAdInsert/> tag:
<smil>
<RealAdInsert/>
</smil>
The following table illustrates the basic steps involved in generating a SMIL file by an ad server. If you integrate RealServer directly with an ad server, you don't use an HTML target file as shown in column 2. Rather, the target URL causes the ad server to return the mark-up shown in column 3. Some syntax details have been omitted for clarity.
RealServer can insert a banner ad, rotating banner ad, or streaming ad clip into a requested SMIL file. Content creators lay out the presentation with SMIL, but instead of including URLs to ad clips, they add <RealAdInsert/> tags that cause RealServer to get ads from an ad server. The URL for the SMIL file request determines what type of ad RealServer inserts in place of a <RealAdInsert/> tag.
Once you've determined how many ad types you need to stream, you can plan the mount points you'll need. ("Understanding Ad Types" explains how various factors make up an "ad type.") Each mount point gives RealServer a different target URL where it finds the ad URLs. If one type of ad, such as a GIF banner ad, works for all content you stream, set up just one ad streaming mount point, such as /adtag/general/. You'll probably need to set up several mount points, however.
Once you've set up the mount points, the ad used to replace a <RealAdInsert/> tag depends on the URL used to request the SMIL file. Here's an example of a SMIL request URL:
<a href="http://realserver.example.com:8080/ramgen/adtag/general/start.smil">
The target URL defined for the /adtag/general/ mount point determines what type of ad replaces the SMIL file's <RealAdInsert/> tag or tags. <RealAdInsert/> tags may have parameters that override the settings, though. Additional mount points not related to ad streaming, such as a mount point to verify a user name and password, may precede an ad streaming mount point in the SMIL file request URL:
<a href="http://realserver.example.com:8080/ramgen/secure/adtag/general/start.smil">
To stream more than one type of ad, you define additional mount points like these:
/adtag/sports/
/adtag/tech/
These mount points appear in different request URLs that target different types of ads:
<a href="http://realserver.example.com:8080/ramgen/adtag/sports/start.smil">
<a href="http://realserver.example.com:8080/ramgen/adtag/tech/start.smil">
 |
Tip |
|---|
| Although you can create a new mount point for every ad type you stream, you do not always have to do this. In some cases, it is easier to use SMIL to override a mount point's settings, rather than create a new mount point. Before you set up mount points, read "Overriding Mount Point Settings through SMIL". |
Ad streaming mount points like /adtag/general/ constitute "virtual paths" that invoke RealServer's ad streaming feature. The base mount point represents the actual file system mount point RealServer uses to find the requested file. When you define an ad streaming mount point, you also indicate its base mount point. For example, this entry for a base mount point:
/
means RealServer uses the file system plug-in associated with the mount point "/" to locate the requested file. In RealServer Administrator, the General Setup section defines these file system mount points. The value "/" typically indicates RealServer's default file system plug-in that locates unsecured files on local disks. So for this request:
<a href="http://realserver.example.com:8080/ramgen/adtag/general/start.smil">
RealServer locates the file with a UNIX path such as the following, depending on the directory path associated with the "/" mount point:
/RealServer/content/start.smil
On Windows, the path may look like this:
G:\RealServer\content\start.smil
If RealServer contains secure content, authorization is verified only on the initial request URL, not when RealServer accesses the file through the base mount point. This creates a security risk if ad streaming requests are unsecured, but secure content resides below the directory defined by the base mount point. If your RealServer hosts secure content, but ad streaming requests are unsecured, make sure the ad streaming base mount point does not lead to a secured directory.
To illustrate how a security hole can occur, suppose the ad streaming mount point uses a base mount point of "/", which is defined in the RealSystem Administrator's Mount Points section as this path:
/RealServer/content/
If this path leads to a secured directory such as:
/RealServer/content/protected/
someone can access content in this directory through the ad streaming system by using a URL such as this:
<a href="http://realserver.example.com:8080/ramgen/adtag/general/protected/start.smil">
This URL uses the Ramgen (/ramgen/) and ad streaming (/adtag/general/) mount points, but no security mount point. Here, /protected/ is not a mount point, but the directory below the base mount point directory. Because the URL has no security mount point, RealServer does not validate the request before accessing the file in this path:
/RealServer/content/protected/start.smil
To prevent security problems, keep unsecured and secured content in separate paths. For example, you might use these mount points for unsecured and secure content:
/
/secured/
These mount points might lead, respectively, to these paths on UNIX:
/RealServer/content/
/RealServer/secure/
G:\Program Files\Real\RealServer\Content
G:\Program Files\Real\RealServer\Secure
A security risk is not present because the unsecured directory path does not lead to the secured directory path. For information on secure directories and authenticated content, refer to Chapter 15, "Authenticating RealServer Users".
The mount point /adtag/general/ is predefined. You can modify this mount point, as well as create new mount points.
/adtag/tech/
|
|
Additional Information |
|---|
| For the background on ad streaming mount points, see "Understanding Ad Streaming Mount Points". |
/".
|
|
Additional Information |
|---|
| See "Choosing the Ad Streaming Base Mount Point" for more information. |
|
|
Additional Information |
|---|
| See "Getting Ad URLs from an Ad Server". See also "Overriding Mount Point Settings through SMIL" for details on overriding where RealServer gets ad URLs. |
The Ad Server Type setting affects the clickthrough URL of an ad that appears in RealPlayer. If you use the DoubleClick ad serving system, for example, choose the DoubleClick option. When you choose one of the named ad serving systems, make sure you have integrated RealServer with that system as described in "Integrating RealServer Directly with an Ad Server".
If you do not use one of the named ad serving systems, choose the Default setting and finish configuring the mount point as described in this section. Apply the changes, and use RealPlayer to request ad content through the mount point. Click the ad to verify that it takes you to the correct Web page for the ad sponsor. If the clickthrough does not work, choose Type 1, apply the changes, and try again. If that doesn't work, redo the procedure using Type 2. Once clickthroughs work, choose the same type setting for all mount points used with that ad serving system.
|
|
Additional Information |
|---|
| For background on this option, see "Why are There Different Ad Server Types?". |
Set Resolve Relative URLs to No only if your RealServer hosts the content specified by relative ad URLs. For example, your RealServer might host the GIFs used for rotating banner ads. The ad serving system can then return relative URLs that RealServer sends to RealPlayer. In this case, RealServer doesn't need to resolve the relative URLs because it hosts the content.
For the Ad Server Type field, RealServer presents several name-brand ad serving systems, as well as the three generic options: Default, Type1, and Type 2. These options are present because different ad serving systems handle clickthrough URLs differently. Some ad serving systems return the advertiser's clickthrough URL with the ad image URL. For example, a clickthrough URL http://www.real.com may accompany a RealNetworks ad.
Other ad servers do not return the advertiser's clickthrough URL initially, however. Instead, they record RealServer's IP address and a user agent ID when it requests an ad. Rather than pointing to the advertiser's Web site, the clickthrough URL points back to the ad server and includes RealServer's IP address and ID. This type of URL lets the ad server log the clickthrough before redirecting the request to the advertiser's Web site.
In this case, an error may occur on the ad server because RealPlayer handles clickthroughs rather than RealServer. RealPlayer's IP address will not match RealServer's IP address, so the ad server will not recognize RealPlayer as the client that received the ad. To correct this, RealPlayer routes the clickthrough request through RealServer. Because RealServer then acts as RealPlayer's proxy, the ad server recognizes the clickthrough attempt.
The settings Default, Type 1, and Type 2 cover three possible ways that RealServer can interact with ad servers. It is easier to try out the three possibilities until you find that option that makes clickthroughs work correctly than to research how your ad serving system handles clickthroughs.
When you set up a mount point to stream banner ads in JPEG or GIF format, you can use RealServer's rotation feature to insert fresh ads into the SMIL presentation at regular intervals. You might stream a new ad image to RealPlayer every 30 seconds, for example. The following are the options you set in the Rotating Banner Ads section of the ad streaming mount point dialog.
|
|
Additional Information |
|---|
| The SMIL generation feature or the requested SMIL file lays out the banner ads with the streaming clips. For more on SMIL generation, see "Generating SMIL Files for Ads". The RealSystem Production Guide explains how to lay out banner ads manually with SMIL. |
Select On in this pull-down menu to turn on banner ad rotation for the mount point.
This is the frequency in seconds that new banner ads appear in RealPlayer. Make sure that the interval and the bit rate work for the ad size. With a bit rate of 1000 and an interval of 30, for example, RealServer can stream 30,000 bits (3.6 Kilobytes) during each 30-second interval. This may not be enough for some banner ads.
RealServer streams banner ads to RealPlayer at this rate, which is in bits per second (bps). Keep in mind that the ad bit rate is part of the presentation's overall bit rate. If you want to deliver a 20 Kbps video over 28.8 Kbps modems, for example, do not use a 4000 bps ad stream. The total presentation bit rate of 24 Kbps is too high when you take into account the overhead reserved for network congestion, packet loss, and so on.
The following table lists some common interval times and banner ad sizes, showing the minimum bit rate required for each combination. For instance, the table shows that 9-Kilobyte ads rotated every 30 seconds need to stream at a minimum of 2460 bits per second.
In this optional field, you can enter the location of an image to display before the first ad streams to RealPlayer. The purpose is simply to fill the ad banner region until the first ad appears in RealPlayer. If you don't use a start-up image, the ad region remains blank until the first ad arrives. The start-up image streams at the same bit rate you select for the rotating ads. Do the following to make the start-up image appear as quickly as possible:
/start.gif
RealServer uses two timeout values, each set by default to 5 seconds:
This value determines the number of seconds that RealServer waits for a response from an ad serving system or a Web server when requesting ad URLs.
This value determines the number of seconds that RealServer waits for the ad server or Web server to return the ad URLs after the connection is made.
All timeouts are recorded in the RealServer error log. (The error log is described in "Error Log" .) If ads consistently fail to appear in RealPlayer, the server providing the ad URLs may not be responding fast enough to avoid a timeout. You should first try to fix this latency by using a faster Web or ad server, or increasing the speed of the connection between RealServer and the other server. If ad retrieval still times out, increase the two timeout values by increments of one second until ad retrieval consistently works. Consider the following points when raising the timeout values:
RealServer lets content creators override certain ad mount point settings. Through SMIL, content creators can specify banner ad rotation parameters, as well as where RealServer gets ad URLs. If your RealServer hosts clips for many content creators who use different ad types, this override feature lets you satisfy the creators' different needs without setting up separate ad streaming mount points for each ad type. For example, instead of setting up different banner ad mount points for different audiences, you can set up one mount point, then use SMIL to point RealServer to different target URLs. Each target URL then returns ad URLs for a different audience.
As described in "Creating Ad Streaming Mount Points", you specify where RealServer gets ad URLs when you define each ad streaming mount point. RealServer then requests an ad URL for each <RealAdInsert/> tag included in the SMIL file. Content creators can specify a different target that provides ad URLs, however, by including an AdURL attribute in the <RealAdInsert/> tag:
<RealAdInsert region="adbanner" AdURL="http://www.example.com/ads.html"/>
In this case, RealServer requests the URL specified by the AdURL attribute, not the target defined through Target HTML in the mount point dialog. Keep in mind, though, that the AdURL target must provide ad URLs that work with the mount point's remaining settings. For example, the AdURL target should not return URLs to streaming video ads if the mount point is set up for rotating banner ads. Nor should it target an ad serving system other than the one defined for the mount point.
"Setting Up Rotating Banner Ads" explains how to configure an ad streaming mount point for rotating banner ads. To include these ads in a SMIL presentation, content creators use a <RealAdInsert/> tag like this:
<RealAdInsert region="ad_banner" dur="9min"/>
This tag specifies the SMIL region where the ads appear and how long RealServer sends ads to RealPlayer. Normally, the tag does not specify any ad rotation parameters, which are set instead in the ad streaming mount point. As described above, however, content creators can specify where RealServer gets the banner ad URLs. As well, content creators can override any of the banner ad mount point's Interval, Bitrate, and Startup Image settings:
<RealAdInsert region="ad_banner" dur="9min"Interval="60" Bitrate="2460"
StartupImage="/start.gif"AdURL="http://www.example.com/ads.html"/>
This sample tag overrides the ad mount point's rotation settings with a new ad target URL, a new start-up image, a rotation interval of 60 seconds, and a bit rate of 2,460 bits per second.
RealServer can automatically generate a SMIL file that inserts an ad or series of ads in each streaming presentation. This works for both single clips and existing SMIL files. If your RealServer hosts a large number of RealAudio clips, for example, you can simply have RealServer generate a SMIL file that lays out ads for each clip. Content creators then do not need to write SMIL files or include <RealAdInsert/> tags in existing SMIL files.
|
|
Note |
|---|
| Automatic SMIL generation works in conjunction with ad streaming as described in "Configuring RealServer to Stream Ads", and you must set up ad streaming mount points first. |
Although automatic SMIL generation works in a large number of ad streaming scenarios, it does not provide all the flexibility possible when content creators write SMIL files that include <RealAdInsert/> tags. SMIL generation has these limitation:
Like ad streaming, automatic SMIL generation works through mount points included in the content request URL. The SMIL generation mount points always work in tandem with ad streaming mount points, which are described in "Understanding Ad Streaming Mount Points". For example, a Web page hyperlink to a media clip or SMIL file on RealServer may look like this:
<a href="http://realserver.example.com:8080/ramgen/adtag/general/smilgen/banner/video/video.rm">
Here, the ad streaming mount point, /adtag/general/, determines the type of ad used with video.rm. The SMIL generation mount point, /smilgen/banner/, trails the ad streaming mount point in the URL. It causes RealServer to create a SMIL file that lays out a <RealAdInsert/> tag along with the video clip. If a SMIL file rather than a clip were requested, RealServer would create a new SMIL file that includes the contents of the requested SMIL file along with a <RealAdInsert/> tag.
A mount point such as /smilgen/banner/ might define a layout for a banner ad that is 468 pixels wide by 60 pixels high and appears above the requested content. You can define any number of SMIL generation mount points, such as /smilgen/lead_in/ or /smilgen/banner_below/, for different ad layouts. This lets you support any number of ad types, whether banner ads or streaming media ads, through SMIL generation.
When you define a SMIL generation mount point, it must be relative to the base mount point of the ad streaming mount point used with it. For example, in this request URL:
<a href="http://realserver.example.com:8080/ramgen/adtag/general/smilgen/banner/video/video.rm">
/adtag/general/ is the ad streaming mount point. If this mount point uses the default file streaming mount point ("/") as its base mount point, you simply define the SMIL generation mount point like this:
/smilgen/banner/
If the ad streaming mount point uses a base mount point such as /local/, however, you need to include this base mount point in the SMIL generation mount point definition:
/local/smilgen/banner/
This causes the SMIL generation feature to intercept the file access attempt caused by the ad streaming mount point. The actual file access then occurs through the SMIL generation mount point's base mount point. Note that in the example above, /local/ does not appear in the request URL. It appears only in the SMIL generation mount point dialog.
|
|
Additional Information |
|---|
| For more on the ad streaming base mount points, see "Choosing the Ad Streaming Base Mount Point". |
SMIL generation mount points for lead-in ads, banner ads, and rotating banner ads are predefined. You can modify these mount points or create new ones.
/smilgen/banner_above/
|
|
Note |
|---|
| SMIL generation mount points are relative to ad streaming base mount points. See "Understanding SMIL Generation Mount Points". |
/".
|
|
Note |
|---|
| SMIL generation base mount points have the same security issues related to the base mount points for ad streaming. See "Using Authentication with Ad Streaming" for more information. |
|
|
Additional Information |
|---|
| See "Setting SMIL Options" for descriptions of these options. |
The following are the SMIL generation options you can set for each mount point.
This pull-down menu determines the type of ad used. You can set one of these values:
Banner |
Banner ad that appears alongside requested content. For Ad Position, choose Top, Bottom, Left, or Right. |
Leadin |
Ad that appears before the requested content begins playback. This ad is usually in a format such as RealVideo or Flash. The Ad Position valueis typically Center. |
| Rotating Banner | Rotating banner ad that appears alongside requested content. The Ad Position value should be Top, Bottom, Left, or Right. |
This pull-down menu determines the ad's location relative to the requested content. It can have one of the following values:
Top |
Ad appears above the requested content. The ad and content are centered horizontally within the RealPlayer window. |
Bottom |
Ad appears below the requested content. The ad and content are centered horizontally within the RealPlayer window. |
Center |
Ad appears centered and in front of the requested content. The ad and content are thus centered both horizontally and vertically. In this case, the Ad Type value should be Leadin. Otherwise the ad appears in front of the content as the content plays. |
Left |
Ad appears to the left of the requested content. The ad and content are centered vertically within the RealPlayer window. |
Right |
Ad appears to the right of the requested content. The ad and content are centered vertically within the RealPlayer window. |
In these fields, set the pixel width and height, respectively, of the ad included with the request. RealServer uses these values to lay out the ad in the SMIL file. Make sure that the ad serving system returns URLs to ads of this size.
|
|
Additional Information |
|---|
| See "Getting Ad URLs from an Ad Server". |
The outer padding determines how many pixels of space RealServer adds as a border around all clips. A value of 20, for example, adds 20 pixels of outer padding. The inner padding sets the distance in pixels between the ad and the requested content. It is ignored if the ad is centered in front of the requested content.
Suppose a banner ad appears above the content and is wider than the content, as illustrated in the left image above. If the ad is 468 pixels wide, an outer padding value of 5 makes the RealPlayer window 478 pixels wide. The height of this window is:
root-layout)
InnerPadding value
This field sets the background color for the RealPlayer window. Empty space around the ad and content appears in this color. To specify a color value, use any RGB hexadecimal value (#RRGGBB), or one of the following predefined color names, listed here with their corresponding hexadecimal values:
This field determines whether the viewer has access to the RealPlayer playlist during a lead-in ad. It does not affect banner ads. Set this field to Yes to allow the viewer to skip the lead-in ad clip.