previous next

Chapter 8: Multicasts

Multicasting is an alternative to unicasting that reduces the number of broadcast streams in use. Although it can increase the audience for a live event by reducing the broadcasting bandwidth, it requires a specially configured network, and is more suited for intranets than Internet delivery. You can multicast RealMedia, QuickTime, Windows Media, MPEG, and a number of RTP-based formats.

Understanding Multicasts

As Chapter 7 explained, unicasting delivers a unique broadcast stream to each media player. In contrast, multicasting sends a single live stream to multiple players. The multicast can be a live event, or a prerecorded clip broadcast by SLTA, which Chapter 10 explains. The players connect to the stream, rather than to the Helix Universal Server, as shown in the following illustration.

Multicasting

Multicasting

Back-Channel Multicasting

Back-channel multicasting works with all RealNetworks media players, including older players that use only the PNA protocol. In this method of multicasting, each media player maintains a control channel to Helix Universal Server. A media player uses its channel to send commands such as Stop, and to deliver statistics about the quality of service to the archive log. The channel lets Helix Universal Server receive a user name and password if authentication is used. It also enables the Server Monitor described in Chapter 18 to track how many players are viewing the multicast.

Back-Channel Multicasting

Back-Channel Multicasting

Note: Because each player uses a control channel, back-channel multicasting is limited to the number of client connections licensed to your Helix Universal Server.

Unicast Failovers

If a RealNetworks media player is not multicast-enabled, or cannot connect to the back-channel multicast, it fails over to a unicast automatically. This ensures that all players can receive the broadcast. Because each unicast stream consumes extra bandwidth and Helix Universal Server overhead, you can choose to disable the failover feature and provide just the multicast. In this case, a player not able to participate in a multicast receives an error message when attempting to connect to the broadcast.

Tip: You can use back-channel multicasting with the failover feature for all broadcasts to RealNetworks media players. By default, players attempt a back-channel multicast connection first, switching to unicast if the failover feature is enabled, and the multicast is not available. Hence, enabling an automatic multicast for all broadcasts can help conserve bandwidth.

Scalable Multicasting

Using a scalable multicast, you can broadcast to an unlimited number of media players because the transmission is one-way. Unlike back-channel multicasting, scalable multicasting does not use a control channel. Thus, it uses less bandwidth, administrative overhead, and system resources on Helix Universal Server. Scalable multicasting works with RealPlayer G2 and later. You can also multicast to any RTP-based media player that complies with scalable multicasting standards, including Apple's QuickTime Player.

Scalable Multicasting

Scalable Multicasting

Session Description Files

Viewers connect to scalable multicasts by clicking a link to a Session Description Protocol (SDP) file, which Helix Universal Server automatically generates. All data is multicast on the network once, and media players do not connect to Helix Universal Server during the multicast. Because of this, tools such as Server Monitor do not track client connections and activity during the broadcast.

Authentication and Statistics

Because media players do not connect to Helix Universal Server directly during the multicast, you cannot enforce user name and password validation in a scalable multicast. Optionally, you can have players connect to Helix Universal Server or a Web server to deliver quality of service statistics when the broadcast ends (or they disconnect).

Unicast Failovers

Like back-channel multicasting, scalable multicasting has a failover feature that lets you direct RealNetworks media players to a unicast if they cannot receive the multicast. You can provide a unicast on the same Helix Universal Server that hosts the multicast, or choose a different Helix Universal Server. As well, you can direct players to a Web page that indicates that the multicast is not available, and provides information about broadcast alternatives.

Windows Media Multicasts

Helix Universal Server can deliver scalable multicasts in the Windows Media format to Windows Media Players. Each multicast is pulled from Windows Media Encoder, and made available to players on a single multicast channel. Players click a Web page link to an NSC file to join the multicast. You can designate a unicast URL for players that cannot join the multicast. Unlike with RealMedia back-channel multicasts, Helix Universal Server cannot make all Windows Media unicasts automatically available as multicasts. As well, archiving of Windows Media multicasts is not supported.

Network Configuration for Multicasts

To use multicasting, Helix Universal Server, media players, routers, switches, and all other networking devices between them must be multicast-enabled. For this reason, multicasting is primary used on intranets. However, it is possible to deliver multicasts over the Internet where intermediary network devices have been multicast-enabled. Before using multicasting, verify the following with your network administrator:

Multicast Addresses

A multicast requires the use of a continuous range of multicast addresses on your network. Valid ranges are between 224.0.0.0 and 239.255.255.255. Check with your network administrator about which multicast addresses are available on your network. On the public Internet, certain ranges in the multicast address space (from 224.0.0.0 to 224.0.0.255) are reserved, and cannot be used.

The number of addresses required for a multicast depends on the type of multicast you use, as well as the number of streams you deliver. For scalable multicasting, you also need to reserve a number of Helix Universal Server ports for the broadcast. The sections on setting up each type of multicast explain the number of addresses and ports you need.

Warning! If you use multiple types of multicasts, such as both back-channel and scalable multicasts, the address ranges you pick cannot overlap.

Packet Time to Live

All multicast broadcasts include a "time to live" feature. As a multicast data packet passes through a multicast-enabled router, its time to live decreases by 1. When the value reaches 0, the router discards the data packet. When you set up a multicast, you specify a time to live of 0 to 255. The larger the value, the greater the distance a packet can travel. The default value of 16 typically keeps multicast packets within an internal network. The following table summarizes possible values.

Time to Live (TTL) Values
TTL Value Packet Range
0 local host
1 local network (subnet)
16 intranet
32 site
64 region
128 continent
255 world

Multicasts with Multiple Network Interface Cards

If your Helix Universal Server machine has multiple network interface cards (NICs), and you want to ensure that Helix Universal Server always uses a particular NIC for multicasts, use your operating system to set a default address. On Windows, set IP bindings as described in "Binding to an IP Address". On UNIX, use the route command to associate the multicast route with the appropriate NIC.

Multicasting Used with Other Features

The following sections summarize how multicasting works with other Helix Universal Server features.

Splitting and Multicasting

Transmitters can multicast a stream to receivers, as explained in Chapter 9. This does not require the setup described in this chapter, which concerns only server-to-player multicasts. If the receiver multicasts a stream to media players, however, you must configure the receiver for multicasting as described in this chapter.

Live Archiving and Multicasting

As with all live broadcasts, you can configure Helix Universal Server to archive files for live multicasts in the RealMedia or MP3 format. Helix Universal Server does not archive MPEG-4 or Windows Media multicasts.

Simulated Live Broadcasts with Multicasting

You can multicast a simulated live stream from on-demand clips using SLTA, which Chapter 10 describes.

Helix Universal Proxy and Multicasting

Depending on how the network is configured and the streams are listed in Helix Universal Server, clients whose requests are forwarded by a Helix Universal Proxy may receive different results.

Helix Universal Proxy cannot join a multicast. Instead, it will try to receive the multicast using pull splitting. If pull splitting is enabled on the source Helix Universal Server, Helix Universal Proxy will use that broadcast, instead of connecting to the multicast. The client will receive the broadcast in unicast mode.

If there is a multicast-enabled network between Helix Universal Proxy and the client, Helix Universal Proxy can be configured to re-send its pull split stream by multicast instead.

For More Information: Refer to Helix Universal Proxy Administration Guide for information on configuring Helix Universal Proxy.

Firewalls and Multicasting

Multicasts usually take place within an intranet, where broadcasts are not traveling outside a firewall. If a multicast passes through a firewall, the firewall must be specially configured to allow multicast traffic.

Access Control, Authentication, and Multicasting

As with all delivery methods, Helix Universal Server verifies that the client requesting a broadcast is allowed to receive it. If you include the authentication mount point (/secure/) in the link, Helix Universal Server verifies the viewer's identity. You cannot authenticate scalable multicasts, however.

Reporting and Multicasting

Streams served through back-channel multicasts appear in the access log just like unicast material. The access log shows which method was used to transmit the stream. Scalable multicasts can be identified in the access log by their mount point in the GET statement. If Helix Universal Server is configured for requesting client statistics (see "Gathering Client Statistics"), the log file will also contain statistics for each client.

Multicast Resources

The Helix Universal Server implementation of back-channel and scalable multicasting is based on open industry standards. You may find the following resources useful.

General Multicasting Information

Scalable Multicasting Information

Defining Back-Channel Multicasting

Back-channel multicasting is enabled by default, though you need to specify multicast addresses for it to work. You can use this method to multicast any media format that RealNetworks media players can play. Once you've set up multicasting, players attempt to connect in multicast mode first, using a unicast if the cannot connect to the multicast. This helps to save bandwidth by providing the most efficient possible connection for each player.

Calculating Address Requirements

Determining the number of addresses you need for a back-channel multicast is straightforward. You need just one address per bit rate, regardless of the number of streams. So although a single-rate video technically delivers two streams, one for the audio track and one for the visuals, both tracks can use the same address.

SureStream Broadcasts

For SureStream, you need to reserve one address for each bit rate encoded into the stream. If a SureStream stream is encoded for three audience bandwidth targets, for example, you need three addresses. The duress streams encoded for a particular bandwidth target are not used, and do not require additional addresses.

Note: Media players cannot shift between SureStream streams during the multicast.

Automatic Multicasts

If you intend to leave back-channel multicasting on for all broadcasts, you need enough multicast addresses to accommodate your typical broadcast. It's a good idea to implement a policy, such as using only two bandwidth targets when broadcasting RealVideo. If you have not reserved enough addresses for a particular multicast, the event is unicast automatically, as long as you have not disabled the failover feature.

Configuring Back-Channel Multicasting

The following procedure describes how to set up Helix Universal Server for back-channel multicasting. Minimally, you need to define your multicast address range. Other features are optional.

To set up back-channel multicasting:

  1. In Helix Administrator, click Broadcast Distribution> Back-Channel Multicasting.
  2. The Enable Multicast list turns on this feature. Ensure that the default value of Yes is selected. If you set this to No, multicasting is disabled, and all media players use unicasting for all broadcasts.
  3. Set the Enable SAP list to Yes to announce the multicast session, as described in "Publicizing Your Multicasts".
  4. In the PNA Port box, enter the port number on media clients where Helix Universal Server directs PNA multicast streams. The default is 7070. PNA is used only with media clients earlier than RealPlayer G2, such as RealPlayer 5. These clients cannot play SureStream or SMIL.
  5. In the RTSP Port box, list the port number on media clients where Helix Universal Server directs RTSP multicast streams. The default is 3554.
  6. Specify the range of addresses to which you want to multicast streams by filling in the IP Address Range box. Helix Universal Server uses the first available addresses in this range. See "Calculating Address Requirements" for information about the number of addresses you'll need.
  7. Indicate how far multicast packets can travel over a network by typing a value in the Time to Live box. For more information, see "Packet Time to Live".
  8. To allow missing packets to be resent to clients that request them, select True from the Resend list. Resending packets adds network overhead, but delivers higher-quality multicasts.
  9. If you want to deliver the broadcast through multicasting alone, choose Yes from the Multicast Delivery Only list. Media players that cannot use multicasting will not be able to connect to the broadcast. Use this feature when broadcasting only to multicast-enabled media players, or if you are multicasting a high-bandwidth presentation and do not want to provide a unicast option.
  10. Warning! Selecting this option prevents you from unicasting any broadcast to RealNetworks media players. If you want to reuse unicasting after your multicast, turn this option off when the multicast ends.

  11. The Access Rules section lets you restrict the range of media players that can connect to the multicast. A predefined rule allows all multicast-enabled players with access to the broadcast URL to connect to the multicast. You can delete this rule, modify it, and set up other rules as necessary:
    1. To add a new rule, click the "+" icon and, optionally, change the default name in the Edit Client Access Rule Description box. Because the access rules simply list addresses of media players that have access, the order of the rules in the Access Rules box does not matter.
    2. For the highlighted rule, enter an IP address or domain name for acceptable players in the Client IP Address or Hostname. The value Any is predefined for the first rule, meaning that all IP addresses are accepted. To restrict the range, delete the rule, or change its value and set a netmask.
    3. In Client Netmask, specify the range of client IP addresses around the one you entered in the preceding step by selecting a bit mask. If Client IP Address is set to Any, though, leave Client Netmask set to None. See Appendix B for details about assigning a range of IP addresses using a bit mask.

  12. Click Apply.
  13. Tip: General access control rules, which are described in Chapter 12, are enforced before multicast access rules. A media player excluded by general access control will not connect to any multicast, regardless of the multicast access rules.

Starting a Back-Channel Multicast

After you configure a back-channel multicast, you start a unicast as described in Chapter 7. Media players that can connect to the multicast do so. Players that cannot connect to the multicast use a unicast, as long as the failover feature is not disabled. Links to both RTSP and PNA multicast are identical to links for unicasts. This enables a single link to serve both multicast and unicast clients. For information on linking formats, see "Linking to Unicasts".

Setting Up Scalable Multicasting

This section describes how to set up a live channel to broadcast to any number of media players that support the RTP packet format and the scalable multicasting standards. This includes RealOne Player and Apple QuickTime Player. You can multicast any audio or video format that plays in the media players used by your audience.

For More Information: The section "Multicast Resources" directs you to information about multicasting standards.

Determining the Number of Addresses and Ports

You must reserve a contiguous block of IP addresses and a continuous range of Helix Universal Server ports for a scalable multicast. The number of addresses and ports you need is based on the number of streams you broadcast. The following sections describe how to calculate the numbers of addresses and ports you'll need.

Note: The multicast addresses you choose cannot overlap with addresses assigned to back-channel multicasts.

Single-Rate Audio and Video

A single-rate audio broadcast uses one stream, requiring one address. A single- rate video contains at least two streams, one for the audio track and one for the visual track. It may also have an event stream used to open URLs, for instance. The scalable multicasting specification requires an address for each stream. However, Helix Universal Server has a default Reuse Address feature that lets you use just one multicast IP address for each single-rate video, whether or not it includes an event stream. RealNetworks recommends that you use this feature unless you have a specific reason not to do so.

Note: The Reuse Address feature works only with RealNetworks media players.

Tip: Using multiple addresses is useful if media players use a low-bandwidth connection, and are able to play just the audio track of a video stream.

SureStream RealAudio and RealVideo

For SureStream, you need to reserve one address for each encoded bit rate. If a SureStream RealAudio broadcast is encoded for three bandwidth targets, for example, you need three addresses. If you broadcast RealVideo and are not using the Reuse Address feature, you need two addresses for each rate. If a SureStream RealVideo broadcast is encoded for three audience bandwidth targets, for example, you need three addresses if the Reuse Address feature is used, six addresses if it isn't. The duress streams encoded for a particular bandwidth target are not used, and do not require additional addresses.

Note: Media players cannot shift between SureStream streams during a multicast.

Port Ranges

Scalable multicasts require a continuous, even-numbered range of ports. The number of ports required depends on the media type, and the number of bit rates encoded in the stream. You need to reserve two ports for each data stream:

Gathering Client Statistics

RealNetworks media players can transmit statistics about the amount and quality of data they received during a scalable multicast. As with unicasts, client statistics are sent at the end of a presentation (or when the player disconnects), and are stored in the access log described in Chapter 16. Once you have gathered statistics, you can draw conclusions about the quantity of clients and quality of service.

Because scalable multicasts can serve many thousands of players, your Helix Universal Server may not be able to handle all of the statistics connections at the end of the session, either because of load or client licensing limitations. In this case, you can limit the amount of information sent to Helix Universal Server (though not the number of connections), or offload the task to a Web server.

Limiting Statistics

Under Logging & Monitoring>Access & Error Logging, you can control the type of data sent at the end of a scalable multicast by modifying the Client Stats setting. You can instruct clients to send minimal data by setting Logging Style to 0 and by clearing any Client Stats settings. The section "Logging Style" shows the data recorded with this logging style. Although it records minimal data, Helix Universal Server still accepts connections from all players, up to its licensed maximum.

Note: If you change the access logging style, the setting applies to all content served through any method.

Offloading Statistics to a Web Server

When players connect to a scalable multicast, Helix Universal Server can instruct them to send their connection statistics to a Web server at the end of the session. Web servers are often configured for load balancing, and may be better equipped than Helix Universal Server to handle large numbers of simultaneous connections that have short durations.

To use a Web server, you will need to write a CGI script that receives the statistics and to writes them to a log file. The statistics sent to the Web server are a subset of those normally recorded in the Helix Universal Server access log. They are transmitted through HTTP POST, and they use the following format, in which the # symbol is a separator:

[Stat1:statistics_1][Stat2:statistics_2]#sent_time

For More Information: See "Client Statistics" for details about client statistics 1 and 2.

Setting Up a Live Channel

The following procedure explains how to set up a live channel for delivering a scalable multicast to RealNetworks media players. You might set up just one live channel for all scalable multicasts. Alternatively, you can create different live channels to multicast broadcast streams in different ways. To run two multicasts at the same time, for example, you define two separate channels.

To create a live channel:

  1. In Helix Administrator, click Broadcast Distribution>Scalable Multicasting.
  2. The Mount Point box lists the mount point used for all scalable multicasts. The default mount point is /scalable/. RealNetworks recommends that you use this default value, but you may change it if you wish.
  3. To create a new live channel, click the "+" icon and enter a descriptive name for this multicast session in the Edit Channel Description box.
  4. Turn on scalable multicasting for this channel by selecting Yes from the Enable Channel list.
  5. Set the Enable SAP list to Yes to announce the multicast session, as described in "Publicizing Your Multicasts".
  6. In the Path box, identify the stream name the live broadcast uses. To accept all broadcast streams, keep the default value of an asterisk (*). Otherwise, specify a stream name, such as live.rm, and include any virtual path used by the encoder, as in news/live.rm. You do not need to include the encoder's unicast mount point, such as /broadcast/ or /encoder/.
  7. You next specify the ports and addresses used by the scalable multicast. Refer to "Determining the Number of Addresses and Ports" for more information on these topics.
    1. In the Port Range boxes, type the port range where clients listen for streams.
    2. In the IP Address Range boxes, type the range of addresses to use. Helix Universal Server uses the first available address in this range. To use a single address instead of a range, type the same address in each box.
    3. Tip: You can use the same range of ports and addresses for multiple channels. If you plan to multicast on multiple channels at the same time, however, ensure that your ranges are broad enough to cover all of the simultaneous multicasts. Although two channels can share the same range of addresses, for example, they cannot both broadcast on the same address simultaneously.

  8. Indicate how far multicast packets can travel on your network in the Time to Live box. For information on these values, see "Packet Time to Live".
  9. Type a value for Timeout. This represents the number of seconds a client waits for multicast packets before it stops, or uses the value in Alternate URL.
  10. From the Reuse Address list, select False if you want to use a separate address for each stream in a video. Select True if you want to use one address for both streams. Refer to "Determining the Number of Addresses and Ports" for more information.
  11. Note: The Reuse Address feature works only with RealNetworks media players.

  12. You next decide whether to shift media players that cannot receive the multicast to a unicast. This feature works only with RealNetworks media players.
    1. From the Shift to Unicast list, select No if you do not want to shift clients to unicasting. You may want to choose this when broadcasting a high bit rate presentation in which a lot of unicast streams would consume too much bandwidth. If you choose No, you can ignore the next box.
    2. To make the backup unicast available on the same Helix Universal Server, leave the Alternate Unicast URL box blank. If you want to shift unicasts to a different Helix Universal Server, supply that server's address and the path to the broadcast. Here is an example:
    3. rtsp://helixserver.example2.com/broadcast/vivaldi.rm
      

      If you do not want to redirect players to an alternate stream, you can point them to a Web page that posts a message, such as, "This presentation is available only to multicast-enabled RealOne Players." In the Alternate Unicast URL box, enter the fully qualified URL of your Web page, such as the following:

      http://www.example.com/no_multicast.html
      

  13. The next set of options controls whether client statistics are logged on Helix Universal Server, on a Web server, or not at all. For background on this feature, see "Gathering Client Statistics". Only RealNetworks clients report statistics, so you can set this to No if multicasting to other RTP-based media players.
    1. In the Send Client Statistics to Web Server box, select Yes to have clients send their connection statistics to a Web server at the end of the multicast. Select No to send connection statistics to Helix Universal Server. If you select No, you can ignore the following settings.
    2. In the Web Server Address or IP Address box, type the address of the Web server that collects the statistics.
    3. In the Web Server Port box, type the HTTP port number of the Web server.
    4. In the Web Server CGI Path box, type the path of the CGI script that consolidates the client statistics into a log file on the Web server. For example, enter:
    5. cgi-bin/client-stats/logstat
      

  14. Click Apply.

Delivering the Scalable Multicast

Once you've configured the multicast, you launch your broadcast as described in Chapter 7. If you leave scalable multicasting turned on, and configure your multicast to cover all broadcasts by entering "*" as the path, the multicast will be available for all unicasts intended for RealNetworks media players. Unlike back-channel multicasts, however, scalable multicasts use a different URL format than unicasts. This means that the scalable multicast is available only if you provide the proper multicast link.

Tip: If you've enabled the Shift to Unicast feature, you can publish just the multicast URL for all broadcasts. Players that can connect through multicasting will do so. Players that cannot use multicasting will use unicasting.

Multicast SDP Files

When Helix Universal Server receives a scalable multicast request, it automatically creates an SDP (Session Description Protocol) file, which is a standard format that contains information such as the multicast addresses and ports, as well as the broadcast stream's title, author, and copyright information.

The media player receives the SDP file when the viewer clicks the multicast link in a Web page, and connects to the multicast using the file's information. A viewer can also download the SDP file, typically by right-clicking on the Web page link, then connect to the multicast later by opening the file directly in the media player.

Linking to a Scalable Multicast

Scalable multicast links differ from unicast links. They use the same format whether they appear in a Web page or in a metafile, and they always specify the HTTP protocol. The requested stream always ends with the .sdp extension. The following illustrates the link format:

http://address:port/mount_point/path/file.rm.sdp

Here is an example in which Helix Universal Server uses its default port 80 for HTTP, so the port number is not listed:

http://helixserver.example.com/scalable/news/live.rm.sdp

Multicasting Windows Media

As with all Windows Media broadcasts, a Windows Media multicast is pulled from a Windows Media encoder the first time a Windows Media Player requests the multicast. You need only one IP address and port for each multicast. This style of multicasting builds on the basic unicasting definitions you set up according to instructions in "Broadcasting Windows Media".

Defining a Multicast Channel

To set up Windows Media multicasts, you first define one or more multicast channels. A multicast can go out on a channel as long as the channel is enabled.

To create a Windows Media multicast channel:

  1. In Helix Administrator, click Broadcast Distribution>Windows Media Multicasting.
  2. The NSCFilePath box lists the path to the NSC file, which Windows Media Players use to connect to multicasts. The default path is the nscfile directory under the Content directory, but you can change this to another directory that holds on-demand content. Helix Universal Server automatically generates the NSC file in the specified directory, using the channel name as the file name and .nsc as the extension.
  3. Note: If you use a different directory for the NSC file, add that path to the HTTP delivery list, as described in "Allowing HTTP Delivery".

  4. To create a new live channel, click the "+" icon in the Channels section and enter a descriptive name for this multicast session in the Channel Name box. Because the channel name becomes the NSC file name, RealNetworks recommends that you do not include spaces or special characters in the name.
  5. Enable multicasting for this channel by selecting Yes from the Enable Broadcast list. After the multicast, you can disable the channel by resetting this list to the default value No.
  6. Tip: Because Windows Media multicasts are pulled on request, and viewers can save the NSC file locally, it's a good idea to disable a channel when you do not intend to use it.

  7. In the Multicast Address box, type the class D multicast address to use. You need only one address for each multicast. Each channel must use a different address.
  8. In the Port Range boxes, type the port where clients should listen for streams on this channel. Each channel must use a different port.
  9. Indicate how far multicast packets can travel on your network in the Time to Live box. For information on these values, see "Packet Time to Live".
  10. In the Stream Description box, you can type any text that describes this multicast stream. This is for your reference, and is not used in the multicast.
  11. To make a backup unicast available for media players that cannot join the multicast, supply the address and path to the unicast in the Alternate Unicast URL box. Although the unicast can be on the same Helix Universal Server, you need to define the address explicitly for the unicast failover to work. Here is an example:
  12. mms://helixserver.example.com/wmtencoder/chopin.wma
    

  13. For Client Statistics URL, supply an HTTP address or host name for the Microsoft Internet Information Server (IIS) that gathers client statistics at the end of the multicast. If you leave this field blank, media players do not send back any statistics. Players cannot send statistics to Helix Universal Server.
  14. For More Information: Refer to the Windows Media Services documentation on reporting multicast statistics for instructions about setting up IIS to gather statistics.

  15. Proceed to the next section if you want to define the live sources that use this multicast channel. You can click Apply to save the channel definition, however, if you want to set up its channel sources later.

Setting Up a Live Source

Each channel can multicast a live stream from any number of Windows Media encoders. However, it can multicast a stream from just one of its live sources at a time. Below a channel definition, you set up the live sources that each channel can use. Each channel maintains a separate list of sources.

To set up a live source for a channel:

  1. In Helix Administrator, click Broadcast Distribution>Windows Media Multicasting.
  2. In the Channels box at the top of the page, highlight the channel for which you want to create a live source.
  3. Scroll to the bottom of the page and click the "+" icon in the Channel Sources section to set up a new live source.
  4. Enter a descriptive name for this source in the Channel Source Name box. This name is for your reference only, and is not used in the multicast.
  5. For Stream Format File, enter the full path and file name of the ASF file (extension .asf) that Windows Media Encoder generates and is copied to Helix Universal Server when the encoding begins. This file is used only by Helix Universal Server, and is not delivered to media players.
  6. Tip: Because ASF is a streaming format, RealNetworks recommends that you do not place the format file in a directory used for on-demand streaming. This helps you to avoid mistaking the format file for a streaming clip.

  7. For Live Source, specify the mount point and stream name that identifies the live stream pulled from Windows Media Encoder. These elements are defined in the Windows Media unicast page, described in "Broadcasting Windows Media". The default mount point is /wmtencoder/, so a Live Source entry might look like this:
  8. /wmtencoder/live.wmv
    

    Warning! You must define a specific broadcast stream for each live source. Windows Media multicasting does not support the use of a wildcard character (such as "*") to pull all broadcasts that use the /wmtencoder/ mount point.

  9. Click Apply to save the live source definition.

Running the Windows Media Multicast

Once you've enabled the multicast and defined the live source, you are ready to begin the multicast. Start Windows Media encoder running, and deliver the ASF stream format file to the predefined location on Helix Universal Server. The broadcast starts with the first media player request.

Linking to the Multicast

Windows Media Players join the broadcast by requesting a download of the NSC file, which then instructs them on how to join the multicast. You can launch the broadcast through an HTTP link in a Web page, as shown in the following example. The /asxgen/ mount point normally required to launch Windows Media Player is not required:

http://helixserver.example.com/nscfile/live_channel.nsc

Tip: If you're using the unicast failover option, you can publish just the NSC file URL. Players that can connect through multicasting will do so. Players that cannot use multicasting will switch to the unicast URL.

Stopping a Windows Media Multicast

As a channel multicasts the stream, the channel name appears in the Transmitting Channels box at the top of the multicasting set-up page. To stop the broadcast, highlight the channel name, check the Stop Transmitting box, and click Apply. This changes the Enable Channel list to No to prevent the stream from being pulled again. To restart the channel, select Yes in the Enable Channel list and click Apply.

Publicizing Your Multicasts

Optionally, you can publicize back-channel and scalable multicasts to anyone running a program that listens for the Session Announcement Protocol (SAP). These applications, such as SDR and ICAST Guide, display a list of all multicasts currently playing. Helix Universal Server creates the SAP file automatically. Programs that listen for SAP announcements show the title, author, and copyright information encoded into the files you multicast.

Note: The Windows Media multicast format does not support Session Announcement Protocol.

To set up Helix Universal Server to create SAP files:

  1. In Helix Administrator, click Broadcast Distribution>Session Announcement.
  2. In the Host IP Address box, type the IP address of this Helix Universal Server. The SAP announcement will include this address.
  3. From the Enable SAP Service pull-down list, select Yes. This instructs Helix Universal Server to create and send SAP files. The default value is No.
  4. From the Listen to SAP list, ensure that the default value of Yes is selected. This option enables Helix Universal Server to collect in-use multicast addresses. Helix Universal Server consults this list when selecting a multicast address from the user-supplied address range, thus ensuring that it selects unique addresses that are not in use elsewhere on your network.
  5. Click Apply.


RealNetworks, Inc. © 2002 RealNetworks, Inc. All rights reserved.
For more information, visit RealNetworks
Click here if the Table of Contents frame is not visible at the left side of your screen.
previous next