Popular Searches:
Uploading, APIs, Creating Players, BEML
Brightcove players has built-in support for a variety of ad formats, from video ads to video pods to overlays. These ad formats have a page which describe their use in the built-in player templates; this article explains their support in custom templates. Custom player templates that are created in the Brightcove Studio Publishing module can use Brightcove advertising, and the options for advertising all depend on what is put in the custom player template. This article will explain in depth the different options available for these templates as well as the limitations.
To start off, we need to have a good understand of Brightcove's ad format system and how it currently relates to BEML, the language which is used to create custom player templates. Once we understand how the advertising system works with BEML, we can talk about how to use specific ad formats.
Below is a high level summary of what happens in the player as it relates to BEML. Don't worry if this doesn't all make sense, as we'll go through this summary in detail below.
Depending on what's located in the BEML for a player, the player sends "frmt" key/value parameters to the ad server. These "frmt" parameters are then used by the ad server to send back a valid ad XML for one of the given formats. The ad XML is processed by the player and converted into an ad. If the ad format for the ad is supported by the current BEML, then the ad is displayed.
Let's parse this summary sentence by sentence.
Depending on what's located in the BEML, the player sends "frmt" key/value parameters to the ad server.
The current way to think about formats is that different standard player templates support different format numbers. This is how we break out the information in our ad format page, as mentioned in the introduction.
This is a bit of a sleight of hand, however. There's nothing special about our standard player templates themselves as related to the format numbers. It's the specific BEML that's within the standard player templates which trigger different format numbers to be sent. So any player, standard or custom, which has the correct BEML within it can support a given format. There will be more on what specific BEML triggers different formats in later sections.
When the specific BEML is found that tells the player that a format is supported, this information is sent on to the ad translator which sends this information on to the ad server. In DART for Publishers (DFP) and in most systems, this is done as "frmt" URL parameters. It could be sent as something other than a "frmt" parameter, however, and it's up to the ad translator to decide on how to send on this information.
These "frmt" parameters are then used by the ad server to send back a valid ad XML for one of the given formats.
The ad server then decides, based on the "frmt" parameters and other information, what XML to send back. This is done in a way that's specific to each ad server, and it involves the magic of ad trafficking. But in short, the "frmt" parameters should be used to send back XML that matches one of the given formats.
The ad XML is processed by the player and converted into an ad. If the ad format for the ad is supported by the current BEML, then the ad is displayed.
The ad translator sends the XML on to the player, and the first element will tell the player the format number of the given ad XML. If this is a format number that the player supports, then the ad will be displayed. Again, the player supports a given format number based on the BEML, and the specifics of the BEML support will be explained soon.
Let's see the high level summary again. It should make a bit more sense this time:
Depending on what's located in the BEML for a player, the player sends "frmt" key/value parameters to the ad server. These "frmt" parameters are then used by the ad server to send back a valid ad XML for one of the given formats. The ad XML is processed by the player and converted into an ad. If the ad format for the ad is supported by the current BEML, then the ad is displayed.
In the explanation of the summary, we've mentioned a few times that specific BEML allows the player to support different ad formats. We'll now go through all the different ad formats and what BEML pieces are needed to have them supported.
The support for video ads and overlay is essentially automatic for custom players. It's automatic because the only requirement is that you have a VideoPlayer component within your BEML. And if you support video ads or overlay ads, you'll need to have a VideoPlayer.
All players support ad SWFs. It's the one format that doesn't depend on specific components being present in the BEML.
There's a large number of formats which contain a banner or expanding banner. Here are the ones we support in the Brightcove 3 player:
Video Pod 468x60
Banner 468x60
Video Pod 728x90
Banner 728x90
Banner 300x60
Video Pod 300x60
Overlay ads with companion 468x60 banners
Overlay ads with companion 728x90 banners
SynchedOverlay300x60
All of these formats have four pieces in them in different combinations and sizes: videos, overlays, banners, and expanding banners.
For formats that have a video or overlay, you are required to have a VideoPlayer component in the BEML, just like in the requirement for video and overlay ads.
For formats that have a banner, you must have a Banner or ExpandingBanner in the BEML of a specific size. For formats that have a expanding banner, you must have a ExpandingBanner of a specific size. The specific size of the Banner or ExpandingBanner must be the same as the size that's given in the format information. For Video Pod 468x60, for instance, the ExpandingBanner must have a width of 468 and height of 60. The width and height have to be exact: if it's 468 and 59, then the player wouldn't support this format by default.
There is a way to have a banner or expanding banner of a custom size by using the "bannerFormats" attribute. If you specify "bannerFormats" for ExpandingBanner or Banner, you can give a comma-deliminated list of formats that are supported.
As an example of this, let's say you wanted to support format 2, Video Pod 468x60, but your expanding banner is only 468x59. You'd put something like the following in your BEML:
<ExpandingBanner width="468" height="59" bannerFormats="2" />
This strategy can also be used to support banner formats of an arbitrary size. There's a bit of an oddity in this in that you have to pick a banner format which isn't normally meant for that size. So you'd use the bannerFormats as described above, and then make sure the ad trafficker and advertising knows about the different size. This will give the ad format number and ad XML an overloaded meaning, but it will allow unlimited customization of banner sizes.
While the current system does allow for ads in custom templates, there's some limitations to what can be done. As noted in Customizing Banner Formats, there's a limitation in banner formats of custom sizes which requires you to overload the meaning to one of our existing format numbers.
There's also no easy way to go beyond our current ad formats and to create new ones. For instance, you can't just add three Banners and traffic to these three banners, because there isn't an existing Brightcove format for three banners. It's possible to do something like this through the ad SWF format, but that's not a simple solution.
We're looking at ways to get rid of these limitations. If you have ideas on how you'd like to see this work, let us know in the forums.
We've discussed in depth how you can support advertising in your custom templates, and how the specific BEML in your template will drive the ad formats that are supported. If you need more information or have a problem with your custom templates, just let us know.