Chapter 11: Running a Broadcast

This chapter explains how to set up a broadcast by defining server destinations and templates. The procedure differs depending on the type of broadcast you are performing. Refer to Chapter 10 for background about broadcasting options.

Tip: You can also encode the output as an archive clip during the broadcast. The section "Creating a Destination Clip" explains how to do this.

Running an Account-Based Broadcast

Account-based, push broadcasting provides easy set-up and reliable delivery of the broadcast stream. It allows you to send a stream to Helix Server version 9 or later. In this method, RealProducer maintains a monitoring connection to Helix Server. This connection allows it to pass a user name and password to authenticate access to the server. Helix Server uses this connection to send statistics about the broadcast stream back to RealProducer.

For More Information: Refer to the section "Running an Account-Based Broadcast" for set-up instructions.

Advantages of Account-Based Broadcasting

Because of its monitoring connection, account-based broadcasting is a good method to use if you do not have access to the monitoring pages on Helix Server. The feedback from the monitoring connection informs you if the access attempt failed because of an invalid password, for instance. It also informs you if the connection between RealProducer and the server was dropped and automatically restarted.

Setting up an account-based broadcast requires a minimal amount of knowledge about how Helix Server is configured. You need to know the server IP address, and have a valid user name and password for an encoder login defined by the Helix Server administrator in the server's authentication database.

Account-Based Broadcast Steps

The following figure illustrates the interaction between RealProducer, Helix Server, and RealPlayer in an account-based broadcast.

Account-Based, Push Broadcast

1. RealProducer establishes its monitoring connection with Helix Server. Using this connection, RealProducer sends a user name and password that authenticates its attempt to access the server.
2. After Helix Server authenticates the broadcast, it informs RealProducer how to make the broadcast connection, telling it which server ports to use, for example.
3. RealProducer establishes the broadcast stream connection to Helix Server. It begins to send the encoded packets, whether or not any RealPlayer users have requested the broadcast yet.
4. A viewer typically requests the broadcast by clicking a link in a Web page. This launches RealPlayer, which requests a broadcast stream from Helix Server.
5. Helix Server streams the broadcast to RealPlayer.

Preparing Helix Server for an Account-Based Broadcast

Helix Server requires minimal configuration to receive and distribute an account-based broadcast. Confer with the server administrator on the following issues, which are covered in the unicasting chapter of Helix Server Administration Guide:

• RealProducer requires a valid user name and password. These values are defined in the Helix Server authentication database under the SecureRBSEncoder realm. If you previously broadcasted using RealProducer 8.5 or earlier, your user name and password were defined under a different authentication realm and will not work with RealProducer 10.

Tip: If you are the Helix Server administrator, you can connect using the user name and password for Helix Administrator. For greater security, however, define a different user name and password for RealProducer.

• The broadcast requires at least two ports on Helix Server for the stream data, whether you use TCP or UDP. RealProducer and Helix Server negotiate which ports to use. Possible ports are in the range 50001 to 50050 unless the Helix Server administrator changes the range.

Tip: If you select UDP transport, ensure that any firewalls between RealProducer and Helix Server allow UDP data sent to Helix Server on the ports in the defined range. If you are broadcasting through a firewall performing network address translation (NAT), you may need to set the RealProducer listen address to the IP address of the firewall or the value 0.0.0.0. See "Listen Address".

• If you want to archive or split the broadcast on Helix Server, you may need to apply archiving or splitting rules. This requires that the Helix Server administrator define the rules for a specific virtual path that precedes the stream name, as in news/live.rm. For background, refer to "Virtual Paths".
• If you plan to use redundant encoders, verify the stream delimiter expected by Helix Server. This is typically a period, as in live.rm.1 and live.rm.2. For more on this topic, see "Encoder Redundancy".
• The URL for the broadcast varies depending on the Helix Server features, such as viewer authentication, that you use. The section "Standard URL for a Push Broadcast" explains the basic URL format.
• Although RealProducer receives statistics about the broadcast stream, it does not receive statistics about the actual broadcast, such as how many RealPlayer viewers connected and how long they watched. Depending on the method Helix Server uses to broadcast the stream to the players, as well as the server logging parameters, the server log files may record these statistics.

Defining the Account-Based Server Destination

This section explains how to define the account-based broadcast on RealProducer. You can create the server destination anytime before the broadcast, and can save the settings to a template for future use. You'll need the following information about Helix Server:

• Helix Server IP address or DNS name
• Helix Server HTTP port number
• valid user name defined in the SecureRBSEncoder realm of the Helix Server authentication database
• valid password for the user name

To set up an account-based server destination:

1. If you have multiple jobs open, click the appropriate job file name in the job manager.
2. Select File>Add Server Destination to display the server destination dialog. Or, click the server icon in the destinations area.
3. Enter a description of the server in the Destination Name field. This is for your reference only and does not affect the broadcast. If you save the destination as a template, this entry becomes the name of the template in the graphical application, as well as the file name of the server destination file.
4. In the Stream Name field, enter a name for the broadcast stream. This name resembles a clip name and should use the appropriate extension, either .rm for a constant bit rate stream or .rmvb for a variable bit rate stream. This name appears in the broadcast URL.

The stream name can include uppercase or lowercase letters, numbers, an underscore (_), and a dash (-). Spaces are not allowed. If you are using encoder redundancy, include the appropriate stream delimiter and a unique number for this encoder:

live.rm.2

5. From the Broadcast Method pull-down list, select Push, Account-Based Login (Helix Server).
6. For Server Address, enter the IP address or DNS name of the Helix Server used for the broadcast, such as 207.188.7.176 or helixserver.example.com.
7. The optional Path field specifies a virtual path that can be used for archiving or splitting on Helix Server. Use a simple name followed by a forward slash, such as news/.
8. For Port, specify the HTTP port on Helix Server. The default value is port 80, which is the server's default HTTP port. For account-based broadcasting, RealProducer uses its monitoring connection to contact Helix Server on this port and deliver the broadcast stream information. RealProducer and Helix Server then negotiate which UDP or TCP ports to use for the broadcast data.
9. In the Username and Password fields, enter a valid encoder user name and password defined in Helix Server's authentication database. The broadcast connection fails if either value is incorrect. If you are saving the destination as a template, you can click Remember password to store the user name and password in the template file.

Warning! The password is saved as plain text in the job file or the server template. If you save the password, be sure that you maintain appropriate security on these files.

10. Under Transport, click the radio button for UDP or TCP to select the type of protocol to use for the broadcast stream. UDP is preferred, but may be blocked by firewalls. See "Broadcast Transport Protocols" for descriptions of TCP and UDP.
11. You may want to set the advanced broadcast options by clicking the Advanced Options button. See "Changing Advanced Push Broadcast Parameters" for more information.
12. To save the server destination as a template, click the Templates button and select Save as Template. You can then use this server destination for future broadcasts, as described in "Working with Server Templates".
13. Click OK to save the server destination. The destination appears in the destinations section of the RealProducer main window. You can right-click the destination name to edit or delete the destination.

Starting and Stopping an Account-Based Broadcast

When you have completed the server destination and have defined the live input as described in "Using Live Audio or Video as the Input", you can start the broadcast by clicking the Encode button. RealProducer immediately begins to encode the live input, sending the broadcast stream to Helix Server.

If configured to do so, the account-based broadcast method automatically reconnects a dropped broadcast stream. Because of its monitoring connection, RealProducer receives broadcast statistics and notification if Helix Server has stopped the broadcast. If the server stops the broadcast, RealProducer terminates the stream and stops the encoding process. You can also terminate the broadcast by clicking the Stop button.

For More Information: See "Monitoring Statistics" for information about monitoring a broadcast in progress.

Setting Up a Password-Only Broadcast

Unlike account-based broadcasting, password-only broadcasting does not establish a monitoring connection. It therefore incurs less network overhead, but it receives no feedback from Helix Server. This broadcast method allows you to send a live stream to Helix Server version 9 or later. You must set up the server as a receiver in a splitting arrangement, however.

Advantages of Password-Only Broadcasting

Because it sets up no monitoring connection between RealProducer and Helix Server, password-only broadcasting requires less bandwidth and processor power on the RealProducer machine. This makes the broadcast more efficient, especially if you have multiple server destinations. Password-only broadcasting also lightens the load on Helix Server because the server does not need to generate broadcast statistics for RealProducer.

A password-only broadcast re-establishes its connection automatically. If the broadcast connection fails for some reason, RealProducer continues to send the stream to Helix Server. It automatically encodes the broadcast metadata (such as the stream name) and password into the stream every at regular intervals. This allows Helix Server to re-establish the broadcast once it begins to receive the stream data again.

For More Information: The section "Metadata Resend Interval" explains the advanced parameter that affects how long it takes Helix Server to re-establish a dropped broadcast stream.

Disadvantages of Password-Only Broadcasting

Password-only broadcasting is recommended only when you operate both RealProducer and Helix Server. Each broadcast stream protected by a unique password requires a separate receiver definition on Helix Server. This broadcasting method therefore requires more Helix Server configuration than does account-based broadcasting. Because the server provides no feedback, it is impossible to verify from RealProducer if the log-in attempt failed. You can use Helix Server's monitor, however, to determine if the broadcast connection has been established.

Password-Only Broadcast Steps

The following figure shows the interaction between RealProducer, Helix Server, and RealPlayer in a password-only broadcast.

Password-Only, Push Broadcast

1. As soon as it starts encoding the broadcast stream, RealProducer sends the stream packets to the Helix Server address. It receives no feedback that the broadcast packets have been received, encoding the stream metadata and server login password into the stream at regular intervals.
2. A viewer typically requests the broadcast by clicking a link in a Web page. This launches RealPlayer, which requests a broadcast stream from Helix Server.
3. Helix Server delivers the broadcast to RealPlayer.

Preparing Helix Server for Password-Only Broadcasting

In a password-only broadcast, RealProducer acts as a transmitter and Helix Server functions as a receiver in a splitting arrangement. This highly robust configuration requires coordinated set-up on both ends. The chapter on transmitters and receivers in Helix Server Administration Guide explains splitting, and shows how to set up the server as a receiver. Before running a password-only broadcast, confer with the server administrator on the following issues:

• To be configured as a receiver, Helix Server must be licensed for broadcast distribution. Clicking the About link in Helix Administrator displays the Helix Server licensing information.
• To connect to the Helix Server receiver, RealProducer transmits a password. Unlike with account-based broadcasts, this password is not defined in the Helix Server authentication database. Rather, the receiver configuration defines an authentication type of Basic and sets the password. The Helix Server administrator will need to supply you with the password to use.

Note: Optionally, the receiver can require no authentication. In this case, you leave the password field in RealProducer blank. Unsecured transmission should be used only if RealProducer and Helix Server are on the same local network and a firewall blocks attempts by encoders outside the firewall to reach Helix Server.

• Both RealProducer and the receiver need to define the same range of ports on Helix Server used for stream data. Default ports for both machines are 30001 to 30020, but you may need to change this range depending on the receiver definition. When the broadcast begins, RealProducer and Helix Server negotiate which ports in this range to use.

Tip: If you use the UDP transport, ensure that any firewalls between RealProducer and Helix Server allow UDP data sent to Helix Server on the ports in the defined range. If you are broadcasting through a firewall performing network address translation (NAT), you may need to set the RealProducer listen address to the IP address of the firewall or the value 0.0.0.0. See "Listen Address".

• The Helix Server receiver definition must specify the RealProducer IP address as the transmitter source, and indicate whether TCP or UDP is used. RealProducer must specify the same protocol in its server destination.
• Because this broadcast method does not provide feedback from Helix Server, there is no way to verify from RealProducer that the server has received the stream. Helix Server has a monitor that indicates encoder connections, however.
• If you want to archive or split the broadcast on Helix Server, you may need to apply archiving or splitting rules. This requires that the Helix Server administrator define the rules for a specific virtual path that precedes the stream name, as in news/live.rm. For background, refer to "Virtual Paths".
• If you plan to use redundant encoders, verify the stream delimiter expected by Helix Server. This is typically a period, as in live.rm.1 and live.rm.2. For more on this topic, see "Encoder Redundancy".
• The URL for the broadcast varies depending on the Helix Server features, such as viewer authentication, that you use. The section "Standard URL for a Push Broadcast" explains the basic URL format.
• Depending on the Helix Server logging parameters and the method it uses to broadcast the stream to RealPlayer viewers, broadcast statistics (such as the total number of viewers and how long each viewer watched) may be recorded in the server log files.

Defining a Password-Only Server Destination

This section explains how to define a password-only broadcast on RealProducer. You can create the server destination anytime before the broadcast, and can save the settings to a template for future use. You'll need information about the Helix Server receiver configuration:

• Helix Server IP address or DNS name
• receiver port range
• UDP or TCP transport
• server log-in password defined in the receiver configuration

To define a password-only server destination:

1. If you have multiple jobs open, click the appropriate job file name in the job manager.
2. Select File>Add Server Destination to display the server destination dialog. Or, click the server icon in the destinations area.
3. Enter a description of the server in the Destination Name field. This is for your reference only and does not affect the broadcast. If you save the destination as a template, this entry becomes the name of the template in the graphical application, as well as the file name of the server destination file.
4. In the Stream Name field, enter a name for the broadcast stream. This name resembles a clip name and should use the appropriate extension, either .rm for a constant bit rate stream or .rmvb for a variable bit rate stream. This name appears in the broadcast URL.

The stream name can include uppercase or lowercase letters, numbers, an underscore (_), and a dash (-). Spaces are not allowed. If you are using encoder redundancy, include the appropriate stream delimiter and a unique number for this encoder:

live.rm.2

5. From the Broadcast Method pull-down list, select Push, Password-Only Login (Helix Server).
6. For Server Address, enter the IP address or DNS name of the Helix Server used for the broadcast, such as 207.188.7.176 or helixserver.example.com.
7. The optional Path field specifies a virtual path that can be used for archiving or splitting on Helix Server. Use a simple name followed by a forward slash, such as news/.
8. For Port Range, indicate the range of ports on Helix Server where RealProducer sends the broadcast packets (either TCP or UDP). RealProducer and Helix Server negotiate the actual ports to use once the broadcast begins. The default range is 30001 to 30020.
9. In the Password field, enter the password set in the Helix Server receiver definition. The broadcast connection fails if the value is incorrect. If you are saving the destination as a template, you can click Remember password to store the password in the job file or server template file.

Warning! The password is saved as plain text in the job file or the server template. If you save the password, be sure that you maintain appropriate security on these files.

10. Under Transport, click the radio button for UDP or TCP to select the protocol used for the broadcast stream. UDP is preferred, but may be blocked by firewalls. See "Broadcast Transport Protocols" for descriptions of TCP and UDP.
11. You may want to set the advanced broadcast options by clicking the Advanced Options button. See "Changing Advanced Push Broadcast Parameters" for more information.
12. If you want to save the server destination as a template, click the Templates button and select Save as Template. You can then use this server destination for future broadcasts, as described in "Working with Server Templates".
13. Click OK to save the server destination. The destination appears in the destinations section of the RealProducer main window. You can right-click the destination name to edit or delete the destination.

Starting and Stopping a Password-Only Broadcast

When you have completed the server destination and have defined the live input as described in "Using Live Audio or Video as the Input", you can start the broadcast by clicking the Encode button. RealProducer immediately begins to encode the live input, sending the broadcast stream to Helix Server.

The password-based broadcast method automatically reconnects a dropped broadcast stream. Because it maintains no monitoring connection with Helix Server, however, RealProducer does not receive notice if Helix Server stops the broadcast. You can terminate the broadcast from RealProducer by clicking the Stop button.

Multicasting a Live Stream

In a multicast, RealProducer Plus can deliver the same broadcast stream to any number of Helix Servers without increasing its outgoing bandwidth. In non- multicast delivery (multiple server destinations with password-only broadcasting, for example), each server receives a separate stream, adding to RealProducer's bandwidth requirement. The following figure illustrates multicasting, which is available with Helix Server version 9 and later. Multicasting is not available with RealProducer Basic.

Multicast Push

Multicasting requires that your RealProducer, Helix Servers, and all network equipment such as routers be multicast-enabled, which is often possible on a local area network (LAN). Multicasting may not be possible if RealProducer or any of the Helix Servers needs to communicate to another broadcast component across the Internet. Confer with your network administrator and Helix Server administrator to determine if multicasting is available.

Tip: Multicast broadcasting can also be used for broadcasting across a one-way satellite network where two-way connections are not possible.

Preparing Helix Server for a Multicast

In a multicast, RealProducer acts as a transmitter and the Helix Servers function as receivers in a splitting arrangement. This configuration requires coordinated set-up on both ends. The chapter on transmitters and receivers in Helix Server Administration Guide explains splitting, and shows how to set up each server as a receiver. Before configuring a multicast, confer with the server administrator on the following issues:

• To be configured as a multicast receiver, each Helix Server receiver must be licensed for broadcast distribution. Clicking the About link in Helix Administrator displays the Helix Server licensing information.
• A multicast requires the use of a continuous range of multicast addresses on your network. These addresses are in the range 224.0.0.0 to 239.255.255.255.
• To connect to the Helix Server receivers, RealProducer transmits a password. Unlike with account-based broadcasts, this password is not defined in the Helix Server authentication database. Rather, the receiver configurations define an authentication type of Basic and set the password. The Helix Server administrator will need to supply you with the password to use.

Note: Optionally, the receivers can require no authentication. In this case, you leave the password field on RealProducer blank. Unsecured transmission should be used only if RealProducer and the Helix Servers are on the same local network and a firewall blocks attempts by encoders outside the firewall to reach the Helix Server receivers.

• Both RealProducer and the Helix Servers define the same range of ports on the receivers used for stream data. Default ports are 30001 to 30020, but you may need to change this range depending on the receiver definitions. When the broadcast begins, RealProducer and the Helix Server receivers negotiate which ports to use.

Note: Ensure that any firewalls between RealProducer and Helix Server allow multicast, UDP data sent to the Helix Servers on the ports in the defined range.

• The receiver definition on each Helix Server defines the RealProducer IP address as the transmitter source, and must specify that udp/multicast is used as the transport.
• If you want to archive or split the broadcast on Helix Server, you may need to apply archiving or splitting rules. This requires that the Helix Server administrator define the rules for a specific virtual path that precedes the stream name, as in news/live.rm. For background, refer to "Virtual Paths".
• If you plan to use redundant encoders, verify the stream delimiter expected by Helix Server. This is typically a period, as in live.rm.1 and live.rm.2. For more on this topic, see "Encoder Redundancy".
• The URL for the multicast varies depending on the Helix Server features, such as viewer authentication, that you use. The section "Standard URL for a Push Broadcast" explains the basic URL format.
• Depending on the Helix Server logging parameters and the method it uses to broadcast the stream to RealPlayer viewers, broadcast statistics (such as the total number of viewers and how long each viewer watched) may be recorded in the server log files.

Defining a Multicast Server Destination

This section explains how to define a multicast server destination on RealProducer. You can create the server destination anytime before the multicast, and can save the settings to a template for future use. You'll need the following information about the Helix Server receivers and network multicast configuration:

• multicast address
• port ranges on the receivers
• password on the receivers

To define a multicast server destination:

1. If you have multiple jobs open, click the appropriate job file name in the job manager.
2. Select File>Add Server Destination to display the server destination dialog. Or, click the server icon in the destinations area.
3. Enter a description of the server in the Destination Name field. This is for your reference only and does not affect the broadcast. If you save the destination as a template, this entry becomes the name of the template in the graphical application, as well as the file name of the server destination file.
4. In the Stream Name field, enter a name for the broadcast stream. This name resembles a clip name and should use the appropriate extension, either .rm for a constant bit rate stream or .rmvb for a variable bit rate stream. This name appears in the broadcast URL.

The stream name can include uppercase or lowercase letters, numbers, an underscore (_), and a dash (-). Spaces are not allowed. If you are using encoder redundancy, include the appropriate stream delimiter and a unique number for this encoder:

live.rm.2

5. From the Broadcast Method pull-down list, select Push, Multicast (Helix Server).
6. For Multicast Address, enter the multicast address for the broadcast stream. It must be in the range 224.0.0.0 to 239.255.255.255.
7. The optional Path field specifies a virtual path that can be used for archiving or splitting on Helix Server. Use a simple name followed by a forward slash, such as news/.
8. For Port Range, indicate the range of ports on the Helix Server receivers where the broadcast packets will be sent. RealProducer and Helix Server negotiate the actual ports to use once the broadcast begins. The default range is 30001 to 30020.
9. In the Password field, enter the password defined in each Helix Server receiver definition. The broadcast connection fails if the value is incorrect. If you are saving the destination as a template, you can click Remember password to store the password in the job file or server template file.

Warning! The password is saved as plain text in the job file or the server template. If you save the password, be sure that you maintain appropriate security on these files.

10. You may want to set the advanced broadcast options by clicking the Advanced Options button. See "Changing Advanced Push Broadcast Parameters" for more information.
11. If you want to save the destination as a template, click the Templates button and select Save as Template. You can then use this destination for future multicasts, as described in "Working with Server Templates".
12. Click OK to save the server destination. The destination appears in the destinations section of the RealProducer main window. You can right-click the destination name to edit or delete the destination.

Starting and Stopping a Multicast

When you have completed the server destination and have defined the live input as described in "Using Live Audio or Video as the Input", you can start the multicast by clicking the Encode button. RealProducer immediately begins to encode the live input, sending the broadcast stream to Helix Server.

A multicast automatically reconnects a dropped broadcast stream based on the metadata resend interval. Because it maintains no monitoring connection with the Helix Server receivers, however, RealProducer does not receive notice if the receivers stop the broadcast. You can terminate the broadcast from RealProducer by clicking the Stop button.

Changing Advanced Push Broadcast Parameters

In the Server Destination dialog, clicking the Advanced Options button displays a dialog in which you can configure the advanced settings for an account- based, password-only, or multicast push broadcast. These settings primarily affect how RealProducer attempts to reconnect to Helix Server if the broadcast stream is dropped, and how it protects the broadcast stream against lost data. You may want to leave these options set to their default values at first, modifying them only if you experience disconnects or lost data between RealProducer and Helix Server.

Note: No advanced options are available for legacy push broadcasting. For pull broadcasting, Helix Server defines the error correction and metadata rates. You can set a single advanced pull broadcasting parameter as described in "Defining a Pull Broadcast Server Destination".

TCP Reconnect

The TCP reconnection option is on by default. It affects the reconnection method for account-based broadcasts, which use a TCP monitoring channel. It also controls the reconnection method for password-only broadcasting if you have chosen TCP rather than UDP as the broadcast protocol. In the server definition file, the enableTCPReconnect property enables TCP reconnection.

The TCP reconnection interval sets the number of seconds that RealProducer waits before attempting to reconnect to Helix Server. The interval period begins when the operating system terminates the TCP connection because it has received no response from Helix Server. In the graphical application, you set this value in the Time between attempts field. In the server destination file, the TCPReconnectInterval property sets the value. Choose a value in seconds of 1 second or higher. A value of 0 is not valid. The default value is 10.

Metadata Resend Interval

The metadata resend interval affects how RealProducer and Helix Server re- establish a dropped broadcast stream in password-only and multicast broadcasts that use UDP as the transport. When RealProducer communicates to Helix Server solely through UDP, it does not receive feedback from the server and therefore cannot know if a broadcast stream has been dropped.

To protect against stream loss, RealProducer periodically encodes metadata into the broadcast stream. This provides the information that Helix Server needs to restart the stream, such as the stream name and the receiver password. Through the graphical application's Metadata resend interval field, or the server destination file's metadataResendInterval property, you specify how frequently RealProducer encodes metadata into the stream. This value determines the approximate, maximum time that viewers may need to wait for RealPlayer to reconnect to a dropped broadcast. The default is 30 seconds.

Note: The metadata resend interval has no effect on password- only broadcasts that use TCP transport. For these broadcasts, as well as for account-based broadcasts, the TCP reconnection values described in "TCP Reconnect" control the reconnection characteristics.

Statistics Update Interval

The statistics update interval determines how frequently Helix Server sends statistics reports to RealProducer during an account-based broadcast. It is not used with any other broadcast method. Set a value in seconds in the graphical application's Server statistics update... field or through the server destination file's statisticsUpdateInterval property. The default value is 10 seconds.

Packet Resend Requests and Listen Address

If Helix Server does not receive broadcast packets, it first attempts to reconstruct the broadcast data using the forward error correction packets, as described in "Forward Error Correction". If that fails, it can request RealProducer to resend the packets. There is no guarantee, however, that RealProducer will still have the packets buffered or that they will arrive in time to be useful for the broadcast. The resend feature functions with account- based and password-only broadcasts that use the UDP transport. It is ignored for broadcasts that use a TCP transport, as well as multicasts.

Packet Resends

The packet resend feature is turned on by default. Because the resend requests increase network overhead slightly, you may want to turn the resend feature off to keep tight control over network bandwidth use. To do so, uncheck the packet resend option in the graphical application, or set a value of False for the allowResends property in the server destination file.

Note: The Helix Server receiver configuration can turn off the feature for making resend requests. In this case, the RealProducer setting has no effect because the server will never make these requests.

Listen Address

The listen address sets the IP address that RealProducer uses to listen for packet resend requests from Helix Server. If your RealProducer machine has multiple IP addresses, choose an IP address from the graphical applicatino's Listen address drop-down list, or enter the IP address manually. In the server destination file, add the IP address as the value of the listenAddress property.

Tip: If you are broadcasting through a firewall performing network address translation (NAT), set the listen address to the IP address of the firewall or the value 0.0.0.0. The 0.0.0.0 value tells Helix Server to allow a RealProducer connection from any IP address. The connection still requires the valid password, however.

Forward Error Correction

When forward error correction (FEC) is used, RealProducer adds error correction packets to the broadcast stream. If packets containing broadcast data are lost, Helix Server can often reconstruct the data using the error correction packets. You can include forward error correction with broadcasts that use the UDP transport. The setting is ignored for any broadcast that uses TCP for data transport.

If you use forward error correction, the value set in the graphical application's Partial stream redundancy field or through the server destination file's fecPercent field indicates the percentage of the broadcast stream dedicated to forward error correction. The greater the value, the higher the packet loss protection and the greater the bandwidth needs for the stream. A standard value of 20 percent means that one in five packets is for error correction. The stream also uses 20 percent more bandwidth than if error correction were turned off.

Note: Using FEC increases the bandwidth only for the stream between RealProducer and Helix Server. It does not affect the bandwidth of the broadcast streams delivered to RealPlayer viewers by Helix Server.

Tip: Forward error correction is most useful when sending a broadcast stream over a lossy network such as the Internet. If your RealProducer and Helix Server are on the same local area network, you may not need to use any error correction.

For More Information: If the packet reconstruction fails, Helix Server may request the lost packets to be sent again, as described in "Packet Resend Requests and Listen Address".

Redundant Stream Protection

You can turn FEC protection all the way up to 100%, effectively creating a redundant stream that provides maximum protection against packet loss. This doubles the outgoing bandwidth required for the broadcast stream, however. To do this through the graphical application, click the Full stream redundancy radio button. If you are editing the server destination file manually, set the value of the fecPercent property to 100.

When you use full stream redundancy, you can set an offset in seconds between each packet and its redundant packet. This reduces the chance that both packets will be lost. For example, an offset value of 2 means that after it transmits a certain packet to Helix Server, RealProducer waits two seconds before transmitting the redundant packet. To set this offset, enter a value in seconds in the graphical application's Redundant packet latency field. In the server destination file, the fecOffset property controls this setting.

Note: Implementing packet redundancy is not the same as using redundant RealProducers, which is described in "Encoder Redundancy". Packet redundancy protects against losses due to network conditions, but it does not protect against the failure of the encoding process as does encoder redundancy.

FEC Rates and Receiver Buffering

When you use forward error correction, the Helix Server administrator may need to increase the amount of time that the receiver buffers the broadcast stream. If an FEC packet arrives after the server broadcasts the portion of the stream that the FEC packet corrects, the packet is useless. The administrator may need to change the buffering whether you use partial or full stream redundancy:

• If you use full stream redundancy, Helix Server must buffer the stream at least as long as the redundant packet offset value. For example, if RealProducer transmits redundant stream packets five seconds after the initial stream packets, the Helix Server receiver needs to buffer the stream for a minimum of five seconds.
• When you use partial stream redundancy, broadcasting low-bandwidth RealVideo streams with an error correction rate lower than 20 percent may require raising the receiver buffering time. The chapter on transmitters and receivers in Helix Server Administration Guide explains how to set the receiver buffering based on the transmitter FEC rate.

Multicast 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 in the Multicast time to live field or the server destination file's multicastTTL property. 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.

Setting up a Legacy Broadcast

The legacy push method is similar to the account-based push method. It does not use a monitoring connection to provide server feedback and statistics, however, and is not as robust a broadcast method as account-based push. Use this broadcast method only when sending a broadcast stream to a server that predates Helix Server version 9, such as RealSystem Server G2, 7, or 8. You cannot broadcast variable bit rate (VBR) streams using the legacy push method.

Preparing RealSystem Server for Legacy Broadcasting

RealSystem Server requires minimal configuration to receive and distribute an legacy broadcast. Confer with the server administrator on the following issues:

• RealProducer requires a valid user name and password. These values are defined in the RealSystem Server authentication database under the SecureEncoder realm.

Tip: If you are the RealSystem Server administrator, you can connect using the user name and password for RealSystem Server Administrator. For greater security, however, define a different user name and password for RealProducer.

• RealSystem Server defines a port that it uses to listen for incoming broadcasts. This is port 4040 by default, but may be changed by the server administrator. RealProducer must define the same port in its server destination.
• If you want to archive or split the broadcast on RealSystem Server, you may need to apply archiving or splitting rules. This requires that the RealSystem Server administrator define the rules for a specific virtual path that precedes the stream name, as in news/live.rm. For background, refer to "Virtual Paths".
• The URL for the broadcast varies depending on the RealSystem Server features, such as viewer authentication, that you use. The section "Standard URL for a Push Broadcast" explains the basic URL format.
• Depending on the RealSystem Server logging parameters and the method it uses to broadcast the stream to RealPlayer viewers, broadcast statistics (such as the total number of viewers and how long each viewer watched) may be recorded in the server log files.

Defining a Legacy Broadcast Server Destination

This section explains how to define the legacy broadcast on RealProducer. You can create the server destination anytime before the broadcast, and can save the settings to a template for future use. You'll need the following information about RealSystem Server:

• IP address or DNS name
• listen port number
• encoder log-in user name defined in the SecureEncoder realm of the authentication database
• valid password for the user name

To set up a legacy server destination:

1. If you have multiple jobs open, click the appropriate job file name in the job manager.
2. Select File>Add Server Destination to display the server destination dialog. Or, click the server icon in the destinations area.
3. Enter a description of the server in the Destination Name field. This is for your reference only and does not affect the broadcast. If you save the destination as a template, this entry becomes the name of the template in the graphical application, as well as the file name of the server destination file.
4. In the Stream Name field, enter a name for the broadcast stream. This name resembles a clip name and should use the appropriate extension, either .rm for a constant bit rate stream or .rmvb for a variable bit rate stream. This name appears in the broadcast URL. It can include uppercase or lowercase letters, numbers, an underscore (_), and a dash (-). Spaces are not allowed.
5. From the Broadcast Method pull-down list, select Legacy Push, (8.x, 7.x, G2).
6. For Server Address, enter the IP address or DNS name of the RealSystem Server used for the broadcast, such as 207.188.7.176 or helixserver.example.com.
7. The optional Path field specifies a virtual path that can be used for archiving or splitting on RealSystem Server. Use a simple name followed by a forward slash, such as news/.
8. For Port, specify the listen port on RealSystem Server. This is typically 4040.
9. In the Username and Password fields, enter a valid encoder user name and password defined in RealSystem Server's authentication database. The broadcast connection fails if either value is incorrect. If you are saving the destination as a template, you can click Remember password to store the user name and password in the job file or server template file.

Warning! The password is saved as plain text in the job file or the server template. If you save the password, be sure that you maintain appropriate security on these files.

10. Under Transport, click the radio button for UDP or TCP to select the protocol used with the broadcast stream. UDP is preferred, but may be blocked by firewalls. See "Broadcast Transport Protocols" for descriptions of TCP and UDP.
11. If you want to save the server destination as a template, click the Templates button and select Save as Template. You can then use this server destination for future broadcasts, as described in "Working with Server Templates".
12. Click OK to save the server destination. The destination appears in the destinations section of the RealProducer main window. You can right-click the destination name to edit or delete the destination.

Starting and Stopping a Legacy Broadcast

When you have completed the server destination and have defined the live input as described in "Using Live Audio or Video as the Input", you can start the broadcast by clicking the Encode button. RealProducer immediately begins to encode the live input, sending the broadcast stream to RealSystem Server.

Because it maintains no monitoring connection with RealSystem Server, RealProducer receives no notice of a dropped stream. The legacy broadcast method does not automatically reconnect a dropped broadcast stream. If the stream is dropped, you must restart the encoding and broadcast process. You can terminate the broadcast from RealProducer by clicking the Stop button.

Running a Pull Broadcast

In pull broadcasting, RealProducer begins to generate broadcast packets as soon as you start the encoding. However, it does not deliver the broadcast stream until Helix Server requests the stream, which occurs when the first RealPlayer user requests the broadcast. Pull broadcasting thereby saves bandwidth between RealProducer and Helix Server when no one is viewing the broadcast. This broadcast method allows you to send a stream to Helix Server version 9 or later.

For More Information: See "Running a Pull Broadcast" for set- up instructions.

Advantages of Pull Broadcasting

Pull broadcasting conserves bandwidth between RealProducer and Helix Server when a broadcast stream is not needed. This is useful in many cases, such as the following:

• online radio stations

You might use multiple instances of RealProducer to encode multiple streams for different online radio stations. Using pull broadcasting, you send to Helix Server only the streams for the stations that listeners have requested.

• server redundancy

Helix Server can provide server redundancy by sending each RealPlayer a list of alternate servers to contact in case their connection to the primary server fails. If you use pull broadcasting, a backup server receives the broadcast stream only if a connection between a RealPlayer and a primary server is lost.

For More Information: See the chapter on multiple servers in Helix Server Administration Guide for more about redundancy servers.

Disadvantages of Pull Broadcasting

Because a pull broadcast does not begin until the first RealPlayer user requests the broadcast, the first viewer may experience a longer than normal delay as Helix Server contacts RealProducer to acquire the broadcast stream. After the server acquires the stream, however, the broadcast is queued on Helix Server and subsequent viewers experience no additional delay.

When you use pull splitting, you do not have control over how many Helix Servers pull the stream. Any server that knows the RealProducer address, stream name, and access password can request the stream. You therefore have less control over your outgoing RealProducer bandwidth than you do with push splitting, in which you define exactly which servers receive the stream.

Note: Each Helix Server that requests the broadcast receives a separate stream. Multicasting is not available with pull splitting.

Pull Broadcast Steps

The following figure illustrates the interaction between RealProducer, Helix Server, and RealPlayer in a pull broadcast.

Pull Broadcasting

1. RealProducer begins encoding live streaming media, but the output is not sent to Helix Server.
2. The first audience member requests the broadcast, typically by clicking a link in a Web page. This launches RealPlayer, which requests the broadcast stream from Helix Server.
3. Helix Server requests the broadcast stream from RealProducer, sending it information about the server address and ports to use. Once the connection is established, Helix Server sends "keep alive" requests as long as viewers are receiving the broadcast.
4. RealProducer sends the broadcast stream to Helix Server, terminating the stream when it receives no more keep alive messages.
5. Helix Server streams the broadcast to RealPlayer users.

Preparing Helix Server for Pull Broadcasting

In a pull broadcast, RealProducer acts as a transmitter and Helix Server functions as a pull-enabled receiver in a splitting arrangement. This requires coordinated set-up on both ends. The chapter on transmitters and receivers in Helix Server Administration Guide explains splitting, and shows how to set up the server as a pull-enabled receiver. Before running a pull broadcast, confer with the server administrator on the following issues:

• To be configured as a receiver, Helix Server must be licensed for broadcast distribution and pull-splitting. Clicking the About link in Helix Administrator displays the Helix Server licensing information.
• RealProducer requires that Helix Server transmit a valid password to pull the stream. This password is defined in the RealProducer server destination and the server receiver configuration.
• The Helix Server receiver defines a range of ports it uses to receive the stream data. Default ports are 30001 to 30020. When the broadcast begins, RealProducer and Helix Server negotiate which ports to use. For best results, ensure that any firewalls between RealProducer and Helix Server allow UDP data sent to Helix Server on the ports in the defined range.
• The Helix Server receiver definition specifies RealProducer as a transmitter source through its IP address, and indicates whether TCP or UDP is used.
• In a pull broadcast, the Helix Server receiver defines the error correction parameters used for the broadcast stream. These parameters should be set in the pull-enabling section of the receiver configuration.
• If you want to archive or split the broadcast on Helix Server, you may need to apply archiving or splitting rules. This requires that the Helix Server administrator define the rules for a specific virtual path that precedes the stream name, as in news/live.rm. For background, refer to "Virtual Paths".
• The URL for the broadcast varies depending on the Helix Server features, such as viewer authentication, that you use. The section "Standard URL for a Pull Broadcast" explains the basic URL format.
• Depending on the Helix Server logging parameters and the method it uses to broadcast the stream to RealPlayer viewers, broadcast statistics (such as the total number of viewers and how long each viewer watched) may be recorded in the server log files.

Defining a Pull Broadcast Server Destination

This section explains how to define a password-only broadcast on RealProducer. You can create the server destination anytime before the broadcast, and can save the settings to a template for future use.

To define a pull server destination:

1. If you have multiple jobs open, click the appropriate job file name in the job manager.
2. Select File>Add Server Destination to display the server destination dialog. Or, click the server icon in the destinations area.
3. Enter a description of the server in the Destination Name field. This is for your reference only and does not affect the broadcast. If you save the destination as a template, this entry becomes the name of the template in the graphical application, as well as the file name of the server destination file.
4. In the Stream Name field, enter a name for the broadcast stream. This name resembles a clip name and should use the appropriate extension, either .rm for a constant bit rate stream or .rmvb for a variable bit rate stream. The stream name can include uppercase or lowercase letters, numbers, an underscore (_), and a dash (-). Spaces are not allowed.
5. From the Broadcast Method pull-down list, select Pull (Helix Server).
6. For Local IP Address, select the IP address used by RealProducer to listen for pull requests. If your computer has just one IP address, that address is selected by default in the pull-down list. The Helix Server receive must specify this address as the transmitter address.
7. The optional Path field specifies a virtual path that can be used for archiving or splitting on Helix Server. Use a simple name followed by a forward slash, such as news/.
8. For Producer Listening Port, indicate the port on RealProducer that it uses to listen for pull requests from Helix Server. By default, this port is 3031, but you can use any available port up to 65535. Firewalls should allow TCP communications through the chosen port. RealProducer and Helix Server then negotiate the ports to use for the data transfer.
9. In the Password field, enter the password that the receiver must transmit to pull the broadcast. The broadcast connection fails if the receiver supplies the wrong value. If you are saving the destination as a template, you can click Remember password to store the password in the job file or server template file.

Warning! The password is saved as plain text in the job file or the server template. If you save the password, be sure that you maintain appropriate security on these files.

10. You may want to change the server timeout, which is the amount of time that RealProducer waits for a response from Helix Server before assuming that Helix Server has finished broadcasting. At this point, RealProducer shuts down the broadcast stream. It does not discontinue the broadcast stream, however. This allows other servers to pull the stream.

The timeout value is 30 seconds by default. You can raise the value if previous pull broadcasts have timed out while RealPlayer viewers were still receiving the broadcast. RealNetworks does not recommend that you lower the value. Do the following to set the value:

1. Click the Advanced Options button.
2. In the Server connection timeout field, set a new value in seconds.
3. Click OK.

11. If you want to save the server destination as a template, click the Templates button and select Save as Template. You can then use this server destination for future broadcasts, as described in "Working with Server Templates".
12. Click OK to save the server destination. The destination appears in the destinations section of the RealProducer main window. You can right-click the destination name to edit or delete the destination.

Starting and Stopping a Pull Broadcast

When you have completed the server destination and have defined the live input as described in "Using Live Audio or Video as the Input", you can start the encoding process by clicking the Encode button. RealProducer begins to encode the live input, but does not send the broadcast stream to a Helix Server until the stream is requested.

Helix Server typically re-requests a broadcast stream if it is inadvertently lost. During the broadcast, it periodically sends "keep alive" messages to RealProducer to indicate that it continues to need the stream. If the server notifies RealProducer that it no longer needs the stream, or the server connection times out, RealProducer stops transmitting the stream but does not stop the encoding process. This allows additional servers to pull the stream if necessary. You can terminate a broadcast stream and the encoding process by clicking the RealProducer Stop button.

Working with Server Templates

When you create a server destination, the server information is written to the job file if you save the job. Optionally, you can save the server definition as a separate server template. This allows you to share the server definition or add it quickly to any other broadcast job. RealProducer stores the server template as an XML-based text file in the servers directory under its main installation directory. Using RealProducer Plus, you can save any number of server templates. With RealProducer Basic, you can save one server template.

For More Information: Appendix D explains how to edit a server file manually.

Using a Server Template

To save a server template, create a server destination as described in one of the broadcast set-up sections in this chapter. Then save the server definition as a template by clicking the Templates button and choosing Save as Template. To use that template in another job, select File>Add Server Destination, click Templates, and choose the template from the list. If you make changes to the template, you can change the destination name and save the changes as a new template by clicking Templates and choosing Add to List.

Editing or Deleting a Server Template

You can edit any server template if you need to change it. These changes are recorded in the template and the active job, but not in any previous jobs that also used the server template. To update an older job, edit the job file manually. Or, open the job in the graphical application, and replace the server destination in the output with the revised server destination.

Server Templates

To edit a server template:

1. Select Edit>Server Templates to list all available templates.
2. Select a template from the list. This displays the template's settings in the right-hand side of the dialog.
3. You can then perform any of the following actions:

1. Edit the settings for the template as described in the various sections of this chapter.
2. Click the "duplicate" icon at the bottom of the template list to copy the selected template. Then, edit the settings fields. This allows you to create a similar template quickly.
3. Click the trash icon to delete the selected template.

4. Click Apply to save changes to the template. Click OK to exit the dialog and save any changes.

Broadcast URLs

The following sections provide a general guide to URLs used by RealPlayer viewers to play a broadcast. Confer with the Helix Server administrator about the actual URL to use, as URLs can vary from the standard forms described below for many reasons:

• An HTTP URL in a Web page includes a /ramgen/ mount point, whereas an RTSP URL in a Ram or SMIL file does not.
• The Helix Server administrator can change the mount point (typically /broadcast/, /encoder/, or /redundant/) used with any broadcast method.
• Using the splitting feature, the Helix Server administrator can route the broadcast stream to multiple receivers. This lengthens the broadcast URL, and the URL to the stream on each receiver will differ.
• Including features such as user name and password authentication for viewers adds additional mount points to the URL.
• The Helix Server administrator may shorten long broadcast URLs by substituting an alias for parts of the URL.

Standard URL for a Push Broadcast

For a basic push broadcast that the viewer accesses by clicking a link in a Web page, the URL looks like the following:

http://helixserver.example.com/ramgen/broadcast/news/live.rm

• The /ramgen/ mount point launches RealPlayer when the viewer clicks the link in a Web page. If the URL is in a Ram file (.ram or .rpm) or SMIL file (.smil), the /ramgen/ mount point is omitted and the protocol is rtsp://.
• The /broadcast/ mount point is the default mount point used by Helix Server for an account-based or password-only broadcast. For legacy broadcasts, the mount point is /encoder/. If redundant encoders are used with any broadcast method, the mount point is /redundant/.
• A virtual path such as news/ is optional. It is included in the URL only if RealProducer specifies this path along with the stream name.
• You define the stream name, shown as live.rm above, through the RealProducer server destination.

Note: If you use encoder redundancy, RealProducer defines delimiters in the stream name, such as .1 and .2. These delimiters are not included in the URL.

Standard URL for a Pull Broadcast

The URL to a pull broadcast is longer than a URL to a push broadcast because it includes information about both the Helix Server receiver and the RealProducer transmitter. The following example shows the general format for a basic pull broadcast that the viewer accesses by clicking a link in a Web page. For convenience, the example is displayed on two lines. The first line gives the receiver information. The second line supplies the transmitter parameters:

http://receiver.example.com/ramgen/broadcast/pull/
realproducer.example.com:3031/news/live.rm

• The /ramgen/ mount point launches RealPlayer when the viewer clicks the link in a Web page. If the URL is in a Ram file (.ram or .rpm) or SMIL file (.smil), the /ramgen/ mount point is omitted and the protocol is rtsp://.
• The /broadcast/ mount point is the default mount point used by Helix Server for a pull broadcast. Following the broadcast mount point is a path that indicates pull splitting is used, as in /pull/. The Helix Server receiver defines this path.
• The link's transmitter portion lists the RealProducer IP address or host name, along with its listen port, as in realproducer.example.com:3031.
• A virtual path such as news/ is optional. It is included in the URL only if RealProducer specifies this path along with the stream name.
• You define the stream name, shown as live.rm above, through the RealProducer server destination.

©2004 RealNetworks, Inc. For more information, visit RealNetworks Click here if the Table of Contents frame is not visible at the left side of your screen.