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.
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.
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.
| 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. |
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. |
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.
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.
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).
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.
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.
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:
| Tip: RealNetworks and Microsoft media players are configured for multicast by default, although viewers can turn off multicast support in their player preferences. |
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. |
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.
| TTL Value | Packet Range |
|---|---|
0 |
local host |
1 |
local network (subnet) |
16 |
intranet |
32 |
site |
64 |
region |
128 |
continent |
255 |
world |
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.
The following sections summarize how multicasting works with other Helix Universal Server features.
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.
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.
You can multicast a simulated live stream from on-demand clips using SLTA, which Chapter 10 describes.
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. |
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.
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.
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.
The Helix Universal Server implementation of back-channel and scalable multicasting is based on open industry standards. You may find the following resources useful.
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.
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.
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. |
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.
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: |
Yes is selected. If you set this to No, multicasting is disabled, and all media players use unicasting for all broadcasts.Yes to announce the multicast session, as described in "Publicizing Your Multicasts".7070. PNA is used only with media clients earlier than RealPlayer G2, such as RealPlayer 5. These clients cannot play SureStream or SMIL.3554.True from the Resend list. Resending packets adds network overhead, but delivers higher-quality multicasts.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.| 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. |
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.Any, though, leave Client Netmask set to None. See Appendix B for details about assigning a range of IP addresses using a bit mask.| 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. |
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".
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. |
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. |
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. |
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. |
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:
| Tip: You can determine a clip or unicast stream's encoded bit rate (or rates) by playing the clip or live stream in RealOne Player, and giving the View>Clip>Clip Source command. |
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.
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. |
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: |
| For More Information: See "Client Statistics" for details about client statistics 1 and 2. |
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: |
scalable/. RealNetworks recommends that you use this default value, but you may change it if you wish.Yes from the Enable Channel list.Yes to announce the multicast session, as described in "Publicizing Your Multicasts".*). 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/.| 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. |
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.| Note: The Reuse Address feature works only with RealNetworks media players. |
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.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 |
No if multicasting to other RTP-based media players.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.
|
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. |
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.
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:// |
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 |
/scalable/, but you can change this as described in "Setting Up a Live Channel". The /ramgen/ parameter is not required, even though HTTP is used.news/ is optional. You include it only if the encoder specifies this path when it delivers the stream.live.rm. You then append an extra .sdp extension. Even though MPEG unicasts link to an SDP file, as in live_mp4.sdp, the multicast requires an extra .sdp extension in the request URL, as in live_mp4.sdp.sdp.| Tip: The SDP file contains exact channel settings. If you plan to repeat a multicast, and you want users to connect through a saved SDP file, use the same encoder settings, addresses, and ports as in the preceding multicast. |
Note:
For players to receive the broadcast and log statistics,
/scalable must be in the HTTP delivery list, which is described
in "Allowing HTTP Delivery". Enabling scalable multicasts
adds this mount point to the list automatically.
|
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".
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: |
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.| 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". |
Yes from the Enable Broadcast list. After the multicast, you can disable the channel by resetting this list to the default value No.| 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. |
mms://helixserver.example.com/wmtencoder/chopin.wma |
| For More Information: Refer to the Windows Media Services documentation on reporting multicast statistics for instructions about setting up IIS to gather statistics. |
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: |
.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.| 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. |
/wmtencoder/, so a Live Source entry might look like this:/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.
|
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.
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. |
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.
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: |
Yes. This instructs Helix Universal Server to create and send SAP files. The default value is No.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.|
|
© 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. |