previous next

Chapter 9: Transmitters and Receivers

Transmitters and receivers are two components of splitting, which enables you to deliver broadcast streams in any format to multiple Helix Universal Servers. The servers then unicast or multicast the stream to media players. This chapter describes different splitting arrangements, then explains how to set up Helix Universal Server as a transmitter, a receiver, or both.

Understanding Splitting

At its most basic level, splitting is a technology that enables one component to deliver a live or simulated live broadcast stream to another component. This allows an encoder to transmit a stream to one or more servers, for example, and a server to distribute a stream to one more additional servers. You can thereby deliver single broadcasts to many more users than you could with a single Helix Universal Server. As a result, splitting fosters higher-quality broadcasts by distributing broadcast streams closer to viewers.

Note: Splitting builds on the foundation of unicasting described in Chapter 7. Before you configure a splitting arrangement, be sure that you understand the concepts and procedures described in that chapter.

Tip: The section "SLTA Quick Start Tutorials" introduces you to transmitters and receivers by explaining how to simulate a live broadcast on your Helix Universal Server.


Because splitting technology has many uses and components, it is important to understand the following general terms.

An encoder is software that generates a live or simulated live stream. For RealMedia, an encoder can be Helix Producer or the simulated live transfer agent (SLTA). Additional encoders that you can use include Windows Media Encoder and Sorenson Broadcaster.

A transmitter is a Helix Universal Server on which a stream originates. The transmitter sends the stream to a receiver, and can also broadcast the stream directly to media players. Helix Producer and SLTA can also function as transmitters. They send a stream only to a Helix Universal Server receiver, however, and not to individual media players.

A receiver is a Helix Universal Server that receives a stream from a transmitter and broadcasts it to media players.

A relay is a Helix Universal Server that functions as both a receiver and a transmitter. It receives a stream from another source, and transmits that stream to another receiver. It may also broadcast the stream directly to media players.

Push Splitting
In push splitting, a transmitter initiates the splitting session by delivering the broadcast stream to one or more receivers.

Pull Splitting
In pull splitting, a receiver initiates the splitting session by contacting a transmitter and requesting the stream.

Encoder-to-Server Splitting

You can use splitting technology to deliver a live or simulated live broadcast stream from an encoder to Helix Universal Server. Although this arrangement involves splitting, it does not necessarily involve multiple Helix Universal Servers. Helix Universal Server can acquire a stream in many ways, not all of which use splitting. The following table explains the various methods of encoder-to-server delivery, indicating whether each method is based on splitting technology.

Splitting Used in Server Stream Acquisition
Stream Delivery Method Split? Notes
Live stream using Helix Producer push or pull mode. yes The push and pull modes in Helix Producer both involve splitting, in which Helix Producer is the transmitter and Helix Universal Server is the receiver.
Simulated live stream using SLTA. yes In its advanced mode, SLTA, which Chapter 10 covers, functions as a transmitter, and Helix Universal Server acts as a receiver.
Live stream using Helix Producer in account-based mode. no Although account-based mode is a subset of push mode, it does not use splitting. Instead, it uses the stream delivery technology of earlier versions of RealProducer. To broadcast in this mode, follow the instructions in "Setting Up Account-Based Broadcasting". You do not need to set up Helix Universal Server as a receiver.
Live stream using RealProducer G2 through 8.5. no Earlier versions of RealProducer do not use splitting technology. The section "Encoding with an Older Version of RealProducer" explains how to use them to deliver a stream to Helix Universal Server. You do not need to set up Helix Universal Server as a receiver.
Live or simulated live stream using any other media encoder. no Only RealNetworks encoders use splitting technology. Encoders for other media formats, such as Windows Media and QuickTime, deliver streams to Helix Universal Server by other means. See Chapter 7 for more information. You do not need to set up Helix Universal Server as a receiver.

No matter how Helix Universal Server acquires a broadcast stream, it can use splitting technology to transmit that stream to other Helix Universal Servers. Keep in mind, therefore, that encoder-to-server and server-to-server splitting are different functions, and one does not require the other. This enables you to split Windows Media and QuickTime broadcasts, for example, even though the encoders are not based on RealNetworks splitting technology.

Server-to-Server Splitting

In server-to-server splitting, a Helix Universal Server transmits a live or simulated live stream to another Helix Universal Server. The transmitter may have acquired the stream through a splitting set-up with a RealNetworks encoder, or through a conventional broadcast method. This allows you to distribute the same stream to multiple Helix Universal Servers across your network. You can use splitting technology to tie together a cluster of Helix Universal Servers on an intranet, as well as to connect different servers around the globe over the Internet.

Splitting offers many features that help you to tie together large networks of Helix Universal Servers, conserve bandwidth, and transmit different streams to different receivers. The following are the major features of server-to-server splitting, which subsequent sections explain in detail:

Push Splitting

The following illustration shows the conventional, or "push" form of server- to-server splitting. Here, the transmitter initiates the connection to the receiver. When a media player requests the broadcast, the receiver is ready to deliver the stream. In this form of splitting, Web page links typically point to the receiver. A transmitter can also deliver streams to media players, however.

Push Splitting

Push Splitting

Pull Encoding with Push Splitting

In push splitting, the encoder typically pushes the broadcast stream to the transmitter, initiating the broadcast. However, the transmitter can pull the stream from the encoder, too. This lets you use push splitting with the pull- only encoding methods of Windows Media and QuickTime. To do this, you might create a private link to the broadcast on the transmitter. When you're ready to push the stream to the receiver, you click this link, which causes the transmitter to pull the stream from the encoder, and push it to the receiver. Viewers can then connect to the broadcast on the receiver.

Push Splitting Configuration

You do the following to configure push splitting:

Pull Splitting

The following illustration shows pull splitting, in which the transmitter does not deliver the stream to the receiver until the first media player makes a request (step 1). There's a slight delay as the receiver requests (step 2), receives (step 3), and delivers (step 4) the stream. After that, the stream is live on the receiver, and subsequent player requests do not involve the session setup delay of step 2.

Pull Splitting

Pull Splitting

For More Information: For details about delays caused by pull splitting, see "Stream Acquisition Latency".

Pull Splitting Bandwidth Efficiency

Although pull splitting results in greater latency than push splitting on the first broadcast request, it can save on bandwidth because the stream is not transmitted to the receiver if no media player requests the stream. As well, if all media players disconnect from the receiver before the broadcast ends, the data stream between transmitter and receiver is dropped. Hence, pull splitting never consumes bandwidth between transmitter and receiver if no one is viewing the broadcast on that receiver.

Tip: You can combine push and pull splitting for optimal results. Suppose that you are delivering a broadcast across many different time zones. You could push the stream to receivers that reside in daytime zones. Where it's late at night and there are fewer potential viewers, you could have receivers pull the stream only on viewer request.

Push Encoding with Pull Splitting

If you set up pull splitting between transmitters and receivers, you can still use Helix Producer or SLTA to push the stream to the transmitter. This cues the broadcast so that the transmitter can respond faster to pull splitting requests from receivers.

Pull Splitting Configuration

You do the following to configure pull splitting:

SureStream-Aware Splitting

SureStream-aware splitting is similar to pull splitting when you broadcast RealMedia streams encoded at different bit rates. Without SureStream-aware splitting, the transmitter sends all streams encoded in the broadcast to the receiver. In the following illustration, the top portion illustrates a broadcast that is not SureStream-aware. The broadcast itself may be either push or pull. When the receiver acquires the broadcast stream, it gets all of the SureStream bit rates, even if only the 56 Kbps stream has been requested by media players.

In contrast, SureStream-aware splitting sends each stream only on request. The bottom half of the following illustration shows a player requesting the 128 Kbps stream. Even though the encoder sends the transmitter all the streams, only the 128 Kbps stream goes to the receiver. If another media player later requests the 56 Kbps stream, the transmitter forwards that stream, too. If a certain stream is never requested, it is never sent to the receiver. As well, the transmitter drops a stream if media players stop using it during the broadcast.

SureStream-Aware Splitting Enabled from Transmitter to Receiver

SureStream-Aware Splitting Enabled from Transmitter to Receiver

SureStream-aware splitting works with both push splitting and pull splitting arrangements. Even if your entire network is set up for push splitting, receivers are sent individual SureStream streams only on request. Like pull splitting, SureStream-aware splitting helps to conserve bandwidth during broadcasts, but is not available when transmitters and receivers communicate through multicasting.

Tip: To archive a SureStream-aware broadcast, set up your archive on the Helix Universal Server connected to the encoder. This is the only server guaranteed to receive all SureStream streams. For more on archiving, see "Archiving Broadcasts".

Complex Splitting Arrangements

You can combine the basic splitting methods (push and pull) with the two transport methods (unicast and multicast) in many ways. Splitting also supports encoder redundancy, and can add failover protection for streams and transmitters. The following sections describe different splitting setups, their benefits, and drawbacks. Keep in mind that you can create different splitting arrangements throughout different parts of the network to achieve your goals, whether that's to maximize bandwidth efficiency, or to reduce broadcast latency.

One-to-Many Splitting

A common splitting arrangement uses a single transmitter to broadcast to multiple receivers. If you do this through unicasting, each receiver gets a unique stream, so bandwidth consumption increases with each receiver. Multicasting uses less bandwidth, and is a better solution if all components are on a multicast-enabled network. The following illustrations shows unicasting through push splitting, though you can also use pull splitting, in which each receiver connects to the transmitter only when it needs the stream. Server-to-server multicasting is not available with pull splitting, however.

One-to-Many Splitting

One-to-Many Splitting

Because both Helix Producer and SLTA use splitting technology, they can function as transmitters connecting to multiple Helix Universal Server receivers. A Helix Universal Server is therefore not required to be the transmitter. For a live broadcast, though, you may not want to use Helix Producer to transmit the stream to many receivers. Real-time encoding of a live event uses a lot of processor power, and it's better not to burden the encoder with stream management overhead as well. This is not an issue in a simulated live broadcast using SLTA, however, because the streams are already encoded.

One-to-One Chaining

Another option is to use one-to-one chaining, in which each receiver transmits to another receiver. Receivers in the middle of the chain thereby function as relays. This option is viable if a group of servers is spread across a wide area, and uses unicasting over the Internet to communicate. A transmitter in San Francisco might push a stream to a Tokyo receiver, which pushes it to a Sydney receiver, and so on.

One-to-One Chaining

One-to-One Chaining

Although you can use pull splitting with a relay chain, push splitting suits this setup better. With pull splitting, there may be a long latency period if the first broadcast request comes from far down the chain. In this case, the request has to make its way back the chain, causing each receiver in the chain to pull the stream from the preceding transmitter. As well, pull splitting links for a relay chain quickly become very long, increasing your chances of writing incorrect URLs to the broadcast. Using URL aliases, though, eases this burden.

Unicast Delivery, Multicast Distribution

Splitting works with multicast delivery, as well as unicasting. You can unicast streams to receivers across the Internet, an intranet, a wide area network, or a local area network, for example. Then, within an intranet, you can multicast the stream from the receivers to media players. The following illustration shows this type of delivery.

Unicast Delivery, Multicast Distribution

Unicast Delivery, Multicast Distribution

Dual Unicast and Multicast Transport Methods

If your server network is multicast-enabled, you can simultaneously unicast and multicast a broadcast stream to receivers. Duplicate packets arriving by different transport methods increase the network overhead, but do not cause problems for receivers. When a receiver reassembles the broadcast stream, it uses the packets that arrive first, regardless of their transport methods. If a unicast packet is late or missing, for example, the receiver may get the right packet through multicast. The following figure illustrates this dual delivery.

Broadcasting by Multiple Methods

Broadcasting by Multiple Methods

Tip: Server-to-server multicasting requires a multicast-enabled network just like server-to-player multicasting. However, you do not configure server-to-server multicasts as described in Chapter 8. You simply select multicast as your transport method when configuring transmitters and receivers.

Redundant Stream Splitting

As explained in "Using Broadcast Redundancy", Helix Universal Server supports encoder redundancy for all media formats. This redundancy carries over automatically with splitting, requiring no special configuration for transmitters and receivers. As shown in the following illustration, separate encoders deliver the same stream (delimited with an integer, as in live.rm.1 and live.rm.2) to the transmitter. If the primary stream files, the transmitter uses the backup stream. It sends the receiver one stream, which may come from either the primary or the backup encoder.

Simple Redundant Source for Splitting

Simple Redundant Source for Splitting

Transmitter Redundancy

The setup in the preceding illustration provides a single level of encoder redundancy. You can increase redundancy within a splitting arrangement by adding transmitter redundancy, as shown in the following illustration. Here, both the primary and backup encoders send streams to two Helix Universal Servers that each split the stream to three receivers. (Both SLTA and Helix Producer can push the same stream to multiple Helix Universal Servers.) Under normal conditions, each receiver gets a version of live.rm from each transmitter.

Redundant Sources and Redundant Transmitters

Redundant Sources and Redundant Transmitters

If the primary encoder in the preceding illustration fails, both transmitters switch to the stream from the backup encoder. Again, the receivers get two streams, one from each transmitter. Note that in this configuration, each receiver still receives a stream even if one encoder and one transmitter fail. This provides both encoder and transmitter redundancy. Three out of the four encoder and transmitter components would have to fail for the entire broadcast to fail.

Transport Redundancy

The following illustration shows multiple encoders and delivery methods used to provide encoder and transport redundancy. The primary and backup encoders both unicast a separate stream to each receiver, as well as multicast the broadcast stream to all receivers. Each receiver gets four streams. It uses the primary live.rm.1 stream as long as those packets arrive by either unicast or multicast. If the primary encoder fails, or its transport methods are blocked, each receiver switches to the live.rm.2 backup sent over unicast or multicast.

Redundant Encoders Using Unicasting and Multicasting

Redundant Encoders Using Unicasting and Multicasting

Note that the receivers in the preceding illustration could also function as transmitters that split streams to other receivers, as described in "Transmitter Redundancy". This would provide three layers of redundancy at the encoder, transmitter, and transport levels. Although such a complex arrangement and high degree of redundancy is generally not necessary, RealNetworks components provide support for all of these layers, which you can put together as needed.

Multiple Splitting Definitions

You may set up your transmitters and receivers to split every broadcast the same way. In this case, you always use a certain Helix Universal Server as your primary transmitter, and your other Helix Universal Servers as receivers or relays. This is not necessary, however, and a single network of Helix Universal Servers can support numerous splitting arrangements, enabling you to transmit from any Helix Universal Server. As well, you can split broadcasts from a single transmitter in many different ways.

When you set up splitting, you can create multiple transmitter and receiver definitions on each Helix Universal Server. When you set up a push transmitter, for example, you define how it connects to each receiver. For a single Helix Universal Server receiver on one physical machine, you can create multiple receiver definitions. RealMedia broadcasts can use one definition, for example, while Windows Media broadcasts use another. This lets you multicast one format, for instance, while unicasting another.

You can also use multiple receiver definitions to split broadcasts in different ways according to stream source names, which appear in links to broadcasts. A source name has three parts:

  1. mount point—As explained in Chapter 7, every broadcast uses a mount point. Broadcasts pushed by Helix Producer use the /broadcast/ mount point, for example, while Windows Media broadcasts use /wmtencoder/.
  2. path—The optional path name does not necessarily correspond to an actual path. It's generally a name inserted between the mount point and the stream name to provide splitting functionality. How you define the path differs for each media format:
  3. stream name—In all broadcasts, the stream name appears last in the URL and looks like an on-demand clip name, ending with the media format's standard file extension.

The following illustration shows how you can use mount points, paths, and stream names within receiver definitions to split different broadcasts in different ways. Three encoders connect to the same transmitter and deliver three separate streams. The first stream, live.rm, uses no path. The second and third streams, news/breaking.rm and news/hourly.rm, use the same path name, but different stream names.

Stream Direction through Mount Points, Paths, and File Names

Stream Direction through Mount Points, Paths, and File Names

Each receiver in the preceding illustration is defined with a different broadcast source path. (The definitions are actually created on the transmitter, which is responsible for directing the streams.) The first receiver accepts all broadcasts that use the Helix Producer default broadcast mount point, /broadcast/. In this example, it receives all three broadcast streams because specifying just the mount point is the widest source criterion.

The second receiver gets all broadcasts that use the /broadcast/news/ mount point and path. It therefore receives streams 2 and 3, but not stream 1, which does not use the news/ path. The third receiver uses the most specific criteria. It receives only the broadcast streams that use the /broadcast/news/hourly.rm mount point, path, and stream name.

Splitting Considerations

This section provides general information you'll find useful when setting up any splitting arrangement. When you use pull splitting, you need to consider the latency involved in acquiring a stream. When unicasting multiple streams, bandwidth is an issue because each receiver gets a separate broadcast stream.

Stream Acquisition Latency

Receiver latency occurs in pull splitting when the first media player requests the broadcast. On the first request, the receiver pulls the stream, but must wait for session announcement information to arrive from the transmitter. To determine how long a receiver takes to acquire a live split stream, you need to consider the following:

A receiver does not start to process incoming data until it receives the session description from the transmitter. If the transmitter's session metadata rate is set to 30 seconds, for example, the receiver needs to wait up to 30 seconds to get the session description and begin to process broadcast packets. This time delay does not include any network latency that may exist between the transmitter and the receiver.

As soon as the live distribution stream arrives at the receiver, the receiver constructs a local buffer before streaming data to the connected media players. To help minimize latency, a receiver that uses pull splitting builds only a 1-second buffer before sending the stream to the media player that initiated the pull splitting session.

Note: With SureStream-aware splitting, session description information is sent to receivers even when no players are connected. Because the receiver does not have to wait for the next session description, latency is not an issue even though SureStream-aware splitting functions like pull splitting.

Bandwidth Consumption

Calculating the bandwidth used by a broadcast depends on whether the broadcast is single-rate stream, or a multi-rate format like SureStream. Single- rate broadcasts consume bandwidth according to the following criteria:

For example, a single-rate 100-Kbps stream with an error correction rate set to 10 percent (10 Kbps) will need approximately 10 Kbps of overhead, for a total bandwidth of approximately 120 Kbps.

The bandwidth consumed by a SureStream broadcast equals the combined bit rates of all the audiences, plus the overhead percentages described previously. If SureStream-aware splitting has been enabled, bandwidth use is determined by the actual number of bit rates requested by media players, however. Your calculation will give you a maximum, but not all streams may be requested during the broadcast.

Other Features Used with Splitting

This following table describes the ways in which splitting works with other features

Splitting Used with Other Features
Feature Notes
SLTA SLTA transmits prerecorded clips as simulated live broadcasts. Using it is a good way to test your receiver configurations before you broadcast a live event
Live Archiving Both transmitters and receivers can archive live RealMedia streams. With SureStream-aware splitting, archive on the transmitter connected to Helix Producer to ensure that all streams are archived.
Multicasting A multicast transmission between receivers and media players, as described in "Unicast Delivery, Multicast Distribution", makes the most effective use of bandwidth.
Helix Universal Proxy Because live events are not files, Helix Universal Proxy cannot cache broadcasts. Instead, Helix Universal Proxy replicates live streams among media players through pull splitting.
Firewalls In their default configuration, the transmitter and the receiver use UDP for fast, efficient distribution. Some firewalls may block UDP traffic, however. For more information, see "Communicating With Receivers".
Access Control If you use the access control feature to block access to your transmitter, receivers can still receive push broadcasts, but transmitters cannot honor a receiver's resend requests. Pull splitting receivers will not receive any content at all.
Authentication When splitting a broadcast that requires viewer validation, place copies of all databases that store authentication information on receivers to distribute the authentication load.

Setting Up a Transmitter

The following sections explain how to configure Helix Universal Server as a push or a pull transmitter. Although the same Helix Universal Server can function as a push or a pull transmitter in different cases, you define each transmitter instance separately. That is, the push transmitter settings do not require you to set anything in the pull settings area, and vice versa.

If your Helix Universal Server is receiving a broadcast stream from Helix Producer or SLTA, you set it up as a receiver, not a transmitter. Here, Helix Producer or SLTA is the transmitter, which you set up as described in Helix Producer's User's Guide or Chapter 10, respectively. In these cases, you need to define Helix Universal Server as a transmitter only if it forwards the broadcast stream to other Helix Universal Server receivers.

Defining a Push Transmitter

You create a separate push transmitter definition for each receiver that your Helix Universal Server transmits to. To broadcast to multiple receivers at the same time, you define multiple transmitter instances that all use the same broadcast source path. Alternatively, you can set up receivers to receive only certain broadcasts. This lets you create a large list of receivers that are sent broadcast streams only when those streams include certain path criteria.

To define a push transmitter:

  1. In Helix Administrator, click Broadcast Distribution>Transmitter.
  2. In the Source Name box, enter a name that identifies this transmitter. Because this name appears in links to the split broadcast, use letters and numbers, but not spaces. Examples in this chapter use Japan as the transmitter name.
  3. In the Broadcast Receivers area, click the "+" icon, and change the name in the Edit Receiver Name box to the name or description for the Helix Universal Server that will receive the broadcast stream. This name is for your reference only, and is not used in the broadcast.
  4. For Source Path, specify the mount point and, optionally, a path and a stream name used for broadcasts from this transmitter. The default is /broadcast/, and you can use just this mount point to send the receiver all broadcast streams delivered to this transmitter by Helix Producer or SLTA.
  5. If you use an earlier version of RealProducer, change the broadcast mount point to /encoder/. For Windows Media broadcasts, the default is /wmtencoder/. And for QuickTime or general RTP-based broadcasts, the mount points are /qtencoder/ and /rtpencoder/, respectively. If you are using redundant encoders with any media format, use the mount point /redundant/.

    For More Information: For more on using a path and stream name, see "Multiple Splitting Definitions".

  6. In the Receiver IP Address or Hostname box, enter the address or host name of the Helix Universal Server that receives this broadcast stream. If you plan to multicast the stream from this transmitter, you must specify an appropriate class D multicast address.
  7. For Local IP Address, specify the network address used for transmitting this broadcast. The receiver requires this address for resend requests.
  8. Tip: If you have a multi-homed machine that uses several IP addresses, be sure to use an IP address bound to Helix Universal Server, as described in "Binding to an IP Address".

  9. From the Transport list, select the transport method for transmitter-to-receiver communication. You must set the same transport on both the transmitter and the receiver. The options, listed in order of recommended use, are the following:
  10. Several fields and lists let you configure optional transmitter features:
    1. To enable SureStream-aware splitting, ensure that Enabled is selected in the SureStream Aware Splitting box. Otherwise, select Disabled. The setting has no effect if you are not splitting a SureStream broadcast. For more information, see "SureStream-Aware Splitting".
    2. If you selected the udp/multicast transport option, enter a number in the Multicast Time to Live (TTL) box. For a list of possible TTL values, refer to "Packet Time to Live". The default is 16.
    3. For Error Correction Rate, you can set the percentage of corrective packets sent. The default value for Internet splitting is 20, which adds a 20% bandwidth overhead to the stream for error correction. A higher number results in more reliable delivery of data, but consumes proportionally more network bandwidth. If you're splitting within a local area network, you can set this to a lower value or to 0 (zero) because you are less likely to need error correction.
    4. The Metadata Transmit Rate field sets the frequency in seconds at which special packets are sent from the transmitter to the receiver. These packets describe the stream being split, and are required for the receiver to process the incoming stream. Use a number from 1 to 60. A lower number may result in lower startup latency on a receiver, but consumes more network bandwidth. See "Stream Acquisition Latency" for more information.
    5. To improve quality of service, receivers can re-request packets that arrived in poor quality, or not at all. Select Yes in Honor Resend Requests to enable packet resending. Because this option requires a back channel from the receiver to the transmitter, it increases bandwidth use slightly to enable the resend traffic.
    6. Set Relay Live Broadcasts to Yes if this transmitter is a relay that forwards streams from one Helix Universal Server to another Helix Universal Server, as described in "One-to-One Chaining". If the originating encoder delivers the stream to this Helix Universal Server, set the value to No.
    7. Note: A Yes value for Relay Live Broadcasts means that this server's address does not appear in the media request URL on a receiver further down a splitting chain. The server will still forward a stream if this value is No. But in this case, the server's address must appear in the request URLs on receivers.

  11. The Port Range boxes set the ports on receivers to which the stream is sent. If you change the default ports, RealNetworks recommends using a range of 20 ports. If you cannot use a range of 20 ports, reserve at least 1 port per Megabit of broadcast stream bandwidth.
  12. To secure stream transmissions, select Basic from the Security Type list, and type a password in the Password box. The transmitter passes this word to the receiver to verify its identity. To turn off the password requirement, choose None from the Security Type list. The password needs to be defined on the receiver as well.
  13. Click Apply.

Configuring a Pull Splitting Transmitter

The following procedure explains how to set up Helix Universal Server as a pull splitting source. Pull splitting definitions are entirely independent of push splitting information. With pull splitting, you do not define specific receivers as you do in push splitting. Instead, you set basic parameters that identify the broadcast stream. Then, any receiver can pull the stream. In other words, the pull splitting transmitter definition does not contain any information about potential receivers.

To configure the transmitter for pull splitting:

  1. In Helix Administrator, click Broadcast Distribution>Transmitter.
  2. In the Pull Splitting Sources area, click the "+" icon and edit the name that appears in the Edit Source Name box. This name is for your reference only, and does not appear in URLs.
  3. In the Source Path box, enter the path through which live streams are sent, typically /broadcast/, /encoder/, /redundant/, /wmtencoder/, /qtencoder/, or /rtpencoder/, as explained in Chapter 7. The default value of /broadcast/ means that this transmitter definition allows receivers to pull any broadcast sent to the transmitter from Helix Producer in push or pull mode.
  4. Tip: Optionally, you can specify a path and stream name to define only specific broadcasts that can be pulled. For an example of using source paths, refer to "Multiple Splitting Definitions".

  5. For Local IP Address, specify the network address the transmitter uses. This is the address the receiver contacts to pull the stream. All pulled streams are unicast over UDP when possible, or TCP if UDP is not available.
  6. In the Listen Port box, type a port number on which this transmitter listens for requests. These port numbers are used in request URLs. If you leave this field blank, Helix Universal Server uses the value 2030.
  7. Tip: All pull splitting definitions can use the same listen port, as long as no simultaneous broadcasts use the same stream name. If you want to broadcast the same stream name at the same time through different pull splitting definitions, give each definition a unique listen port number.

  8. If you want to enable SureStream-aware splitting, select Enabled in the SureStream Aware Splitting box. For more information, see "SureStream-Aware Splitting".
  9. Type a password in the Password box. The receiver will use this word to verify its identity when it requests a stream. To turn off this feature, choose None from the Security list.
  10. Warning! Password validation is strongly recommended for all pull-splitting broadcasts. If you turn off validation, any server can pull the stream from your transmitter.

  11. Click Apply.

Setting Up a Receiver

The following sections describe how to define basic receiver information, and how to enable that receiver to make pull splitting requests. To configure a receiver, you need to know the following settings on the transmitter:

Defining Basic Receiver Information

For a pull splitting or push splitting receiver, you set up basic information about the receiver as described in the following procedure. Just as a transmitter definition lists properties of receivers, the receiver defines properties of transmitters.

To configure a receiver:

  1. In Helix Administrator, click Broadcast Distribution>Receiver.
  2. The Mount Point box defines the mount point used in URLs to the broadcast on the receiver. It identifies the source as a live broadcast rather than a clip. The default is /broadcast/.
  3. Tip: A broadcast may go out from a transmitter on a different mount point, such as /wmtencoder/ for Windows Media. Each receiver can broadcast the split stream from its /broadcast/ mount point regardless of the media format, however.

  4. In the Broadcast Transmitters area, click the "+" icon and enter a descriptive name for the transmitter in the Edit Transmitter Name box.
  5. For Transmitter Address, type the host name or IP address of the transmitter. To receive broadcast streams from a range of transmitters, set a bit mask around the specified IP address through the Transmitter Netmask list. See Appendix B for information about using a bit mask.
  6. In the Port Range boxes, set the ports on which the stream is received. The port values should match the settings on the transmitter.
  7. In the Transport box, select the same option that's in use on the transmitter. If you select udp/multicast, you must also add to the Multicast Address field a class D multicast address. This address must match the value in the transmitter's Receiver IP Address or Hostname box.
  8. To re-request packets that did not arrive at the receiver, select Yes for Resend Requests. This option provides greater quality, but requires more network bandwidth. If you enable resend requests, the transmitter needs to have Honor Resend Requests set to Yes.
  9. For Security Type and Password, use the same values set on the transmitter.
  10. If you are not enabling pull splitting on the receiver, click Apply. Otherwise, configure pull splitting as described below.

Enabling Pull Splitting Requests

To enable pull splitting, you set the receiver properties explained in "Defining Basic Receiver Information". Then, add the pull splitting information described in the following procedure.

To enable the receiver for pull splitting:

  1. On the Broadcast Distribution>Receiver page, select the receiver you want to configure for pull splitting, and scroll down to bottom of the page.
  2. From the Enable Pull Splitting Requests list, select Yes.
  3. In the Pull Splitting Virtual Path box, type a value in the form of a mount point, such as /split/. You will use this virtual path in URLs to indicate that the stream is pulled.
  4. For Error Correction Rate, set the percentage of corrective packets sent by the transmitter (the FEC rate set on a transmitter is used only with push splitting). The default value for Internet splitting is 20, which adds a 20% overhead to the stream for error correction. A higher number results in more reliable delivery of data, but consumes proportionally more network bandwidth. If you're splitting within a local area network, you can set this to a lower value or to 0 (zero) because you are less likely to need error correction.
  5. The Metadata Transmit Rate box sets the rate at which the transmitter sends packets describing the session (the metadata rate set on a transmitter is used only with push splitting). A higher number results in better quality and higher startup latency on the receiver, but consumes less network bandwidth. Use a number from 1 to 60. The default value is 30, which sends the metadata once every 30 seconds, adding up to 30 seconds of latency to the initial pull request.
  6. To split over a connection in which stream packets are likely to be lost, you can set the Pull Splitting Backchannel Transport field to TCP. This setting results in a highly reliable connection that requires slightly more network overhead.
  7. Click Apply.

Linking to Split Content

A link to a split stream points to the receiver, and indicates the transmitter where the stream began. Links for push splitting and pull splitting streams are different. For both types of links, you can use URL aliases, which are especially useful for the longer pull splitting links. The following sections explain link formats in general, and provide example links for RealMedia broadcasts. For broadcasts in other formats, you need to use transmitter mount points and stream names as appropriate for that format.

Tip: For examples of links to basic broadcasts in different media formats, see "Linking to Unicasts". The links to split streams build on those basic formats.

Writing Push Splitting Links

Push splitting links point to the Helix Universal Server receiver, but include the source name of the transmitter to identify the broadcast. These URLs are relatively simple, and build on the basic unicast URL format.

Linking from a Web Page

A Web page link to a pushed RealMedia broadcast in which a Helix Universal Server receiver uses the default port 80 for HTTP might look like this:

Linking through a Relay

It typically does not matter if one or more relays exist between the receiver and the transmitter, as illustrated in "One-to-One Chaining". The link refers only to the receiver and the originating transmitter, as long as each relay has its Relay Live Broadcasts field set to Yes.

If one or more relays in the chain has Relay Live Broadcasts set to No, however, you need to include those servers' transmitter names in the URL. Here is an example of a Web page URL that lists two relays along with the transmitter and receiver address:

In this example, the Japan transmitter is the originating transmitter, just as in the preceding examples. The stream travels from this transmitter to the Sydney transmitter, then to the LosAngeles transmitter, before arriving at the receiver. Note that the URL components reflect the exact order in which the stream travels through the chain.

Linking to a Transmitter or Relay

An originating transmitter, as well as any relay in the chain, can also deliver the broadcast to media players. URLs to an originating transmitter are standard unicast URLs, as described in "Linking to Unicasts". The Web-page URL to the broadcast on the Japan transmitter would therefore look like this:

To link to the broadcast on a relay, you treat the relay as if it were the receiver at the end of the splitting chain. It does not matter if the relay has its Relay Live Broadcasts value set to Yes or No. For example, the Web page link to the broadcast on the LosAngeles relay, which links through the Sydney relay to the Japan transmitter looks like this:

Linking from a Ram or SMIL File

You can also launch a broadcast through a Ram file or SMIL file, as described in "Using Metafiles". The URL format is similar to the preceding examples, but specifies RTSP or MMS, and omits the /ramgen/ or /asxgen/ parameter. In the following example of a URL to a receiver, the port number is omitted, which means that port 554 is used for RTSP:


Here is a sample URL to the unicast on the Japan transmitter:


Creating Pull Splitting Links

Pull splitting links are more complex than push splitting links. The link URL tells the receiver where to pull the stream by giving the transmitter's address and listen port. If you have a relay chain as described in "One-to-One Chaining", a link to a broadcast on a specific receiver must indicate all of the preceding links in the chain in the proper order. URL aliases can shorten the published URLs, as well as mask the transmitter addresses.

Note: When pull-splitting Windows Media streams, you must use URL aliases because Windows Media Player does not recognize the URL format used for pull splitting.

Linking from a Web Page

A Web page link to a pulled RealMedia broadcast in which a Helix Universal Server receiver uses the default port 80 for HTTP might look like the following example, in which the URL is shown on two lines to clarify the link portions. The first line gives the receiver information, while the second line supplies the transmitter parameters:

Linking through a Relay

If the stream travels through a relay before reaching the receiver, the URL must include the relay address. When a media player requests the broadcast from the receiver, the receiver contacts the relay to pull the stream, which, in turn, contacts the transmitter to pull the stream. The relay information comes between the transmitter and receiver information. As with the transmitter, the URL gives the relay's address, listen port, and broadcast mount point:

Linking from a Ram or SMIL File

You can also launch a pull splitting broadcast through a Ram file or SMIL file, as described in "Using Metafiles". The URL format is similar to the preceding examples, but specifies RTSP or MMS, and omits the /ramgen/ or /asxgen/ parameter. In the following example of a URL to a receiver, the port number is omitted, which means that port 554 is used for RTSP:


Using URL Aliases

The section "Setting Up Aliases" explains how to create an alias for URL elements. This is a handy way to shorten URLs and mask transmitter addresses in pull splitting URLs. Aliases are optional except when you use pull splitting in a Windows Media broadcast. Windows Media Player does not recognize transmitter addresses and listen ports in pull splitting URLs.

You set up the appropriate alias on each Helix Universal Server that receives broadcast requests from media players. To illustrate the use of an alias, consider the pull splitting example shown in the preceding section:

On the receiver that handles this broadcast request, you could define the following alias to mask the relay and transmitter addresses:

URL component:
Alias: pull/

Your published URL would then look like this:

Note: You can use just one alias in each URL.

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