When you encode a clip with RealSystem Producer, the most important decision you make is whether to create a single-rate clip or use SureStream to generate a multi-rate clip. This choice is simple:
However, to use RealSystem Producer effectively, you should understand what SureStream is. This will help you later if you decide to change the RealSystem Producer encoding defaults.
Introduced with RealSystem G2, SureStream technology gives the best possible playback experience for different types of network connections. With SureStream, you can encode your source file for optimum streaming over, for example, 28.8 Kbps modems, 56 Kbps modems, and 112 Kbps dual ISDN connections, as illustrated in Figure 1. Users with 28.8 Kbps modems receive the stream at the lowest bit rate, while users with faster connections get a stream with better quality because of the extra bandwidth. RealSystem Producer Basic encodes two speeds per clip, RealSystem Producer Plus up to eight speeds.
A SureStream clip can also "downshift" when a connection gets bogged down. Suppose a viewer starts out receiving a higher bit rate stream through a 56 Kbps modem. If the connection starts to sputter as the network gets crowded, RealServer automatically downshifts to a lower bit rate stream. The audio or video quality drops with the lower rate stream, but the clip keeps playing. When the interference clears, RealServer upshifts to the higher rate stream. RealPlayer doesn't need to rebuffer during this shifting.
SureStream works only with clips streamed with RealServer. Because SureStream wraps several streams into a single clip, a server has to know how to extract just one stream from the clip. RealServer can do this, but Web servers, which don't know the details of SureStream, send down all the encoded data for a SureStream clip rather than just one stream.
Although you can encode a clip for just one connection speed with SureStream, you should never do this when delivering a clip with a Web server. Even when encoded for just one speed, a SureStream clip contains "duress" streams that let it downshift during network turbulence. For example, a SureStream music clip encoded only for 28.8 Kbps has duress streams at 16 and 11 Kbps. A Web server downloads all these streams, wasting bandwidth.
When using a Web server, you can provide different bandwidth choices by encoding your source file several times for different connection speeds. You then provide multiple links on your Web page (one for each clip), or use SMIL's <switch> tag so each RealPlayer chooses the right clip automatically. SMIL isn't as flexible as SureStream, and you won't get downshifting, but using SMIL makes it easier for your viewers to get the best clip for them.
 |
Additional Information |
|---|
See the SMIL chapter in RealSystem Production Guide for
instructions on using a <switch> tag.
|
Because each SureStream stream increases the clip's file size, an encoded clip may be larger than its source file, even though the clip is compressed. If the clip's file size is an issue, limit the SureStream streams to just the essential speeds. Table 1 gives ballpark figures for file space required for each minute of a RealAudio or RealVideo stream.
When using SureStream to encode RealAudio or RealVideo, add the figures from Table 1 for each connection speed you encode, then multiply by the length in minutes the source file plays. Table 1 shows that if you encode a RealAudio clip for 28.8 Kbps and 56 Kbps modems, for example, the clip takes about 0.39 Megabytes of disk space per minute (0.15 + 0.24). If the audio is five minutes long, the clip will be about 1.95 Megabytes in size (0.39 x 5).
The figure you get is an approximation based on using the RealSystem Producer default settings. The actual file size varies depending on the combination of streams you've chosen, the type of audio, and whether you've changed the defaults. If you encode for just one connection speed, the file will likely be larger than you calculated because of the duress streams. When you encode RealVideo for multiple connections, the file size may be lower than you calculated because different RealVideo streams may use the same RealAudio stream for a soundtrack.
