previous next

Chapter 7: Unicasts

A unicast is the simplest way to broadcast a live event to viewers. Helix Universal Server can unicast events in RealMedia, Windows Media, and QuickTime formats, as well as in a number of RTP-based formats. You can use live unicasting for audio and video feeds delivered on the Internet or private intranets.

Tip: See also Chapter 10 for information about delivering a prerecorded clip as if it were a live event. This is a good way to test broadcasting before streaming a live event.

Understanding Unicasts

Basic broadcasts are called unicasts because Helix Universal Server delivers a separate stream to each media player. An encoder such as Helix Producer encodes a real-time event in a streaming format. The encoder delivers the stream to Helix Universal Server, which then delivers the live stream to each media player, as shown in the following illustration. Viewers typically receive the broadcast by clicking a link in a Web page, just as they do for an on- demand clip. The link's format, though, instructs Helix Universal Server to deliver the live stream, rather than a prerecorded clip.

Unicasting

Unicasting

Licensing Limitations

Helix Universal Server can deliver multiple, simultaneous broadcasts in any combination of supported media formats, as long as the total number of players does not exceed the licensed maximum. On a Helix Universal Server licensed for 10,000 clients, for example, you can unicast the same live presentation in RealMedia format to 4,000 RealOne Players and in Windows Media format to 4,000 Windows Media Players. At the same time, you might unicast an entirely different live presentation to 2,000 QuickTime Players.

Bandwidth Constraints

In unicasting, each broadcast stream uses bandwidth, so you are also limited by Helix Universal Server's available, outgoing bandwidth. Unicasting from a single Helix Universal Server is generally suited, therefore, for light- to medium-volume broadcasts. For events with a large number of viewers, you can use splitting (see Chapter 9), multicasting (see Chapter 8), or a combination of the two, to deliver a large number of broadcast streams, or to conserve bandwidth.

Tip: If you broadcast to RealNetworks media players on a multicast-enabled intranet, set up back-channel multicasting as described in Chapter 8. Players can then connect to a unicast in multicast mode, which saves on network bandwidth. If a player cannot receive the multicast, it requests a unicast.

Broadcast Trial Runs

When you broadcast live content, you don't get a second chance. It's good practice to perform a trial run to ensure that the equipment works properly and that the broadcast results are what you expect. Because you can't edit a live broadcast the way you can a prerecorded file, it's important to set your audio levels and plan your video shots carefully in advance.

During both the trial run and the live broadcast, view the broadcast output with the appropriate media player. When the player connects, check that the buffering time does not exceed 15 seconds. Throughout the presentation, keep an eye on the broadcast quality. If you experience problems during your trial run, you may need to reduce the number of streams if you are using a multiple-stream technology such as SureStream. Or, you may need to run the encoder on a more powerful computer.

Live Unicasting Used with Other Features

Live unicasting works with all other Helix Universal Server features. There are some considerations for each feature, however, as described in the following sections.

Firewalls

Live broadcasts use standard streaming protocols, so highly restrictive firewalls may block broadcasts. Firewalls are described in Chapter 11.

Access Control and Authentication

Before any client is allowed to receive any broadcast, Helix Universal Server checks the client's IP address to see whether the client is allowed to receive a broadcast. If the address is acceptable, Helix Universal Server looks at the location of the file to see if it is in a secure location. If so, Helix Universal Server challenges the user (or media player) for identification. Once the client passes the tests, Helix Universal Server connects the client to the live broadcast.

For More Information: See Chapter 13 and the section "Securing Broadcasts" for more information on setting up authentication for live broadcasts.

ISP Hosting

Helix Universal Server's ISP hosting feature can host on-demand content only. It does not host any live content.

Monitoring

You can view all streams and connections to broadcasts through the Server Monitor in Helix Administrator. Chapter 18 has more information.

Logging

The access log records all client connections to live broadcasts. The error log records any errors encountered by clients. See Chapter 16 for details.

Archiving Broadcasts

Helix Universal Server is preconfigured to archive broadcasts that use the RealMedia or MP3 format. It does not archive other broadcast formats, such as MPEG-4, Windows Media, and QuickTime. Archived files function just like prerecorded clips, and you can stream them on demand immediately after they are recorded. Before you begin broadcasting with RealMedia or MP3, you may want to define archiving as described in this section.

Tip: Helix Producer can also archive a stream on its local computer as it delivers the stream to Helix Universal Server. You can create the archive on that machine, on Helix Universal Server, or both. Typically, though, the Helix Universal Server computer has more disk space for archiving.

Selectively Archiving Broadcasts

Helix Universal Server is preconfigured to archive broadcasts to its Archive subdirectory. You just have to turn the archiving feature on for the "*" rule as described below. However, you may also want to set up different archiving rules. This allows you to archive only some broadcasts, as well as create archive files for different broadcasts in different directories.

The key to selective archiving is the encoder source path. When you broadcast a live stream, you can define an optional path name through the encoder interface. For example, you might define an encoder source path such as news/, along with the stream name live.rm. The news/ source path does not correspond to an actual directory path on either the encoder or Helix Universal Server computer. It's just a name sent with the stream name that enables you to use various features, such as selective archiving rules.

You can set up any number of archiving rules. You might archive only the broadcasts that use certain source path names, for instance. Or, you can archive all broadcasts except those that use certain source path names. As well, you can archive all broadcasts, using the source path names only to indicate different archive directories. The following table shows possible combinations of using the general archiving rule, "*", along with two selective archiving rules that correspond to news/ and talk/ source paths.

Examples of Archiving Rules
Rule Setting Destination Result
* Enabled /Archive/ All broadcasts except those with the news/ and talk/ source paths are archived in the /Archive/ directory. Broadcasts using the news/ source path are archived under the /News/ mount point or directory, whereas those using the talk/ source path are archived under /Talk/.
/news Enabled /News/
/talk Enabled /Talk/
* Disabled (any) Only broadcasts using the news/ or talk/ source paths are archived. All archive files are created in the /Archive/ directory.
/news Enabled /Archive/
/talk Enabled /Archive/
* Enabled /Archive/ All broadcasts except those using the talk/ source path are archived. Archive files are created in the /Archive/ directory, unless they use the news/ source path. In that case, they are archived under /News/.
/news Enabled /News/
/talk Disabled (any)

Setting Up Archiving

Broadcast archiving is not turned on by default. The following procedure explains how to activate archiving, define new archiving rules, and set up archiving options.

To set up live archiving:

  1. In Helix Administrator, click Broadcasting>Live Archiving.
  2. Each entry in the Source Paths box sets up a different archiving rule. Helix Universal Server predefines the "*" rule, which automatically archives all broadcasts to the same directory. To archive all broadcasts, simply enable the "*" entry as described in the next step. To archive broadcasts selectively, create a new source path:
    1. In Source Paths, click the "+" icon to add a new path.
    2. Under Edit Source Path, enter the broadcast path name sent by Helix Producer. For more information, see "Selectively Archiving Broadcasts".

  3. From the Archiving list, select Enabled to activate the archiving rule selected in the Source Paths box.
  4. Tip: If you want to archive only selected broadcasts, be sure to choose Disabled for the "*" rule, and enable only the selective rules.

  5. In the Destination Path box, indicate where Helix Universal Server stores the archived files for the selected rule. Encase the text in forward slashes, as in /Archive/. Helix Universal Server matches the entry to one of the following elements, searching for a match in the following order:
  6. To create multiple archive files limited by size, enter the maximum size for each file in Megabytes in the Limit Archive Files By Size box. Archive files are numbered sequentially in the base file name. For example, if the broadcast stream is named live.rm, the first archive file is named live0.rm, the second is live1.rm and so on.
  7. Note: A number after the file extension indicates an earlier broadcast that used the same stream name as a later broadcast. See "Maintaining Archives for Repeated Broadcasts" for more information.

  8. To create multiple archive files limited by broadcast time, enter the appropriate time in the Limit Archive Files By Time boxes. To create a new archive file every 30 minutes during the broadcast, for example, enter 30 in the Minutes box. As with files limited by size, archive files limited by broadcast time are numbered sequentially.
  9. Tip: Generally, you limit archives by size or time. You can select both methods, however, to create archive files according to the first limit reached. For example, you can create a new archive file whenever the preceding file reaches 30 Megabytes in size, or has recorded 15 minutes of the broadcast, whichever comes first.

  10. The Bandwidth Negotiation pull-down applies only to legacy encoders that use RealServer 5-style bandwidth negotiation. It does not affect current broadcast methods described in this chapter. Ignore this option if you do not use the legacy encoders for RealServer 5 or earlier.
  11. When this option is set to On, Helix Universal Server creates an archive directory using the stream name, including the file extension, sent by the legacy encoder. It archives the different streams in this directory, naming them for the compression algorithm. If this option is set to Off, Helix Universal Server stores the first stream that arrives under the stream name, which should include the .rm extension. It does not archive the other streams.

    For More Information: See "Legacy Bandwidth Negotiation".

  12. Click Apply.

Maintaining Archives for Repeated Broadcasts

When you repeat a broadcast, such as a live news show rebroadcast each day, you can use the same stream name, and archive each broadcast in the same directory. In this case, Helix Universal Server automatically renames older archive files by appending a unique number after the file extension. For example, if the archive file dailynews.rm exists in the archive directory when Helix Universal Server begins to archive a new dailynews.rm stream, Helix Universal Server moves the existing archive to a name such as dailynews.rm.86400. The appended number is related to a timestamp, so larger numbers indicate newer files.

Streaming Archived Files

An archived broadcast file functions just like an on-demand clip, and you can stream it by writing links to it as described in Chapter 5. You can also use SLTA, which Chapter 10 describes, to rebroadcast archive files as if they were live events. It is easiest to stream the archive from the directory where you saved it, but you can also move it to a different directory. A Web page link to a RealMedia archive that resides in the default Archive directory looks like this:

http://helixserver.example.com/ramgen/Archive/concert.rm

If you saved several archive files for a single broadcast, streaming the entire event requires that you provide a Web page link to each archive. However, you can also list all archive files in order within a single Ram file to stream the entire archived broadcast. For more on Ram files, see "Using Metafiles".

Tip: When you list archives in order within a <seq> tag in a SMIL file, the sequence acts like a unified broadcast. That is, the RealOne Player timeline slider does not reset when each archive file begins to play. For more information, see the SMIL sequences chapter of Introduction to Streaming Media.

Using Broadcast Redundancy

When broadcasting any media format, you can specify one or more backup encoders. Each encoder delivers the same stream name marked with a unique delimiter, such as .1 or .2. When the encoders connect to Helix Universal Server to deliver their live event streams, they form a queue based on their connection order. Consider this example:

live.rm.2 connects first

live.rm.3 connects second

live.rm.1 connects third

Under normal circumstances all media players receive the stream live.rm, and have no knowledge of the encoder sending the stream. In the preceding example, live.rm originates as live.rm.2. If the encoder delivering live.rm.2 fails, media players reconnect to the next live.rm stream in the queue, which is live.rm.3. If live.rm.2 returns, it goes to the bottom of the queue. A subsequent failure of live.rm.3 causes media players to connect to live.rm.1, and so on.

Broadcast Redundancy

Broadcast Redundancy

Support for encoder redundancy is enabled automatically, and requires no Helix Universal Server setup. The section on broadcasting a certain media format explains how to implement redundancy for that media format. RealNetworks recommends that you read the following sections, however, to understand better how encoder redundancy works.

Tip: To provide optimal redundancy, each encoder should be as independent as possible. For example, use multiple video cameras connected to separate computers that use different power supplies and network connections.

Modifying Encoder Redundancy Settings

Helix Universal Server is preconfigured to support redundant encoders for all media types. The following procedure explains how to change overall encoder redundancy settings in case you want to modify how this feature works with any media encoder.

To modify encoder redundancy settings:

  1. Click Broadcasting>Broadcast Redundancy.
  2. If you want to turn off broadcast redundancy, choose Disabled from the Broadcast Redundancy pull-down list. Otherwise, leave this set to Enabled.
  3. The character specified in the Delimiter pull-down list separates the stream names from the source numbers. For example, the primary RealMedia stream might be live.rm.1, while the backup is live.rm.2. The period delimiter is recommended, because it is the most extensible character in UNIX shells. However, you can choose any one of the following:

    ^ (carat)
    ` (single quote)
    ~ (tilde)
  4. The Timeout box sets the number of seconds that Helix Universal Server waits for an interrupted stream to return before switching to a backup stream. The default value is 2, but you can set a range from 0 to 30.
  5. The Reconnect pull-down list specifies how viewers using RealOne Player and RealPlayer 8 receive the backup stream should the primary stream become unavailable. The default value Auto causes the media player to switch to the new stream automatically. Choosing Manual displays the message defined in the Error Message field, and requires users to click the Play button to switch to the new stream.
  6. Note: Viewers must reconnect manually, regardless of the setting in the Reconnect list if they are using a version of RealPlayer earlier than RealPlayer 8, receiving a broadcast over the older PNA protocol, or using any other media player, such as Windows Media Player or QuickTime Player.

  7. The Mount Point box defines the mount point to use in links to indicate that broadcast redundancy is used. The default value is /redundant/.
  8. The Error Message field holds the text of the message that appears if Reconnect is set to Manual. This message should tell users how to connect to the new stream. The default message is:
  9. Broadcast timed out; click Play button to restart.
    

  10. Click Apply to save the changes. You'll need to restart Helix Universal Server if you changed the mount point.

Using Broadcast Redundancy with Other Features

The following table explains how redundant broadcasting interacts with other Helix Universal Server features.

Broadcast Redundancy Used with Other Features
Other Features Notes
SLTA You can use redundant sources with SLTA.
Archiving Helix Universal Server archives the incoming source, but doesn't store the source number. If sources are live.rm.1 and live.rm.2, for example Helix Universal Server archives a file named live.rm, without the delimiter and number.
Splitting A transmitter that uses the redundant encoders feature sends out its streams just like any other live broadcast. To create a system with multiple layers of backups, you should configure multiple transmitters to name their broadcasts with the same file name, plus the delimiter and a unique number.
Multicasting Redundant live sources can be multicast, as with any other live content.
Access Control, Authentication Use access control and authentication the same as with any other live content.
Java Monitor Redundant sources are displayed like any other live broadcasts.
Reporting Just as in any other live broadcast, a record is created in the access log for any client that connects to a live broadcast originating from redundant sources. You can't determine which redundant source is in use, only that the redundancy feature is in use. See "GET Statements" to see how redundant sources appear in the access log.

Broadcasting RealMedia

To broadcast RealAudio or RealVideo, you use Helix Producer to capture and encode the live event. If you have an earlier version of RealProducer, such as RealProducer 8.5, you can continue to use it to deliver live streams, as described in "Encoding with an Older Version of RealProducer". The section "Setting Up Account-Based Broadcasting" explains how to use Helix Producer 9 in a mode that emulates broadcasts originating from earlier versions of RealProducer.

Tip: Helix Producer 9 introduces new methods for delivering live streams, called push mode and pull mode. In these methods, Helix Producer 9 acts like a Helix Universal Server transmitter in a splitting arrangement. These modes are more powerful than the connection methods described in the following sections. They require more setup, though, and are described in Chapter 9.

Broadcasting with SureStream

Using SureStream technology, you can broadcast RealMedia at multiple bandwidths using any encoder from RealProducer G2 to the latest version. In a SureStream broadcast, each RealPlayer selects an encoding appropriate for its connection speed. To reach multiple bandwidth audiences without using SureStream, you run separate Helix Producer encoders (typically on separate machines), broadcasting each stream under a different stream name.

Note that when you archive a live broadcast that uses SureStream, Helix Universal Server creates several temporary files that correspond to different SureStream streams. It merges these temporary files into the final archived file (or files) when the broadcast finishes. The merging time may take longer than the broadcast. Be sure not to stop Helix Universal Server or delete the temporary files before the merging completes.

For More Information: For more on archiving, see "Archiving Broadcasts".

Using SMIL in Broadcasts

You can use SMIL 1.0 or SMIL 2.0 to add prerecorded content to a live broadcast. Within a SMIL file, you treat a broadcast like any other clip, furnishing a URL that points RealOne Player to the live stream instead of an on-demand clip. You can assign broadcast streams to SMIL regions, and group a broadcast with on-demand clips using <seq> or <par> tags.

SMIL can deliver an on-demand RealPix slideshow along with live RealAudio, for example, when both are in a <par> group. It cannot synchronize the on- demand clip with the live stream, however. This is because the on-demand clip's timeline starts when the viewer requests the presentation, whereas the broadcast stream's timeline starts when the broadcast begins.

To illustrate this, suppose that viewer A requests the presentation 2 minutes after the broadcast begins, and viewer B requests it 4 minutes after the broadcast begins. At 10 minutes into the broadcast, both viewers hear the same audio, but viewer A's RealPix clip is at its 8-minute mark, whereas viewer B's clip is at its 6-minute mark. Hence the relationship between the two timelines varies for each viewer.

For More Information: For more on SMIL, see RealNetworks Production Guide.

Setting Up Account-Based Broadcasting

If you are a broadcasting beginner, you can use Helix Producer 9 in its account- based mode. This mode, which is a simplified subset of the newer push mode, emulates the broadcasting connection used in previous versions of RealProducer. Although not as robust as the full-fledged push mode, it requires little setup, so it provides a good introduction to broadcasting RealMedia.

When Helix Producer connects to Helix Universal Server in account-based mode, it uses an HTTP connection to Helix Universal Server to discover the best way to communicate. Because this connection is authenticated, Helix Producer needs a valid user name and password on Helix Universal Server. Helix Producer then sets up a data channel based on the most reliable network path it finds to Helix Universal Server.

Helix Producer 9 in Account-Based Mode

Helix Producer 9 in Account-Based Mode

For More Information: See "Encoder Validation" for information about setting up a user name and password to enable Helix Producer to connect to Helix Universal Server.

To set up account-based broadcasting:

  1. Click Broadcasting >RealNetworks Encoding. The necessary settings reside in the 9.0 Producer section.
  2. In the Port Range box, select the range of ports on Helix Universal Server where Helix Producer sends its live feed. Default values are 50001 to 50050. Two ports are required for each live feed, so the default values allow up to 25 simultaneous connections. You may need to change or limit the port range to work around firewall restrictions, which are described in Chapter 11.
  3. Helix Producer needs a valid user name and password to connect to Helix Universal Server. In the Authentication pull-down list, select the realm where you added user names and passwords for content creators. The default realm for Helix Producer is SecureRBSEncoder. The section "Managing Users and Passwords" describes realms and authentication.
  4. Click Apply to save the changes.
  5. Note: You don't define a mount point with account-based broadcasting. The predefined mount point used for all account-based broadcasts is /broadcast/.

Starting the Account-Based Broadcast

Helix Producer initiates an account-based broadcast by contacting Helix Universal Server and delivering the encoded stream. Helix Producer has a server connection wizard in which you select push broadcasting, then specify an account-based login. You need to supply the Helix Universal Server IP address, as well as a user name and password set up under Helix Universal Server authentication.

In Helix Producer, you designate a stream name, and can include a path if you want to archive the stream selectively. If you use multiple Helix Producers for broadcast redundancy, start each encoder at the same time (or as close as possible). Ensure that each stream has the same stream name, a delimiter (a period by default), and a unique stream integer, starting with 1. For example, your stream names might be the following:

primary stream: live.rm.1
backup stream: live.rm.2

Note: Even though each stream has a delimiter and unique integer after its stream name, the link to the broadcast uses just the common stream name (live.rm).

For More Information: See Helix Producer User's Guide for instructions on setting up the encoder for broadcasting. To create the broadcast URLs, refer to "Linking to Unicasts". The section "Using Broadcast Redundancy" explains the use of multiple encoders.

Encoding with an Older Version of RealProducer

Helix Universal Server supports broadcast connections from earlier RealNetworks encoders. Although you typically do not need to change any Helix Universal Server settings, follow one of the procedures below to ensure that your Helix Universal Server setup is correct.

To set up encoding with RealProducer G2 through 8.5:

  1. Click Broadcasting >RealNetworks Encoding. The necessary settings reside in the G2 to 8.5 Producer section.
  2. If you wish, you can change the Mount Point setting from the default /encoder/. Links to the broadcast include this mount point.
  3. The Port box sets the port on which Helix Universal Server listens for the live broadcast stream. If you change this value, be sure to give the new value to the person running RealProducer.
  4. The Timeout box sets the number of seconds that Helix Universal Server waits after a break in packet reception to shut down the connection and terminate the broadcast. The default value is 30 seconds.
  5. To validate the encoder connection, select the name of the appropriate realm from the Authentication box. The default realm for encoders is SecureEncoder. See "Encoder Validation" for information about creating encoder passwords.
  6. Click Apply to save the changes. You'll need to restart Helix Universal Server if you changed the mount point.

To use an encoder earlier than RealProducer G2:

  1. Click Broadcasting >RealNetworks Encoding.
  2. Click the Setup link at the top of the page.
  3. If you wish, you can change the Mount Point setting from the default /live/. Links to the broadcast include this mount point.
  4. The Port box sets the port on which Helix Universal Server listens for the live broadcast stream. If you change this value, be sure to give the new value to the person running RealProducer.
  5. In the Password box, enter the password the encoder supplies to Helix Universal Server. Passwords are optional, and must be defined through the authentication feature. See "Encoder Validation" for information about creating encoder passwords.
  6. Click Apply to save the changes. You'll need to restart Helix Universal Server if you changed the mount point.

Starting the Legacy Broadcast

In legacy broadcasting, RealProducer initiates the broadcast by contacting Helix Universal Server. You supply the Helix Universal Server IP address, listen port, and a user name and password (if required). You designate a stream name, and can include a path if you want to archive the stream selectively. Legacy broadcasts can also use a backup encoder, with the two encoders specifying number-delimited stream names, such as live.rm.1 and live.rm.2.

For More Information: See your RealProducer User's Guide for instructions on setting up the encoder for broadcasting. To set up broadcast URLs, see "Linking to Unicasts". The section "Using Broadcast Redundancy" explains the use of multiple encoders.

Broadcasting Windows Media

In a Windows Media broadcast, Helix Universal Server pulls a stream from Windows Media Encoder (version 7 recommended) over an HTTP connection, and delivers it to Windows Media Player clients over the MMS protocol. Helix Universal Server is preconfigured with support for the MMS, multiple bit rate (MBR) encoding, a Windows Media broadcast mount point, and an ASXGen mount point for launching Windows Media Player. Broadcasting in Windows Media format therefore requires little setup. Encoder redundancy is supported, but archiving is not.

To set up a Windows Media broadcast:

  1. Click Broadcasting> Windows Media Encoding.
  2. The Mount Point box lists the default Windows Media mount point of /wmtencoder/, which will appear in broadcast URLs. RealNetworks recommends that you use this value. You need to restart Helix Universal Server if you change the mount point value. You can define only one Windows Media broadcast mount point on each Helix Universal Server, but you can deliver multiple broadcasts simultaneously through this single mount point.
  3. In the Windows Media Sources list, click the "+" icon and edit the default text that appears in the Source Description box. Your entry should describe the Windows Media Encoder sending the stream. It is for your reference only, and is not included in URLs.
  4. In the Host field, enter the IP address or host name of the Windows Media Encoder.
  5. In the Port field, enter the HTTP Port of the Windows Media Encoder.
  6. In the Stream Name field, enter a name for the Windows Media stream. The stream name, which appears in links to the broadcast, typically uses the same format as prerecorded clips, including a short base name, along with the standard file extension, whether .asf, .wmv, or .wma. Optionally, you can precede the stream name with a path:
  7. news/live.wmv
    

    The path does not correspond to a physical path. Instead, you can use this when splitting the stream to direct it to some receivers but not others. For more information, see "Multiple Splitting Definitions".

  8. Repeat the preceding steps to set up another Windows Media broadcast, or to define a redundant encoder for the same broadcast. To use encoder redundancy, enter a stream delimiter after the extension, as in live.wmv.1. The backup stream should have the same stream name, but use .2 as its delimiter.
  9. For More Information: See "Using Broadcast Redundancy".

  10. Helix Universal Server is ready to broadcast when you click Apply. It pulls the stream from Windows Media Encoder only on the first request from a Windows Media Player, however, so you can define encoders on this page before delivering broadcasts.
  11. Note: Helix Universal Server will broadcast the stream from the specified encoder as long as the full source is defined. To disable a broadcast after it completes, delete the source name, or clear the Stream Name field.

    For More Information: Consult your Windows Media Encoder documentation for information about setting up the live encoding process. To set up broadcast URLs, see "Linking to Unicasts".

Broadcasting QuickTime, MPEG, and RTP-Based Media

Helix Universal Server can broadcast to the QuickTime Player streams that originate from the Sorenson Broadcaster, Apple's Darwin Server, or Playlist Broadcaster. QuickTime broadcasting is based on the RTSP control protocol and the RTP packet format. Helix Universal Server's support for RTSP and RTP enable it to broadcast other RTP-based media formats as well, including MP3 and MPEG-4. Helix Universal Server is preconfigured to support QuickTime and RTP-based media. You typically do not need to modify Helix Universal Server to broadcast these formats.

For More Information: For more on the RTP format itself, see "Packet Formats".

Using SDP Files with Helix Universal Server

The heart of RTP-based streaming is the Session Description Protocol (SDP) file. The encoder produces this file, which provides general information about the encoded stream. The file is then delivered, usually by FTP, to a specific Helix Universal Server directory. Typically, Helix Universal Server pulls the stream from the encoder, based on information in the SDP file, when the first media player requests the broadcast. However, Helix Universal Server can also scan its SDP directory at regular intervals, cueing the broadcast when an SDP file arrives.

It's important to understand that media players do not receive the SDP file, even though the URL to the broadcast appears to link to the SDP file. The request URL uses the SDP file name to identify the broadcast. However, the request comes through a preconfigured Helix Universal Server mount point. This causes Helix Universal Server to send the media player information about how to connect to the broadcast stream on Helix Universal Server, rather than the original stream sent by the encoder.

Changing RTP Broadcast Procedures

To deliver an RTP-encoded stream, you typically do not need to change any Helix Universal Server settings. You may want Helix Universal Server to monitor for the arrival of the SDP file, though, so that it can cue the broadcast and speed the initial broadcast delivery. The following procedure explains how to modify broadcast settings.

To modify a QuickTime or RTP-based broadcast:

  1. Click Broadcasting>QT & RTP Encoding.
  2. Two encoder descriptions are already predefined, one for QuickTime broadcasting and one for general RTP-based broadcasting. You can add another description by clicking the "+" icon in the Encoders section, then editing the name in the Encoder Description box.
  3. Tip: The two separate descriptions are for convenience. You can broadcast QuickTime using the general RTP mount point, or broadcast any RTP-based format using the QuickTime mount point. As well, you can create additional mount points.

  4. In the Mount Point box, define the mount point used in the broadcast URL. By default, /qtencoder/ and /rtpencoder/ are predefined. For background on mount points, see "Mount Points".
  5. The Base Mount Point box defines a mount point or directory name that corresponds to the directory on Helix Universal Server where the encoder places the SDP file. The predefined entries are subdirectories under the main Content directory.
  6. Note: If you indicate a different subdirectory or mount point, ensure that the specified directory exists before you restart Helix Universal Server.

  7. For Connection Timeout, define the time in seconds that Helix Universal Server waits for the encoder to respond with a stream when the first media player requests the broadcast. If the timeout value expires before the encoder responds, Helix Universal Server terminates the broadcast. The default value is 10 seconds. You can set the value higher if you expect a higher initial latency.
  8. The End of Session Timeout box defines the time in seconds that Helix Universal Server waits for the encoder to respond if it has stopped sending data but has not indicated that the broadcast has stopped. If the timeout value expires before the encoder responds, Helix Universal Server terminates the broadcast. The default value is 10 seconds. RealNetworks does not recommend setting this value lower.
  9. By default, the Enable SDP Directory Scan pull-down is set to No, which causes Helix Universal Server to pull the stream from the encoder when the first client requests the broadcast. If you change this to Yes, Helix Universal Server scans the SDP file directory at regular intervals, connecting to the encoder and cueing the broadcast when it finds a new SDP file. Hence, Helix Universal Server prepares the stream on the arrival of the SDP file, helping to speed the delivery of the broadcast.
  10. Tip: Because cueing the broadcast consumes resources even if no clients request the broadcast, RealNetworks recommends that you enable this feature only if you anticipate that the encoder will deliver the SDP file shortly before the first client requests the stream.

  11. If you set Helix Universal Server to scan for SDP files, enter in the SDP Directory Scan Interval box the frequency in seconds that Helix Universal Server scans the SDP directory. The default is 5 seconds.
  12. Click Apply to save the changes. Any changes in this page require a Helix Universal Server restart.

Starting the RTP-Based Broadcast

As it prepares to broadcast, the QuickTime or RTP-based encoder creates an SDP file that identifies the encoded stream. The broadcaster then delivers the SDP file to Helix Universal Server's SDP directory. The predefined SDP directories for QuickTime and RTP-based broadcasts, respectively, are at the following paths in a default installation of Helix Universal Server on Windows:

C:\Program Files\Real\Helix Server\Content\qtencodersdp
C:\Program Files\Real\Helix Server\Content\rtpencodersdp

On UNIX, the directories are under the Content directory of the main installation directory, as in these examples:

/usr/local/Real/HelixServer/Content/qtencodersdp
/usr/local/Real/HelixServer/Content/rtpencodersdp

Keep in mind that the broadcast request URL does not list the actual directory that contains the SDP file. Instead, it uses the appropriate mount point, which is typically either /qtencoder/ or /rtpencoder/. For examples of this, see "QuickTime and RTP-Based Player Examples".

Note: You can create subdirectories for different SDP files if you want to split different broadcasts in different ways, as described in "Multiple Splitting Definitions". The subdirectory name must then precede the SDP file name in the request URL

Linking to Unicasts

Links to live broadcasts look like links to on-demand clips, but use the broadcast mount points to direct the clients to live streams. Chapter 5 explains link formats in general. For information about the mount points to add to URLs to implement user name and password validation in broadcasts, see Chapter 13.

Linking from a Web Page

For a RealMedia or Windows Media broadcast, you can use the Ramgen or ASXGen utility described in "Using a Client Launch Utility" to launch the appropriate client through a Web page link. The Web page URL uses the following format, in which the HTTP port is not required if Helix Universal Server uses port 80 for HTTP requests:

protocol://address:HTTPPort/ramgen|asxgen/mount_point/path/stream_name

RealMedia Link Examples

Using default values, a Web page URL to a broadcast originating from Helix Producer in account-based mode looks like this:

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

The /broadcast/ mount point is the default. A path such as news/ is optional. You include it only if Helix Producer specifies a path along with the stream name. You can use the path to select an archiving rule, for instance, or require user name and password authentication.

A broadcast originating from an earlier version of RealProducer uses the /encoder/ mount point instead of the /broadcast/ mount point. A Web page link looks like this:

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

If you are using broadcast redundancy with any version of Helix Producer or RealProducer, use the /redundant/ mount point instead of the /broadcast/ or /encoder/ mount point. Even though the streams have delimiters such as .1 and .2, you do not use the delimiters in the URL:

http://helixserver.example.com/ramgen/redundant/live.rm

Windows Media Link Examples

Using default values, a Web page URL to a Windows Media unicast looks like this:

http://helixserver.example.com/asxgen/wmtencoder/live.wmv.asx

A broadcast that uses encoder redundancy looks like this:

http://helixserver.example.com/asxgen/redundant/live.wmv.asx

Tip: See "ASXGen for Windows Media Player" for information about the extra .asx extension used in Windows Media URLs.

Linking through a Metafile

You can also use media client metafiles, which are described in "Using Metafiles", to request the broadcast. Links entered in a metafile, or typed directly into a media client, use the following format, in which the port value is not necessary if Helix Universal Server uses the default RTSP port (554) or MMS port (1755):

protocol://address:Port/mount_point/path/stream_name|SDPFileName

RealMedia Link Examples

In a Ram file or SMIL file, a URL to a broadcast originating from Helix Producer 9 in account-based mode looks like this:

rtsp://helixserver.example.com/broadcast/news/live.rm

Here, the news/ path is optional, and specified along with the stream name by Helix Producer. A Ram or SMIL file URL to a broadcast originating from an earlier version of RealProducer looks like this:

rtsp://helixserver.example.com/encoder/news/live.rm

If you are using broadcast redundancy, use the /redundant/ encoder mount point instead of the /broadcast/ or /encoder/ mount point. Even though the streams have delimiters such as .1 and .2, you do not use the delimiters in the URL:

rtsp://helixserver.example.com/redundant/live.rm

Windows Media Link Examples

Windows Media broadcast links in an ASX file use the following format:

mms://helixserver.example.com/wmtencoder/live.wmv

A link to a broadcast that uses encoder redundancy looks like this:

mms://helixserver.example.com/redundant/live.wmv

QuickTime and RTP-Based Player Examples

URLs to QuickTime broadcasts used in a reference movie file, or entered directly in the QuickTime player, specify the SDP file used for the broadcast. Remember, though, that the media player does not request the SDP file from the directory where the file resides. Rather, it requests the file through the broadcast mount point, as shown here:

rtsp://helixserver.example.com/qtencoder/QTbroadcast.sdp

Links to general RTP-based broadcasts look like this:

rtsp://helixserver.example.com/rtpencoder/RTPbroadcast.sdp

If encoder redundancy is used, a link looks like this:

rtsp://helixserver.example.com/redundant/QTbroadcast.sdp

Playing a Standby Message

If a live broadcast has not started, or is interrupted and has not returned when a viewer tries to reconnect, you can send a message that indicates general information about the broadcast, such as when it is scheduled to play, and what viewers can do if the stream is interrupted. You do this by making a file that contains the message you want to display, and placing it in a subdirectory with the same name as the live mount point.

To create a standby message:

  1. Under Helix Universal Server's content directory, create a subdirectory with the same name as the live mount point. Keep in mind that the live mount point depends on the type of RealNetworks encoder being used. To support all default broadcast mount points, you would create the following subdirectories in a default installation of Helix Universal Server on Windows:
  2. C:\Program Files\Real\Helix Server\Content\broadcast
    C:\Program Files\Real\Helix Server\Content\encoder
    C:\Program Files\Real\Helix Server\Content\wmtencoder
    C:\Program Files\Real\Helix Server\Content\qtencoder
    C:\Program Files\Real\Helix Server\Content\rtpencoder
    C:\Program Files\Real\Helix Server\Content\redundant

    or on a typical installation on UNIX:

    /usr/local/Real/HelixServer/Content/broadcast
    /usr/local/Real/HelixServer/Content/encoder
    /usr/local/Real/HelixServer/Content/wmtencoder
    /usr/local/Real/HelixServer/Content/qtencoder
    /usr/local/Real/HelixServer/Content/rtpencoder
    /usr/local/Real/HelixServer/Content/redundant

  3. Create a clip in the same format as your broadcast, such as RealAudio, RealVideo, Windows Media, or QuickTime, that contains the message to stream if the broadcast is not available.
  4. Tip: You may want to include information about when the visitor should check back, keeping in mind the different time zones in which viewers may reside.

  5. Place the appropriate standby clip in each of the subdirectories. Then, if a live stream fails to arrive, Helix Universal Server searches for the actual directory and clip that matches the broadcast mount point and stream name in the URL. In other words, it streams the prerecorded clips that use the stream names and that reside in the content subdirectories that mimic the broadcast mount points.


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