| E-mail us with your comments and feedback about this article. |
| Describes how to insert personalized advertisements into a broadcast stream that is being delivered to users on Windows Media Player. You'll learn how to create your own broadcast advertising solution by using the step-by-step procedures and sample code included in this article. |
|
Laura Knops
Microsoft Corporation
July 2004
Applies to:
Microsoft® Windows Media® Player 9 Series
Microsoft Windows Media Services 9 Series
Microsoft Windows Media Encoder 9 Series
Contents
Introduction
Broadcasting is a method of delivering a digital media stream to a user in which playback of the stream is controlled at the point of origin, and the user experience is similar to listening to the radio. There are two basic types of broadcasts: a live broadcast, in which a live program is encoded and accessed immediately by a user, and a server-side playlist broadcast, in which the playback of one or more on-demand files is controlled by a Windows Media server.
This article describes how to use Microsoft® Windows Media® technologies to create a broadcast advertising solution, and provides step-by-step instructions and samples for implementing this solution. With broadcast ad insertion, you can add script commands to broadcasts that trigger Windows Media Player to cut away from a broadcast in order to play personalized ads or other content. This broadcast content is defined by client-side or server-side playlists. After the content has been played, the Player resumes the broadcast. This feature can be especially useful when certain broadcast content, such as national commercials, must be replaced with different content in the Internet stream.
There are two scenarios for delivering advertising within a broadcast:
- Traditional broadcast method
- Personalized ad insertion method
Traditional Broadcast Method
The traditional broadcast method of advertising is familiar to users. Advertising and program material are assembled, encoded, and broadcast to multiple users, with everyone receiving the same programming and ads. Because broadcasting over the air is one-way communication, this traditional method is the only way to deliver advertising on television or radio. Figure 1 shows how the components are used in this traditional broadcast method.
Figure 1. Components setup for a traditional broadcast
Personalized Ad Insertion Method
The interactive nature of the Internet provides a number of advertising solutions that take advantage of the two-way communication and direct connections established with every user. With the Internet and Windows Media technologies, you can deliver targeted advertising through personalized ad insertion. Figure 2 illustrates how Windows Media components can be used for personalized ad insertion in live broadcasting.
Figure 2. Components setup for personalized ad insertion in live broadcasting
All users receive the same live broadcast programming. However, the personalized advertising is not included in the live broadcast stream; advertising is delivered to the user as on-demand files, and a method called event switching is used to switch between the live stream and the on-demand streams for each user.
You can create the following types of playlists to define the on-demand files that deliver your advertising:
- Client-side playlists. Entries in a Windows Media metafile (.asx), which are triggered by EVENT commands in the live broadcast stream, initiate the on-demand streams that deliver the advertising. When you use client-side playlists, Windows Media Player controls the streaming experience.
- Server-side playlists. Entries in a server-side playlist (.wsx), which are triggered by FIRE_EVENT commands in the live broadcast stream, initiate the on-demand streams that deliver the advertising. When you use server-side playlists, Windows Media Services controls the streaming experience.
A Web server delivers the instructions to each user's computer that prepare the Player for event switching. The Web server also delivers the playlist that defines the properties for the ads that will be played. Each user can receive a different personalized set of ads. In addition, a database and ad server can be used to further refine the personalization. Figure 3 illustrates the interaction between these Web server components.
Figure 3. Interaction between Web server components
Targeting Your Broadcast Advertising
The benefits of event switching are best appreciated by contrasting how ads reach viewers through standard over-the-air broadcasting with the possibilities using Windows Media technologies. Historically, broadcast ads could only be roughly targeted at viewers, using ratings data as the primary criteria. However, ads sent using Windows Media technologies can be aimed directly at the target user because events and playlists can be automatically generated based on user input.
For example, when a user clicks a link to receive the broadcast of a football game, the link accesses a playlist on a Web server which starts the broadcast stream and prepares Windows Media Player for event switching.
To receive the game, the user enters information about her location. This information is used to determine which ads she will receive. If she lives in Tucson, she will receive advertising localized to that area. The personalization could be further expanded by defining her demographic and by targeting ads for females, age 18 to 49, attending college, and who enjoy rock climbing, for example.
Football game producers also have another motive for using ad insertion in the broadcast besides personalization. Many of the ads in national television broadcasts must be blocked out on the Internet for contractual reasons. As the broadcast proceeds, event switching is used to cut away from the main feed at points when personalized ads must be inserted over national ads. When the personalized ads are finished, the Player resumes the main broadcast feed.
 Back to the top
Implementing Event Switching
In broadcast television and radio, an inaudible tone, cue signal, or precise timing is used to automate the cut away to local breaks from the network feed. Event switching uses a similar method for automating the insertion of ad breaks within a broadcast. For example, during a live Internet broadcast of a ball game, a command can be sent at the beginning of every commercial break that instructs each client (Windows Media Player) to play commercials defined in its playlist. When clients finish playing the commercials, the playlist instructs each client to cut back to the live broadcast. The media content will be rendered only when the streaming media being accessed broadcasts embedded scripting with the matching event name.
With event switching, the signal to switch from the broadcast stream to the on-demand streams that deliver the advertising is sent using script commands. At the point in a live encoding session when a break is to occur, script commands are sent that prepare and execute the switch to an on-demand file in each Player. A script command contains two strings of text. The first string, called the Type, normally contains a command that the Player executes, or passes, to a browser to execute. The second text string, called the Parameter, normally contains additional information that is used in the execution of the command.
For client-side playlists, two script-command types are required. An OPENEVENT command is sent 15 to 20 seconds prior to the point when the switch is to occur. The OPENEVENT command acts as a pre-roll for the ad break. The first ad in the break is located by the Player, and then approximately the first five seconds are downloaded into a memory buffer. At the switch point, an EVENT command is sent. When the EVENT command is received, the switch is made. Because the first part of the ad has been pre-buffered, there is a minimal wait before the ad starts. In some cases, there is little or no additional buffering.
For server-side playlists, a single script-command type is required. A FIRE_EVENT command initiates the switch from the broadcast stream to the on-demand stream that delivers the advertising. If more than one ad is contained in a break, each one is played in order. After the last ad, the Player resumes the main broadcast feed. The wait between ads is minimal because pre-buffering takes place automatically between entries in an event.
The following sections describe how to implement the event switching described in the previous paragraphs. First, you'll learn how to create a client-side playlist or server-side playlist that defines your broadcast advertising content. Then, you'll learn how to insert the event script commands into the encoder session that plays the broadcast ads identified by your client-side or server-side playlist.
Creating a Client-Side Playlist to Define Broadcast Ads
To create a client-side playlist, write your script in a text editor such as Notepad. A playlist script is based on Extensible Markup Language (XML) syntax and made up of elements and their associated tags and attributes. Each element in the script defines a particular setting or behavior in the client, which is Windows Media Player.
The metafile elements are fairly simple. The first line of code defines the file as a Windows Media metafile (.asx) and tells the Player what version of the ASX file format you're using. The metafile contains two primary elements that define your broadcast content: an ENTRY that identifies the live or server-side broadcast stream, and one or more EVENT elements that define the content for the ad breaks.
The following metafile script plays an example broadcast unicast stream, FootballGame, and defines two events: AdBreak1 and AdBreak2. Each event contains two entries, each containing an ad:
<ASX VERSION="3.0">
<ENTRY>
<REF HREF="mms://WindowsMediaServer/FootballGame" />
</ENTRY>
<EVENT NAME="AdBreak1" WHENDONE="RESUME">
<ENTRY CLIENTSKIP="NO">
<REF HREF="mms://WindowsMediaServer/Ad1.wmv" />
</ENTRY>
<ENTRY CLIENTSKIP="NO">
<REF HREF="mms://WindowsMediaServer/Ad2.wmv" />
</ENTRY>
</EVENT>
<EVENT NAME="AdBreak2" WHENDONE="RESUME">
<ENTRY CLIENTSKIP="NO">
<REF HREF="mms://WindowsMediaServer/Ad3.wmv" />
</ENTRY>
<ENTRY CLIENTSKIP="NO">
<REF HREF="http://AdServer/Ad4.asp" />
</ENTRY>
</EVENT>
</ASX>
The CLIENTSKIP attribute is set to NO to prevent the streamed ad from being skipped. The streamed ads must be played before returning to the original broadcast stream. The WHENDONE="RESUME" attribute defines the behavior of the Player following the last item in a break. In this case, RESUME returns the Player to the main feed, FootballGame.
Note that the second ad position in AdBreak2 calls for an active server page (ASP). This ASP page returns a scripted playlist with dynamic entries that provide dynamic on-demand programming. The use of ASP pages in metafiles enables you to integrate ad servers, for example, to return personalized ads based on a user profile or other parameters. In the first break, the football game producers used their ads to cover national ads. With Ad4.asp in the second break, a Windows Media file is returned based on some user parameter, such as automobile preference. In this way, you can use ASP pages with dynamic entries to create dynamic on-demand programming.
You can also use the metafile to display customized graphics, audio, and text for advertising. You can use the BANNER element as a child element of an EVENT to display an advertising message graphic. As shown in the following example, the BANNER element provides the path and file containing the graphics for your advertising banner. You can also provide a link to a site or file using the MOREINFO child element. The URL in the MOREINFO element can provide a link to even more advertisements on the Web.
<BANNER HREF="SomePath\2.gif">
<ABSTRACT>Read This Ad and Buy.</ABSTRACT>
<MOREINFO HREF="http://www.proseware.com" />
</BANNER>
For more information about creating client-side playlists, see the Windows Media Player 9 Series Software Development Kit (SDK).
Creating a Server-Side Playlist to Define Broadcast Ads
To create a server-side playlist, write your script in a text editor such as Notepad. A server-side playlist script is based on the Synchronized Multimedia Integration Language (SMIL) 2.0 syntax, and is made up of elements and their associated tags and attributes. Each element or attribute in the script defines a particular setting or behavior in the server, which is Windows Media Services.
The playlist elements are fairly simple. The first two lines of code define the file as a SMIL-compliant server-side playlist (.wsx), and notify Windows Media Services about the version of the WSX file format that you're using. Then, media src elements define your broadcast content.
In the following example, the publishing point source is a playlist that references a broadcast stream from an encoder session. When the encoder sends a script command to the server to initiate the event PlayEvent in the playlist, the media source Ad01.wmv specifies the ad to play. When the ad finishes, the broadcast playlist resumes playback of the live encoder stream.
<?wsx version="1.0" encoding="utf-8"?>
<smil>
<excl>
<priorityClass peers="pause">
<media src="http://encoder:8080" begin="0s"/>
<media src="C:\Ads\Ad01.wmv" begin="PlayEvent.begin"/>
</priorityClass>
</excl>
</smil>
If you want the playlist to resume playback after the on-demand file is finished playing, you must include a priorityClass element with a peers attribute value of pause. This element controls how one media element interrupts the playback of another element and the playback state of the interrupted media element.
For more information about creating server-side playlists, see the Windows Media Services 9 Series SDK.
Inserting Event Script Commands in the Broadcast Stream
In Windows Media Encoder, you can use the Script panel to insert event script commands into a stream while you are encoding a live program, and then broadcast the stream from a Windows Media server. This feature enables you to insert the commands that initiate the ads within your broadcast. Note that the code for the specified events must be defined in the playlist for the stream in order for the Player to perform the specified events.
To insert script commands into an encoding session, you need to select scripts as a source type when setting up your session. You cannot include scripts when you set up a session using the New Session Wizard, but you can add scripts to the session through the Sources tab of the Properties panel. Because script commands are saved in the stream, they are not available for you to edit at a later time.
To insert script commands while encoding
- On the Encoder toolbar, click Properties, and then click the Sources tab.
- In Source from, click Devices.
-or-
To insert script commands while sourcing from a file, click Both device and file.
- Select the Script check box, and then click Script Panel.
Figure 4. Windows Media Encoder Script panel
- Click Apply, and then click Start Encoding.
- On the Script panel under Script, click the Custom script command button.
- Type the script command type and value.
- For client-side playlists:
Approximately 15 to 20 seconds before you want the advertisement to play, type OPENEVENT in the type box, type the name of the next event (break) in the parameter textbox, and click Insert. Then, at the point when you want the switch to occur, type EVENT in the type box, and click Insert.
The OPENEVENT enables the player to prebuffer the content so that when the specified event occurs, the switch between streams appears to be seamless. Windows Media Player begins buffering the break when it receives the OPENEVENT, and cuts away to the first ad in the break when it receives the EVENT command.
- For server-side playlists:
When you want the advertisement to play, type FIRE_EVENT in the type box, type the name of the next event (break) in the parameter textbox, and then click Insert.
When Windows Media Services receives the FIRE_EVENT command, it begins streaming the first ad in the break.
Figure 5. Inserting an OPENEVENT command in a Windows Media Encoder broadcast
For more information about setting up Windows Media Encoder for a broadcast encoding session, see Windows Media Encoder Help.
If you want to implement an automated solution, you can create an encoder application with the Windows Media Encoder SDK. A programming environment such as Microsoft Visual Basic® can be used to create a program that controls an instance of Windows Media Encoder. The program can make use of an input port of a computer, such as the serial port or joystick port, to trigger script commands based on switch contact closures. The port can then be connected to an external automation device that detects the presence of cue tones, the signals in the vertical interval of the video, or the timing cues from an automation system. For more information about creating an encoder application, see the Windows Media Encoder SDK.
Back to the top
For More Information
Back to the top
|
