Easy to configure and use, RealServer's ad banner rotation feature can insert a series of ad images into any SMIL presentation. You might show in RealPlayer a new ad image every 30 seconds, for example, with clickthrough URLs thrown to the viewer's browser. The ad rotation feature works for prerecorded content as well as live broadcasts, serving ads from any ad server. It supports GIF, animated GIF, and JPEG ad files.
RealServer repackages the banner ads as a RealPix stream to manage bandwidth and provide graceful fade-in transitions between ad images. You do not need to learn any RealPix mark-up to employ ad rotation, however. You only need to specify a few simple ad rotation options in each SMIL file. The following sections explain rotating banner ads and tell how to set them up for a SMIL-based presentation. You can edit the RealServer configuration file manually or use the Web-based RealSystem Administrator.
 |
Note |
|---|
| Using the Web-based RealServer Administrator interface is not described in this document. |
The following figure illustrates the process for streaming rotating banner ads to RealPlayer:
<a href="http://realserver.company.com/ramgen/audio.smil">
|
|
Note |
|---|
| RealServer's automatic SMIL generation feature does not work for ad banner rotation. You must set up the SMIL file in advance. |
<img.../> tag specially configured for rotating banner ads. The tag looks like the following example, which has some detail omitted:
<img src="rtsp://.../shellfs/ads.rpa?adurl=http://...&bitrate=10000
&interval=30&dur=9:00.0" .../>
The RTSP URL includes a mount point, such as /shellfs/, that routes the request through RealServer's shell file system. It also has an adurl option that tells RealServer where to get the banner ads. Other options set the streaming bit rate, display interval, and overall duration for the banner ads. The <img.../> tag can contain any other SMIL attributes as well.
ads.rpa file, which is in the "RealPix Ads" format used solely for streaming rotating banner ads. It's important to note that this file does not exist on the RealServer file system: it's created in memory only.
adurl option. This provides it with the image file and hypertext link URLs for the first banner ad.
adurl option to get new banner ads, streaming these ads to RealPlayer as part of the ads.rpa file.
The ad banner rotation feature works independently of RealServer's general ad serving feature. Within the RealServer configuration file, you set up the shell file system defined within the FSMount mount point list. Most variables for this file system mount point are configured by default, so you do not need to change much information:
<List Name="FSMount">
...other mount points...<!-- RealSystem Shell File System -->
<List Name="RealSystem Shell File System">
<Var ShortName="pn-shell"/>
<Var MountPoint="/shellfs/"/>
<Var AdRetrievalMountPoint="/httpfs/"/>
<Var AdPlaybackMountPoint="/httpfs/"/>
<Var StartupImage="/images/startad.gif"/>
</List>
</List>
|
|
Note |
|---|
| Before editing the configuration file, make sure you understand the file's XML-based syntax. For more information, see the configuration file appendixes in RealServer Administration Guide. |
The user-defined list name ("RealSystem Shell File System" in the example above) should identify the plug-in.
RealServer uses the short name to identify the shell file system plug-in. Use the predefined short name: pn-shell.
By default, the shell file system defines /shellfs/ as its mount point. You may change this mount point, although doing so is not necessary. This mount point is used in SMIL URLs for rotating banner images.
This variable defines the mount point, and thereby the file system plug-in, that RealServer uses to retrieve the banner ad URLs. In most cases this will be the HTTP file system:
<Var AdRetrievalMountPoint="/httpfs/"/>
The specified mount point must also be defined within the FSMount list. Here is an example:
<List Name="HTTP">
<Var ShortName="pn-http"/>
<Var MountPoint="/httpfs/"/>
</List>
This variable defines the mount point, and thereby the file system plug-in, that RealServer includes in the banner ad URLs it sends to RealPlayer. In most cases this will be RealServer's HTTP file system:
<Var AdPlaybackMountPoint="/httpfs/"/>
The optional start-up image is a "dummy" ad file that RealServer streams to RealPlayer when the presentation starts. It fills the ad banner region while RealServer retrieves the first ad URL from the ad server and streams it to RealPlayer. If you don't define a start-up image, the banner ad region is blank until the first ad arrives. The variable requires the full path to the image on RealServer:
<Var StartupImage="/images/startad.gif"/>
In this example, the start-up image is startad.gif, which resides in the images subdirectory off RealServer's "/" mount point. You could also use an image on a Web server:
<Var StartupImage="/httpfs/http://www.company.com/startad.gif"/>
Here, RealServer gets the image off a Web server through its HTTP file system (the /httpfs/ mount point). If this Web server is local to RealServer, the latency between presentation start and image display will be low.
|
|
Note |
|---|
| Make sure the start-up image is the same size as the rotating banner ads you'll use. |
To include rotating banner ads with clip requests, you create a SMIL file that defines regions for the banner and the clips. In the SMIL <body> section, you add an <img.../> tag that specifies rotating banner ads through its source URL. Here's a full URL example:
<img src="rtsp://lizh.real.com:8800/shellfs/ads.rpa?adurl=
http://www.real.com/ads/g2ads_4.html&bitrate=10000&interval=30
&dur=9:00.0" region="ad_banner"/>
This <img../> tag consists of a src URL that contains a basic RTSP URL:
rtsp://lizh.real.com:8800/shellfs/ads.rpa
This URL contains the RealServer address and, if needed, RTSP port. The /shellfs/ mount point sends the request to the shell file system. The requested file, ads.rpa in the example above, does not exist on the server's file system. The server creates ads.rpa as a live RealPix stream of rotating banner ads. You can specify any file name as long as it has the .rpa extension, which stands for "RealPix Ads." Following the name of the virtual file, the src URL has several options and operators.
A question mark operator ("?") separates the first image option from the request URL in the image src attribute. The URL requires multiple options, however, and an ampersand ("&") precedes each image option after the first option. There are no spaces between options and these operators.
This attribute takes as a value the full URL to the target HTML file where RealServer gets URLs for the rotating banner ads. RealServer requests this file each time it needs to send a new banner ad. It then parses the HTML file to get the ad image and link URLs, repackaging the URLs as part of the live RealPix stream. Do not enclose the URL to this HTML file in quotation marks.
 |
Additional Information |
|---|
| This ad target HTML file is described in "Ad Target HTML Page". |
RealServer streams banner ads to RealPlayer at this rate, which is in bits per second. The default value is 4,000 bits per second. Keep in mind that the ad stream bit rate is part of the overall presentation bit rate. If you want to deliver a 20 Kbps video over 28.8 Kbps modems, for example, do not use a 4,000 bps ad stream. The total presentation bit rate of 24 Kbps is too high because you need to reserve more than 4.8 Kbps for overhead, noise, congestion, packet loss, and so on.
|
|
Additional Information |
|---|
| See the bandwidth chapter in RealSystem G2 Production Guide. This manual is available for download from http://service.real.com/help/library/encoders.html. |
This is the frequency in seconds that new banner images appear in RealPlayer. The default is 45 seconds. You need to make sure that bitrate and interval work for the ad size. With bitrate=1000 and interval=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.
The following table lists some common interval times and banner ad sizes, showing the minimum bit rate required for each combination. For example, the table shows that for 9-Kilobyte ads rotated every 30 seconds, you need to stream ads at a minimum of 2460 bits per second.
This required attribute sets the time frame during which banner ads are sent. For a live stream, set dur=live. For a prerecorded, on-demand presentation, set the ad stream duration to approximately the same length as the requested presentation. Specify the ad banner lengths in this format:
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. If the requested content is a five minute, thirty-second video, for example, set the ad banner duration to the same length:
dur=5:30.0
 |
Tip |
|---|
| To determine a SMIL presentation's length, play the SMIL file and observe the presentation length readout in RealPlayer's status bar. |
You can set the ad banner duration shorter than the requested content if you do not want ads to rotate for the entire length of the presentation. In this case, a fill=remove or fill=freeze attribute included in the ad banner <img.../> tag determines if the last ad banner disappears or remains on the screen, respectively.
RealNetworks does not recommend setting the ad duration significantly higher than the length of the requested content. RealPlayer considers the ad banner duration when calculating the total presentation running time. If a video is 10 minutes, for example, but its ad banner duration is 20 minutes, RealPlayer indicates in its status bar that the presentation is 20 minutes long. A viewer may think the video is 20 minutes long and move the RealPlayer clip position slider forward to, for example, the 18-minute mark. Here the video has stopped, and the viewer may believe the presentation is flawed.
This section explains a sample presentation that include a live RealAudio broadcast along with rotating RealPix banner ads. The following figure shows snapshots of RealPlayer during three sequential banner ads for the broadcast.
The following is the SMIL file used to request the RealAudio broadcast and the rotating banner ads. Note that the layout section defines an industry-standard size (468 by 60 pixels) for the banner ads region. The ad region is centered against the black background of a slightly larger root-layout region. Although it doesn't have to be larger that the ad region, the root-layout region must be defined. Within the SMIL file body, the broadcast and the banner ad image URL are defined to play in parallel:
<smil>
<head>
<meta name="title" content="Continuous Rotating Banner"/>
<meta name="author" content="RealNetworks, Inc."/>
<meta name="copyright" content="(c) 1999"/>
<layout>
<root-layout height="100" width="500" background-color="black"/>
<region id="ad_banner" left="17" top="20" height="60" width="468"/>
</layout>
</head>
<body>
<par>
<!-- URL for rotating banner ads -->
<img src="rtsp://lizh.prognet.com:8800/shellfs/ads.rpa?adurl=
http://www.real.com/ads/g2ads_4.html&bitrate=10000&interval=30
&dur=live" region="ad_banner"/>
<!-- Requested content -->
<audio src="rtsp://realserver.company.com/encoder/live.rm"/>
</par>
</body>
</smil>
When a viewer requests the SMIL presentation shown above, RealServer creates the RealPix ad file ads.rpa in memory. The shell file system then requests the file http://www.real.com/ads/g2ads_4.html at regular intervals. This HTML file is set up with an #include tag that expands to a banner ad URL when the file is served. Here's an example of an HTML file returned to RealServer:
<HTML>
<BODY>
<!-- this is the ad -->
<A HREF="http://www.amazon.com/exec/obidos/ASIN/0679433740/realamzntom">
<IMG SRC="http://images.real.com/ads/pics/amzbocelli_rsr.gif"></A>
</BODY>
</HTML>
Each time this file is returned, RealServer parses it to extract the image and hyperlink URLs, repackaging them as a RealPix image within ads.rpa, then streaming them to RealPlayer.
