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. |
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.
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.
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. |
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 works with all other Helix Universal Server features. There are some considerations for each feature, however, as described in the following sections.
Live broadcasts use standard streaming protocols, so highly restrictive firewalls may block broadcasts. Firewalls are described in Chapter 11.
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. |
Helix Universal Server's ISP hosting feature can host on-demand content only. It does not host any live content.
You can view all streams and connections to broadcasts through the Server Monitor in Helix Administrator. Chapter 18 has more information.
The access log records all client connections to live broadcasts. The error log records any errors encountered by clients. See Chapter 16 for details.
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. |
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.
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: |
Enabled to activate the archiving rule selected in the Source Paths box.Tip:
If you want to archive only selected broadcasts, be sure to
choose Disabled for the "*" rule, and enable only the selective
rules.
|
/Archive/. Helix Universal Server matches the entry to one of the following elements, searching for a match in the following order:Content directory. If the directory does not exist already, Helix Universal Server will create it. The default location is the Archive subdirectory under Content.live.rm, the first archive file is named live0.rm, the second is live1.rm and so on.| 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. |
30 in the Minutes box. As with files limited by size, archive files limited by broadcast time are numbered sequentially.| 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. |
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". |
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.
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.
|
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:
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.
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. |
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: |
Disabled from the Broadcast Redundancy pull-down list. Otherwise, leave this set to Enabled.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) |
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.| 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. |
/redundant/.Manual. This message should tell users how to connect to the new stream. The default message is:Broadcast timed out; click Play button to restart. |
The following table explains how redundant broadcasting interacts with other Helix Universal Server 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. |
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. |
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". |
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. |
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.
| 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: |
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.SecureRBSEncoder. The section "Managing Users and Passwords" describes realms and authentication.Note:
You don't define a mount point with account-based
broadcasting. The predefined mount point used for all
account-based broadcasts is /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. |
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: |
/encoder/. Links to the broadcast include this mount point.SecureEncoder. See "Encoder Validation" for information about creating encoder passwords.| To use an encoder earlier than RealProducer G2: |
/live/. Links to the broadcast include this mount point.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. |
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: |
/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..asf, .wmv, or .wma. Optionally, you can precede the stream name with a path:
|
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".
live.wmv.1. The backup stream should have the same stream name, but use .2 as its delimiter. | For More Information: See "Using Broadcast Redundancy". |
| 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". |
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". |
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.
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: |
| 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. |
/qtencoder/ and /rtpencoder/ are predefined. For background on mount points, see "Mount Points".Content directory.| Note: If you indicate a different subdirectory or mount point, ensure that the specified directory exists before you restart Helix Universal Server. |
| 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. |
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 |
On UNIX, the directories are under the Content directory of the main
installation directory, as in these examples:
/usr/local/Real/HelixServer/Content/qtencodersdp |
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 |
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.
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:
|
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 |
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.
|
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):
|
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 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 |
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 |
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: |
C:\Program Files\Real\Helix Server\Content\broadcast |
or on a typical installation on UNIX:
/usr/local/Real/HelixServer/Content/broadcast |
| 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. |
|
|
© 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. |