This chapter explains the issues and methods for broadcasting live content on a network, whether an intranet or the Internet. It introduces you to the types of broadcasts, explains broadcast options, and covers advanced broadcast features. When you are ready to broadcast, refer to Chapter 11 for instructions about using your chosen type of broadcast method.
 |
Tip: If you are new to streaming media, familiarize yourself with the process for encoding static clips, which Chapter 6 describes. You should also review the audio and video issues described in Chapter 4 and Chapter 5. Broadcasting requires many of the same choices you make when encoding a clip, and introduces new issues of broadcast bandwidth and processor load. |
In a live broadcast, RealProducer takes live input from a capture card as described in "Using Live Audio or Video as the Input", encodes it as RealAudio or RealVideo, and sends the stream to Helix Server for replication and distribution to RealPlayer viewers. You encode a broadcast stream using the same audiences you use when creating a static clip, as described in Chapter 7.
Helix Server is required for a broadcast because RealProducer cannot broadcast directly to RealPlayers. Nor you can deliver a broadcast using a Web server. The Helix Server license, or practical considerations such as its outgoing bandwidth, determine how many RealPlayer viewers you can reach with a broadcast. Helix Server must be configured to accept the broadcast, and the server setup determines how the broadcast is distributed to RealPlayer viewers:
To send a broadcast stream from RealProducer to Helix Server, you define a server destination in RealProducer. The destination records information such as the server's address and the password required for access. By saving a destination as a template, you can easily repeat a broadcasts using the same parameters. When you run a broadcast, you can send the same stream to multiple servers by defining multiple server destinations in your job. You can also archive the broadcast as a clip by adding a clip destination to your job.
RealProducer provides several different broadcast methods that you can use. Broadcasting methods break down into the two general areas of push and pull:
In push broadcasting, RealProducer initiates the broadcast stream and delivers the stream to Helix Server when the broadcast begins. There are several methods of push broadcasting:
In pull broadcasting, RealProducer does not deliver the broadcast stream as soon as you start encoding. Rather, it waits for Helix Server to request the stream, which occurs when the first RealPlayer user requests the broadcast. For more information, refer to "Running a Pull Broadcast".
Broadcasting constant bit rate (CBR) audio or video allows you to reach the widest audience on the Internet. As described in "SureStream CBR Clips", you can use SureStream to encode the broadcast stream for multiple audiences. Each primary stream or substream you choose increases the processor load during encoding, however, and adds to the outgoing bandwidth requirements.
If you choose the 56k Dial-up audience and the 128k Dual ISDN audience, for example, the encoding may require twice as much processing power. As well, the outgoing bandwidth available to RealProducer must be over 185 Kilobits per second.
 |
Note: Except for those encoded with the lossless codec, all audio-only RealAudio streams are CBR and support the use of SureStream. |
If you broadcast variable bit rate (VBR) video, you can choose one VBR audience for each output. Your outgoing RealProducer bandwidth, as well as your RealPlayer viewers' network connections, should be able to handle the maximum bandwidth requirement for your selected audience, as listed in Chapter 7. For example, the 350k Download (VBR) audience has a maximum possible bandwidth of 700 Kilobits a second.
|
Note: If you plan to broadcast a VBR stream, be sure that you understand VBR characteristics. See "VBR Clips for Streaming and Broadcasting" for background. |
When you use a non-multicast, push broadcast method, you specify whether to use TCP or UDP when delivering the broadcast stream to Helix Server. UDP is the preferred protocol because of the lower network overhead. But you may want to use TCP when delivering the broadcast over a lossy environment.
|
Note: The monitoring connection of an account-based broadcast always uses TCP whether the data transport stream is UDP or TCP. |
When RealProducer uses the connectionless UDP protocol, it does not receive notice that broadcast packets have arrived or are missing. This generally reduces the network communications overhead and improves the quality of the broadcast. Helix Server notifies RealProducer if it requires data to be resent. Thus, using UDP enhances the performance of your broadcast.
A firewall between RealProducer and Helix Server may block UDP packets. The best solution is to configure the firewall to allow UDP packets through the ports that RealProducer and Helix Server use the broadcast transmission. These ports, which vary depending on the broadcast method, are described in the sections about setting up each type of broadcast in Chapter 11.
If you select the TCP protocol when broadcasting, RealProducer and Helix Server establish a two-way connection. If a broadcast packet is lost in transmission, the network itself requests the packet to be resent. This makes TCP a highly reliable protocol for broadcast on a network prone to high packet loss. It is also more likely to pass through firewalls that you cannot configure to accept UDP communications.
Using TCP incurs a higher network and machine overhead, however, and can lead to inefficiencies. Helix Server does not need all stream packets to keep a broadcast flowing to RealPlayer. If a packet is lost, the network requests the packet again from RealProducer. That packet may no longer be available, however. Or, if it is available, it may arrive at Helix Server too late to be useful. Hence, both RealProducer and Helix Server must handle some network requests that do not benefit the broadcast.
Under normal conditions, Helix Server does not buffer the live stream input long before broadcasting it to viewers. When you broadcast RealVideo, however, RealPlayer must receive a video key frame before it displays the visual image. In the standard RealProducer encoding settings, it's possible that a key frame does not display until ten seconds after the broadcast begins to play. The viewer therefore hears the soundtrack for ten seconds until the video's visual track displays.
As described in "Maximum Time Between Keyframes", you can lower the maximum time between key frames to shorten this delay during a broadcast. However, this can reduce the compression gains of the RealVideo codec, resulting in a slower frame rate or lower visual quality. Note, too, that the delay can vary for each viewer depending on how often key frames are actually encoded into the stream and at which point the viewer joins the broadcast.
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 RealPlayer to the live stream instead of an on- demand clip. You can assign broadcast streams to SMIL regions to lay out the presentation, and play a broadcast sequentially or in parallel with on-demand clips.
SMIL can deliver an on-demand RealPix slide show along with live RealAudio, for example. 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. |
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 with RealPlayer and confirm that the quality is good. When RealPlayer connects, check that the content begins to play in a reasonable time, such as less than 15 seconds for a push broadcast or 30 seconds for the first request of a pull broadcast. Display RealPlayer's playback statistics to verify that the frame rate is adequate, and that packet loss is not excessive.
When you broadcast using SureStream, you can change the RealPlayer bandwidth preferences to display different SureStream streams. If you experience problems during your trial run, you may need to reduce the number of streams. Or, you may need to run the encoder on a more powerful computer.
|
For More Information: See "Broadcast Load Management" for additional points about managing processor load during a broadcast. Refer to Chapter 4 and Chapter 5 for tips about encoding audio and video in a live broadcast. |
The broadcasting techniques described in this chapter apply only to the broadcasting of live content. Using the Simulated Live Transfer Agent (SLTA) of Helix Server, you can broadcast static clips as if they were a live event. The effect is that of a radio station that broadcasts the same prerecorded songs to every listener at the same time. SLTA even allows you to define playlists that you can update during the broadcast.
To use SLTA, you encode static clips as described in Chapter 6. All clips used in an SLTA broadcast must be encoded for the same audience or audiences. You then transfer the clips to Helix Server, set up an SLTA playlist, and run the SLTA utility from the Windows or UNIX command line. The chapter on simulated live broadcasts in Helix Server Administration Guide explains how to do this.
In the simplest method of broadcasting, you send a single stream to a single server through a push or pull broadcasting method. Or, you send a single stream to multiple computers through multicasting. RealProducer allows you to send multiple streams to multiple destinations, however. As well, Helix Server offers several features for forwarding streams to additional servers. The following sections describe methods for distributing broadcast streams to multiple points.
Using RealProducer, you can define multiple server destinations for a single encoded output. This allows you to forward the same broadcast to more than one Helix Server. In push broadcasting, you define each destination explicitly. In pull broadcasting, a new destination is created each time a Helix Server pulls the broadcast from RealProducer.
Each additional server destination that you define for an output adds to your outgoing bandwidth requirement. If your broadcast stream is 350 Kilobits, for example, sending it to a second destination increases the total bandwidth to at least 700 Kilobits. Because the same stream is sent to each destination, using multiple destinations does not increase the processor load for live encoding.
Using parallel outputs, you can encode two or more streams with different properties. For example, you might want to encode live audio as a low- bandwidth, SureStream CBR stream for dial-up modem users, and as a high- bandwidth VBR stream for cable modem users. Because the same encoded stream cannot be both CBR and VBR, you create two separate outputs.
As shown in "Destinations and Outputs", you can send each encoded output to the same server destination, or to different server destinations. If the same Helix Server broadcasts both streams, the streams must have different names. Your Web page then gives viewers the choice of a low-speed broadcast or a high-speed broadcast.
Each output that you add increases the amount of processing power that RealProducer requires, so you need to ensure that your computer is fast enough to handle the load. The processing power required for each output depends on the audiences selected. A multi-rate SureStream encoding requires more processing than encoding for a single audience. As well, encoding video requires much more processing power than encoding audio-only input.
|
For More Information: To set up parallel outputs, you create a job file as described in Appendix B. You then run the broadcast through the command-line application, which Chapter 14 covers. |
Each Helix Server is limited in the number of viewers who can receiver the broadcast. These limits are based on the server license, as well as practical constraints such as the amount of outgoing bandwidth. For a large broadcast, you may need to use multiple Helix Servers to reach your anticipated audience. Although RealProducer can send a broadcast stream to multiple server destinations, it is often more efficient to have the servers forward (or split) the broadcast stream themselves.
The preceding illustration shows a simple splitting arrangement in which RealProducer sends a broadcast stream to one Helix Server acting as a transmitter. This server then splits the stream to three additional Helix Servers acting as receivers. The transmitter and receivers can each stream the broadcast to multiple viewers.
The method by which RealProducer delivers the stream to a transmitter is entirely independent of the manner in which the transmitter splits the stream. For example, RealProducer may use an account-based push to contact the transmitter, whereas the transmitter splits the stream by multicasting to the various receivers. As well, the receivers may be set up to pull the stream from the transmitter, even though RealProducer pushes the broadcast stream to the transmitter.
|
For More Information: Setting up a splitting arrangement requires the services of an experienced Helix Server administrator. For more information on available options, refer to the chapter on transmitters and receivers in Helix Server Administration Guide. |
The following sections describe optional features that you can use when broadcasting to Helix Server. In some instances, the Helix Server administrator must enable or configure the feature on the server.
When broadcasting through account-based or password-only push methods,
you can provide encoder redundancy through two or more RealProducers
encoding the same live event. When you start each broadcast stream, you
specify the same stream name, but add a unique, numbered delimiter, such as
.1 or .2. When the RealProducers connect to Helix Server, they form a queue
based on connection order. Consider this example:
live.rm.2 connects firstlive.rm.3 connects secondlive.rm.1 connects third
Under normal circumstances all viewers receive the stream live.rm, and have no
knowledge of which RealProducer encoded the stream. In the preceding
example, live.rm originates as live.rm.2. If the RealProducer delivering live.rm.2
fails, RealPlayers connect 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.
|
Note: Encoder redundancy is enabled automatically on Helix Server. Its use changes the broadcast URL, though. The Helix Server administrator may also require the use of a different delimiter, such as a tilde (~), in the stream identifier. Confer with the administrator on these issues before using encoder redundancy. |
|
Tip: To provide optimal redundancy, each encoder should be as independent as possible. For example, use multiple video cameras connected to separate RealProducer computers that use different power supplies and network connections. |
|
For More Information: Refer to the unicasting chapter of Helix Server Administration Guide for information about encoder redundancy configuration options. |
When you broadcast a live event, you can also record the event to a clip for later, on-demand streaming. You can archive the clip through RealProducer, Helix Server, or both. A primary consideration is disk space. Writing a long broadcast to a clip can consume considerable disk space depending on the broadcast bandwidth. The server may have more available space than your RealProducer computer. As well, creating the archive on the server eliminates the need to upload the archive clip later if you want to stream it on demand.
To archive a broadcast on RealProducer, you define a clip destination along with the server destination. RealProducer automatically creates a new clip if the existing archive reaches the operating system limit (typically 2 or 4 Gigabytes). If you run the broadcast from the command-line, or manually create a job file for the broadcast, you can specify a different file rolling limit based on broadcast time or file size.
|
For More Information: The section "Creating a Destination Clip" explains how to create an archive clip. For information on file rolling through the command line, see "Output and Destination Options". The section "File Destinations" explains how to define file rolling through a job file. |
The Helix Server administrator can turn on archiving for RealMedia broadcasts. Like RealProducer, Helix Server can create multiple archive files based on the broadcast time (such as a new file every 15 minutes), or file size (20 Megabytes per file, for example). The administrator can also set up selective archiving rules that archive only certain broadcast streams based on the presence of a virtual path in the stream name.
|
For More Information: See the unicasting chapter of Helix Server Administration Guide for information about archiving. |
When you encode a broadcast, you define a stream name such as live.rm.
Optionally, you can precede the stream name with a a virtual path, as in
news/live.rm. The virtual path does not correspond to any physical directory or
mount point. Rather, it serves as a flag to Helix Server to apply certain rules
for archiving or splitting.
The Helix Server administrator can set up archiving rules based on the
presence of virtual paths. For instance, the administrator may archive all
broadcasts that include the news/ path in a certain directory, and all
broadcasts that use the sports/ path in a different directory. A second use is
with splitting, which the section "Server Splitting" describes. The virtual path
can define which broadcast streams are split to which receivers.
|
Note: Confer with the Helix Server administrator about the path name to use. When you include the virtual path with the broadcast stream name, URLs to the broadcast must include the virtual path as well. |
|
For More Information: For information about server-side archiving rules, refer to the unicasting chapter in Helix Server Administration Guide. That manual's chapter on transmitters and receivers explains splitting rules. |
When you broadcast live content, it is crucial that your RealProducer machine encode the input audio or video in real-time. Otherwise, the encoding process falls behind the input media and the broadcast stalls. RealProducer provides several features that automatically lowers the processing load as necessary. The following sections explain these load management features, and discuss the encoding options that you may want to avoid because of the processing power they require.
|
Note: The number of SureStream audiences you choose for a constant bit broadcast greatly affects the processing requirements. See "CBR Broadcasts" for more information. |
|
Tip: You will get superior encoding results using a machine with two or more processors. The section "RealVideo Codecs" explains how RealProducer manages multiple processors. No matter how fast of a machine you use, though, you should not run other, unnecessary applications or services on the RealProducer machine during a live broadcast. |
Before running a broadcast, you can test your RealProducer computer to determine if it can handle the processing load.
The best way to do this is to run a test broadcast, as advised in the section "Broadcast Trial Runs". During the broadcast, look for messages about load reduction and frame dropping printed to the command-line application screen or displayed in the log viewer. After the broadcast trial has completed, check the statistics to ensure that the average video frame rate was acceptable.
|
For More Information: Refer to the sections "Viewing Log Messages" and "Monitoring Statistics". |
If you do not have a Helix Server available for a broadcast load test, capture live input to a RealMedia clip as described in Chapter 6. Select the same options and audiences you plan to use in the broadcast. If RealProducer can encode the clip in less time than it takes the clip to play (for example, 45 seconds to encode a 60-second video file), it can typically handle the broadcast load.
|
Tip: When testing with a video clip, turn off two-pass encoding as described in "Choosing Video Options". |
As noted in the section "Encoding Complexity Modes", you can set a video
complexity level of low, medium, and high. If you use the default setting of high,
RealProducer automatically lowers the level if the encoding process cannot
keep up with the video input. This scales down the video quality, but keeps the
broadcast flowing. You therefore do not need to change the level manually
when broadcasting unless you specifically want to reserve processing power
for other applications on the RealProducer computer.
By default, RealProducer uses RealVideo 10, which provides the highest video quality, but also requires the most processing power. For best results, stick with RealVideo 10 and let RealProducer reduce the encoding complexity automatically. If you use RealProducer Plus and still lack processing power, you can switch to RealVideo 9, which requires less processing power. RealVideo 8, in turn, requires less processing power than RealVideo 9.
|
Tip: YUV12, also known as I420, is the native color format used by RealVideo codecs. Capturing video input as I420 improves performance by removing the need to convert the color format before encoding. |
If necessary, RealProducer scales down the encoded frame rate to keep up with the media input stream. Most audience settings specify a preferred frame rate of 15 or 30 frames per second. RealProducer attempts to provide the preferred rate, but encodes at a slower rate if necessary if the encoding process begins to maximize the CPU usage. Check the log viewer for reductions in frame rates. To keep the frame rate encoding adequate, you may need to eliminate other, CPU-intensive features, or broadcast using a faster computer.
|
Note: RealProducer may also lower the encoded frame rate because of the bandwidth constraints of the chosen broadcast audience. The RealProducer log does not report these rate reductions because they do not result from CPU bottlenecks. The RealPlayer playback statistics panel lists the broadcast stream's frame rates, however. |
The section "RealVideo Filters" explains the video prefilters that you can use during a broadcast. The black-level, de-interlace, and low noise filters are relatively safe to use because of their low processing needs. Resizing a video is highly processor intensive and should not be used when broadcasting. However, cropping a video can speed the encoding process because it decreases the amount of video data that must be encoded.
|
Tip: When possible, use the video capture card to set the video input to the appropriate size. Resizing through hardware is generally faster than resizing through software. See "Video Encoding Dimensions" for tips about selecting the video height and width. |
RealAudio codecs require audio input to have a certain sampling rate. If necessary, RealProducer resamples the audio to the necessary rate before encoding. It is helpful to avoid resampling by ensuring that your audio input uses a preferred sampling rate. See "Sampling Rate" for details.
If you use the RealProducer graphical application to run the broadcast, RealNetworks highly recommends that you turn off the visual display of the input video and encoded output to lessen the processor load. Refer to the section "Monitoring Video Output" for instructions.
|
©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. |
