CHAPTER 10

Webcast Authoring

There are a number of ways of connecting your audience to your programming. The most important thing to consider when choosing a method is speed. People don’t want to fill out forms, enter passwords, or spend ten minutes searching your website for the live stream. The best approach is to get them to the live stream as quickly and painlessly as possible.

This chapter starts with a general discussion of things you should be thinking about regarding your web page design, and then segues into the actual syntax for the various methods you can use.

•    Authoring Considerations

•    Standalone

•    Players Embedded Players

Authoring Considerations

You have to consider two things when you’re authoring for your webcast. First, how is the webcast going to be featured on the website? Is there going to be a link on the homepage, and will that link take people to an intermediate page, or directly to the webcast?

Second, you have to decide whether you’re going to use an embedded player or offer a link that opens up a standalone player. Both methods have advantages and disadvantages. Of course, for redundancy purposes, you should offer both.

Regardless of which method(s) you use, you’ll be using a text editor to place the link to your stream in a file, either a small text file known as a metafile or inside of special tags in an HTML file.

HTML Considerations

You should always try to put a link to your webcast on your home page. Webcasts tend to attract large audiences, all arriving at the same time. The first place they’re going to go is your home page. This will place an abnormally large load on your web server. If your audience has to search through multiple pages to find the webcast, the load on the web server could be dangerously high.

This is bad for two reasons. First, the web server will slow down, making it even more frustrating for folks trying to find the webcast. Second, if the system load is too high, you run the risk of system failure. If your website fails, then no one will be able to get to your stream.

This is a good argument for keeping your website simple. It is not uncommon for people to simplify their websites if they’re expecting huge crowds. Some organizations have even been known to replace their home page with a temporary home page that has a link to the web cast, and a link to the regular website.

It may sound extreme, but it works. The last thing you want is 10,000 people trying to download a fancy animation on your home page when all the audience wants to do is click the “skip intra” button. They’re there for the webcast, not the animation. Furthermore, unless you’ve got programming that people are absolutely dying to see, it’s not a good idea to force them to register.

Embedded vs. Standalone Players

There are two basic ways to present your webcast. You can either embed a streaming media player in a web page, or you can use links that pop up standard streaming media players. Many companies prefer the embedded approach because the experience is more seamless, since the webcast is seen in the context of the website, which has been carefully crafted and constructed to extend a company’s brand.

 

Author’s Tip

However, there can be issues when using embedded players. For embedded players to work properly, the audience’s browsers and media players must be configured properly. Also, there are cross-platform issues, meaning that if you’re trying to cater to people on the Mac or Linux platform, you may have some trouble.

Things have gotten much better for embedded players over the past few years. Using the right code, you can reach well over 90% of the average Internet audience with an embedded player. If you’re working in a closed environment where you know exactly what software people are running, you should be able to make sure everyone can see your webcast.

The best approach in our experience is to offer an embedded player, with links to open up standalone players for folks who encounter problems with the embedded player. Using this approach you should be able to reach 100% of your audience.

Let’s start with links to standalone players, since they’re the simplest.

Standalone Players

Linking to standalone players has the advantage of being relatively foolproof. Provided people have the appropriate streaming media player installed, it will open up and start streaming the webcast.

However, you can’t link directly to the webcast in your HTML code. To understand why, remember that browsers use the hypertext transfer protocol (HTTP) to communicate with web servers. Links to streaming media use the real time streaming protocol (RTSP)—which browsers do not understand. If you try to use an RTSP link directly in your HTML code in an anchor tag, the browser will display an error. What we need is a method to hand off the URL of the webcast directly to the streaming media player. This is done using what is known as a metafile.

Metafiles are small text files that are placed on web servers. They use special file extensions such as .ram and .asx that are uniquely associated with streaming media players. Because they’re text files, they can easily be delivered via HTTP, which browsers understand.

When a browser receives a metafile, it hands off the file to the appropriate streaming media player. The streaming media player then opens the metafile, and extracts the URL to the stream. The process is illustrated in Figure 10-1.

1.    User clicks on link, issuing a request to web server.

2.    Web server returns a metafile.

3.    Browser identifies metafile as belonging to a streaming media player, and hands it off to a streaming media application.

4.    The player opens the metafile, extracts the URL, and issues a request to a streaming server.

5.    The streaming server sends the stream to the player.

Figure 10-1
Use metafiles when you want to open up a standalone player.

Metafiles are a pretty simple solution, and work in almost all cases. One problem that can arise, though, is that they can be cached. Web servers and large content distribution networks (CDNs) use caching to speed up delivery of their most popular files. During a webcast, caching systems register that the metafile is very popular, and will cache them. This is great provided your metafile doesn’t change, but if something goes wrong with your webcast and you are forced to change the URL of your webcast, the cached version will be out of date.

Also, chances are your webcast will use more than a single server. Therefore, you want spread your load across a number of different servers. Some distribution networks use hardware load balancing systems so an address like

rtsp://my.streamingserver.com/2005Conference

is redirected to a number of servers automatically, without having to specify individual server names. Other systems, however, require different links for different servers. In this case, you need to dynamically generate your metafiles.

Dynamically generating metafiles is pretty simple, and something that any system administrator can take care of. Essentially, you generate the metafile on-the-fly, taking server load into account so that your load is evenly distributed amongst a number of servers.

Simple dynamic metafile generators assign requests to servers randomly; others actually monitor load levels and CPU usage to determine the optimal server to send the request to. However it is done, load balancing is essential for a successful webcast, and needs to be addressed when authoring metafiles. Work closely with your system administrators, and you’ll be fine.

Metafile Examples

As mentioned previously, metafiles are very simple text files. Metafiles contain additional information about the file, most importantly the location, and information about how to play the file. The syntax varies from platform to platform, but the information they contain is basically the same.

Windows Media — Windows Media metafiles use an XML-based format, which means that tags are contained in angle brackets. It’s similar to HTML (which is an XML-based language), but uses different tags. Here’s a simple Windows Media metafile:

<asx version="3.0">

<entry>

<ref href="rtsp://your.wmserver.com/2005conference_live" />

</entry>

</asx>

Let’s go through this file line by line. The first line says that this is an .asx file, with the version number 3.0. The second line starts a new entry, which is a file and all the information that is associated with it. The third line is a reference tag that contains the URL of the actual stream. The fourth line closes the entry, and the final line closes the .asx file.

To use this code, simply type it into a text editor, substituting the correct URL in the <ref> tag, and save the file with an .asx file extension. Then place it on your web server, and link to the .asx file from the webcast web page. When the browser receives the .asx file, it will recognize it as belonging to the Windows Media Player, and hand it off accordingly.

 

Author’s Tip

One thing to notice with XML files is that there are unary and binary tags. Unary tags are self contained, and always have a trailing slash before the closing angle bracket, like the <ref> tag above. Binary tags come in pairs, with the second, or closing tag, taking a slash before the tag name, i.e., </entry>. This syntax is common to all XML based metafiles.

The other thing to notice is how the file is indented. Indenting the file is not required but makes it easier to read, and more importantly, to debug when problems arise. For example, you could have quite a bit more information in your metafile:

<asx version="3.0">

<entry>

<ref href="rtsp://your.wmserver.com/file1.wmv" />

<param name="title" value="Keynote Address" />

<param name="copyright" value="2005 MyCompany.com" />

</entry>

<entry>

<ref href="rtsp://your.wmserver.com/file2.wmv" />

<param name="title" value="Thank you for coming." />

<param name="copyright" value="2005 MyCompany.com" />

</entry>

</asx>

In this case, there are two entries, each with two extra parameters. The Windows Media Player plays entries in .asx files in order, just like a play list. In this example, the two entries have different titles. There are many other parameters that can be used inside .asx files. For a full list, please consult the Microsoft website at:

http://msdn.microsoft.com/library/en-us/wcewmt/html/_wcesdk_asx_asx_elements_reference.asp

RealMedia — RealMedia metafiles are plain text files, and take either the .ram or .rpm file extension. The ram file extension is used when you want the standalone RealPlayer to play the stream; the rpm file extension is used when you’re authoring for an embedded player. A RealMedia metafile contains the URL to the stream, for example:

rtsp://your.realserver.com/YourStream.rm

Just type it into a text editor, save it with the right file extension, and put it on your web server. RealMedia metafiles can also take additional parameters, using the following syntax:

rtsp://your.realserver.com/YourStream.rm?parameter=“value”&parameter=“value”

To add additional parameters, simply put a question mark after the URL, and then the name of the parameter, an equals sign, and the value in quotes. Additional parameters can be added by adding an ampersand and then the parameter and value pair. For example:

rtsp://your.realserver.com/YourStream.rm?title=“Conference 2005”&copyright=“2005”

There are a number of parameters that can be used in RealMedia metafiles. Some parameters are tied to the file, such as title and copyright. Others dictate how the player displays the file, (for example screensize=“full”), or what is displayed in the RealPlayer browser window. You can find more information about metafile parameters in the RealNetworks Production guide, available from the RealNetworks website:

http://www.realnetworks.com/resources/documentation/index.html

One last thing to note—.ram and .rpm files can have multiple entries, one entry per line. You can put comments in Real metafiles by placing a pound sign ("#") as the first character of a line. The RealPlayer plays through the files in order they’re listed.

QuickTime — QuickTime metafiles use the .qtl (QuickTime Link) file extension, and are also XML-based files. A QuickTime link file looks like this:

<?xml version="1.0">

<?quicktime type="application/x-quicktime-media-link"?>

<embed src="rtsp://your.qtserver.com/YourStream.mov" />

The first two lines let the QuickTime player know that this is a link to a streaming file. The third file contains the URL of the actual stream. This example links directly to a QuickTime file. However, QuickTime broadcasts are slightly different, in that you must link to the Session Description Protocol file, which is a small file that is automatically created by the QuickTime broadcasting application.

The .sdp file must be placed on the QuickTime streaming server. Then, in the .qtl file, leave off the file extension of the .sdp file. For example, assuming you started a live QuickTime stream, and the broadcaster application created an .sdp file named keynote.sdp, you would load the keynote.sdp file onto your QuickTime server, and then the contents of your .qtl file would look like this:

<?xml version="1.0">

<?quicktime type="application/x-quicktime-media-link"?>

<embed src="rtsp://your.qtserver.com/keynote" />

It’s a small difference, but it has to be done this way or it won’t work. QuickTime link files can also take a number of parameters, which are added to the embed tag, using the following syntax:

<embed src="rtsp://your.qtserver.com/keynote" autoplay="true" fullscreen="true" />

A full discussion of QuickTime link file parameters is available on the apple website:

http://developer.apple.com/documentation/QuickTime/QT4WebPage/samplechap/special-11.html

Redundancy in Metafiles

As mentioned previously, the default behavior for metafiles is to behave like play lists, where entries are played in order. This enables the thoughtful reader to add a bit of redundancy to a webcast by placing multiple entries into the metafile. For example, consider the following RealMedia metafile:

rtsp://your.realserver.com/live_l.rm

rtsp://your.realserver_2.com/live_2.rm

rtsp://your.realserver.com/live_l.rm

rtsp://your.realserver_2.com/live_2.rm

The RealPlayer will attempt to play the first stream, live 1.rm, and continue to play it until the file finishes. If the file is unavailable, the RealPlayer will then attempt to play the second, and so forth. So if there are problems with live 1.rm, the player will “switch” to the second stream, and play that until it is finished or there is a problem.

You can achieve the same behavior with Windows Media .asx files by placing multiple <ref> tags in each <entry>tag. Also, because older versions of the player do not support RTSP, you may want to specify an alternative protocol:

<asx version="3.0">

<entry>

<ref href="rtsp://Server1/Path/File1.asf"/>

<ref href="mms://Server2/Path/File1.asf"/>

</entry>

</asx>

In this case, the player will attempt to connect via RTSP to the first stream, but if the player cannot connect via RTSP it will then attempt to connect to the second stream via MMS, the legacy Microsoft streaming protocol. You could also place multiple <entry> tags, each with multiple references.

Embedded Players

There is something irresistible about embedding a player in a web page that looks and feels like the rest of a website. The problem is that embedding a player requires different code depending on the browser, the OS, and the player version. Use the right code, and you’ve got a nice looking presentation. Use the wrong code, and you stand a good chance of shutting out a substantial portion of your audience.

 

Author’s Tip

As with most things relating to streaming, things have gotten considerably better in the last few years. Support across browsers has improved, as has support across operating systems. It’s still not perfect, but using the techniques described in the following sections you should be able to embed a player that the majority of your audience will be able to see.

The Microsoft ActiveX Control

Internet Explorer uses what is know as an ActiveX control to embed functionality into web pages. ActiveX controls are immediately recognizable by their use of the <object> tag. The following code embeds a QuickTime player:

<object classid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B"

codebase="http://www.apple.com/qtactivex/qtplugin.cab"

width="160" height="136" >

<param name="src" value="rtsp://your.server.com/Conference2005.mov">

</object>

The first tag, the opening <object> tag, contains a few parameters:

•    classid: The classid parameter is a unique string that identifies the object to be embedded, in this case the QuickTime player.

•    codebase: The codebase parameter provides a URL for the user to link to if they do not have the required ActiveX control installed.

•    width, height: These parameters specify the size of the embedded object.

The <param> tag contains a name-value pair, which means it contains a pair of parameters, specifying the name of and the value of the variable. In this case, it specifies the URL of the stream. There are additional parameters that can be specified in name-value pairs, such as whether the file should play automatically, whether to show the control bar, and many others, depending on which player you’re embedding.

The only problem is that Netscape-based browsers don’t recognize the <object> or the <param> tags. To get compatibility across Netscape-based browsers, you need to use different code.

 

Author’s Tip

The Netscape Plug-In Model

Netscape-based browsers work similarly to Internet Explorer, but instead of an ActiveX control, they use what is known as a plug-in. Plug-ins use the <embed> tag:

<embed src="rtsp://your.server.com/2005Conference.mov" width="160" height="136"

pluginspage="http://www.apple.com/quicktime/download/">

</embed>

The code is similar to the ActiveX code, but with all parameters included in the single <embed> tag:

•    src: The src parameter specifies the URL of the stream

•    width, height: The width and height parameters specify the size of the plug-in.

•    pluginspage: The pluginspage parameter specifies the URL the viewer can go to if they do not have the required plug-in to view the webcast.

As with the ActiveX control, there are other parameters that can be included to specify various types of player behavior. The only difference is that they are included in <embed> tag as opposed to <param> tags.

Building Cross-Platform Web Pages with Embedded Players

Knowing what we do about embedding players in different browsers, how can we cater to both Internet Explorer and Netscape-based browsers? Thankfully, the answer is quite simple. We can cater to both by including the code for the Netscape Plug-in within the code for the ActiveX control. Take the following code for example:

<object classid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B"

codebase="http://www.apple.com/qtactivex/qtplugin.cab"

width="160" height="136" >

<param name="src" value="rtsp://your.server.com/2005Conference.mov">

<embed src="rtsp://your.server.com/2005Conference.mov" width="160" height="136"

pluginspage="http://www.apple.com/quicktime/download/">

</embed>

</object>

The code begins with the <object> tag and code as per a standard ActiveX control. Then, the <embed> tag is included within the <object> tag. When Internet Explorer parses this code, it ignores the <embed> tag. Similarly, Netscape-based browsers don’t recognize <object> or <param> tags, and ignore them.

Using this approach, you should be able to author pages with embedded players that the majority of your audience can see, provided they have the media player installed. The only time it gets tricky is with the Windows Media Player. There are a couple of reasons for this which are addressed next section.

Embedding the Windows Media Player

The Windows Media Player is embedded as a whole, just like the QuickTime player. The code looks pretty much the same:

<object classid="CLSID:6BF52A52-394A-11d3-B153-00C04F79FAA6"

width="240" height="244" >

<param name="url" value="media/wmv9.asx"/>

<embed type="application/x-mplayer2"

src="media/wmv9.asx" width="240" height="226">

</embed>

</object>

The <object> tag has the classid for the windows media player, and the standard width and height parameters, as well as a name-value pair specifying the URL of the file to be played. In this case, the URL is pointing to a metafile, with the standard .asx extension.

The <embed> tag, however, has a new addition: the type parameter. This must be included, and the value must be exactly as it is shown above. Other than that, the code is just as simple as the others. So why is embedding a Windows Media Player tricky? Well, there are a number of reasons:

•    Microsoft discontinued support for the Netscape plug-in with the Windows Media 7.0 Player

•    The 6.4 plug-in doesn’t work on some Netscape browsers (6.×, 7.0)

•    Internet Explorer on the Mac uses the Netscape plug-in, not the ActiveX control

However, just when all seemed lost, Windows Media resumed support for the Netscape plug-in with the Series 9 Player. Almost simultaneously, with version 7.1 Netscape began supporting the Windows Media Player ActiveX control. You can even download an extension for the open source Firefox browser to add Windows Media Player ActiveX support. So what’s the problem?

The problem is that you don’t know what browsers your audience will be using, or what version of the Windows Media Player they have installed. If they have Windows Media 9 or greater installed, chances are everything will be just fine, unless they’re using Internet Explorer on a Mac. To further complicate the issue, the Windows Media Series 9 Player is only available for OSX.

It can all be a bit daunting, if you’re trying to support every single possible permutation of browser, operating system, and player version. Using the code above, you stand a very good chance of reaching the majority of your audience. For those who have problems with the embedded player, offer a link to a metafile that opens up a standalone player, which hopefully will keep everyone happy.

Embedding the RealPlayer

The RealPlayer is embedded in pieces. Each piece of the RealPlayer you embed can be placed in a table, frame, or any valid HTML construct. In this example, we’ll embed the video pane and all the controls, including the playback controls, the metadata window, and the status bar:

<!- code for Image Window -->

<object classid="clsid:CFCDAA03-8BE4-11cf-B84B-0020AFBBCCFA"

width="240" height="180">

<param NAME="controls" VALUE="ImageWindow" />

<param NAME="console" VALUE="one" />

<embed src="2005Conference.rpm" width="240"

height="180" controls="ImageWindow" console="one" />

</object>

 

<!-- code for controls -->

<object classid="clsid:CFCDAA03-8BE4-11cf-B84B-0020AFBBCCFA"

width="375" height="100">

<param NAME="controls" VALUE="All"/>

<param NAME="console" VALUE="one"/>

<param NAME="src" VALUE="2005Conference.rpm"/>

<embed src="2005Conference.rpm" width="375"

height="100" controls="All" console="one" />

</object>

The first thing to note is that there are two separate blocks of code, each of which uses an <embed> tag within an <object> tag. The classid parameter is different, and is the string associated with the RealPlayer. Third, the code links to a metafile, but the metafile uses the rpm file extension. This is critical, because the Netscape plug-in uses file extension to determine what plug-in to use. The rpm file extension is registered to the RealPlayer plug-in.

There are two other parameters that are crucial to embedding the RealPlayer:

•    Controls: The controls parameter determines what part of the RealPlayer is being embedded.

•    Console: The console parameter is used to tie together all the different embedded pieces.

In the first block of code, the controls parameter is set to “ImageWindow.” This is the part of the RealPlayer that displays video. The second block has the controls parameter set to “All,” which embeds all the controls. Both chunks include the console parameter, which is set to “one.” It doesn’t matter what you set this parameter to, as long as it’s set the same for all the embedded pieces of the RealPlayer.

You can actually embed multiple RealPlayers in a web page, and separate controls, as long as you use unique console parameters for each embedded player. As for the controls, the RealPlayer allows you to embed each control individually, or in groups. For full documentation of the RealPlayer, please refer to the RealNetworks Production guide, available from the RealNetworks website:

http://www.realnetworks.com/resources/documentation/index.html

 

Conclusion

When people watch a webcast, they’re there for one thing: the webcast. So don’t make them navigate through your entire site to find the link. Ideally, put a link on your home page. It’s also a good idea to keep your site simple when you’re expecting a big crowd. Webcasts put a strain on your web servers as well as your streaming servers.

The simplest way to connect your audience to your programming is to link to a metafile. Metafiles allow the browser to hand off to a player, either standalone or embedded. If you’re going to use an embedded player, be sure to use both the <object> and the <embed> tags, so that both Internet Explorer and Netscape based browsers will be able to see your programming. It’s also important to put a link to a metafile in case people have problems with the embedded player.

Next up is distribution. The final piece of software in the puzzle is the streaming server, which is the subject of the next chapter.