RealSystem Producer has several options that affect how it encodes RealVideo clips. These options can improve clip quality, but also degrade it if used improperly. Some options also affect encoding speed. Choose Options>Preferences to display the preferences dialog, which has three panes of options.
 |
Note |
|---|
| Unless noted otherwise, all RealVideo options are compatible with each other and can be used when encoding video from a source file, a media device, or a live broadcast. |
The Video Filter pane of the preferences dialog has several filtering options you can use when encoding RealVideo. These filters remove artifacts that appear in the encoded clip because of the methods used to create the source video.
A by-product of poor quality in one or more links in the video production chain, video noise (which has nothing to do with the audio quality) can distort the encoded clip. These distortions are similar to the "snow" that often shows up in TV signals received over an antenna. The source of the noise is typically hardware, such as the video tape, capture card, or camera. Using professional-quality equipment and media helps eliminate video noise at the source. If your source video is high quality to start with, you won't need the noise filters.
 |
Additional Information |
|---|
| See the video preparation chapter in RealSystem Production Guide for tips on producing high-quality video. |
If your video input has a small amount of noise, turn on the low-noise filter. Because it has a small impact on processing power and won't degrade a video's appearance, the low noise filter is safe to leave on at all times. It's better practice, though, to use it only when necessary.
If noise greatly distorts the source video, try the high noise filter. Although optimized for Pentium MMX machines, the high noise filter can nonetheless add 30% or more to the encoding time. It can also remove slight details, making highly textured surfaces look more smooth. For these reasons, never use the high noise filter when it is not needed.
RealSystem Producer's Options>Video Settings... command lets you resize video as you encode it. On the Video Filter tab of the preferences, you can select whether to do this as a fast resize or a high-quality resize. These resize options affect the video only when you make it smaller. They tell RealSystem Producer to throw out video data using a quick method (fast resize), or through a complex analysis (high-quality resize).
A fast resize has a small impact on encoding time, but the resulting image may have some distortion. A high-quality resize results in a superior image, but it may double or triple the encoding time because it carefully analyzes the video source before resizing. Because of its impact on speed, the high-quality resize filter is not recommended for broadcasts.
The Inverse-Telecine filter is for cinematic film that was transferred to NTSC video, whether the VHS or BETA version. Film is usually photographed at 24 frames per second (fps), whereas the NTSC standard is 30 fps. The film-to-video conversion (called "telecine") duplicates some frames to bring the film input up to the NTSC frame rate. American theatre-release films transferred to video, for example, undergo the telecine process.
Use the inverse-telecine filter when encoding NTSC video that was transferred from film and has a frame rate of 25 to 30 fps. (The filter is not necessary if the video frame rate is below 25 fps.) The filter strips out redundant frames, letting RealSystem Producer focus on image quality. This improves the clip's overall look. Although the inverse-telecine filter is safe to use on all input, it slows performance marginally and should be used only when the source is NTSC video that originated from film.
|
|
Note |
|---|
| PAL video, which is widely used in Europe, does not require the inverse-telecine filter because the conversion from 24 fps film to 25 fps PAL does not use the telecine process. |
The de-interlace filter removes jaggedness in interlaced NTSC or PAL video. A video camera running at 30 frames per second captures the odd-numbered lines of a frame in 1/60th of a second, and the even-numbered lines in the next 1/60th of a second. It then interlaces the two to create the frame. Because half the frame's lines are captured a fraction of a second later than the other half, fast-moving objects may appear jagged, the result of the object advancing slightly within 1/60th of a second. Figure 7 illustrates this jaggedness in a detail of an interlaced video.
Figure 8 shows the jaggedness removed with the de-interlace filter.
Optimized for Pentium MMX processors, the de-interlace filter has a modest impact on encoding speed, but is useful only for interlaced source video that is 240 lines or higher. Typical source video used for television is 480 lines high. If you digitize the video with a video capture card that captures at 240 lines high or less, the card throws out either the odd or the even lines, de-interlacing the video itself. The de-interlace filter is safe to leave on, though, because RealSystem Producer never applies it to a video less than 240 lines high.
The Video Codec pane of the preferences dialog includes several encoding options you can use with RealVideo. It also lets you select which RealVideo codec encodes your clips. These options affect the quality of RealVideo clips by modifying RealSystem Producer's encoding methods.
The top of the Video Codec pane has a pull-down menu that lets you choose between three RealVideo codecs. The default choice is the RealVideo 8 codec, but you can also choose one of two RealVideo G2 codecs. The codec you select encodes all of a clip's SureStream streams. You cannot encode half the streams with the RealVideo 8 codec, for example, and the other half with a RealVideo G2 codec.
The default RealVideo 8 codec results in visual quality markedly superior to that of the RealVideo G2 codecs. It requires more processing power, though, so encoding a clip with it takes longer than encoding the clip with a RealVideo G2 codec. RealPlayer 8 and higher can play RealVideo 8 clips. Earlier RealPlayers attempting to view a RealVideo 8 clip are prompted to auto-upgrade to RealPlayer 8. RealNetworks recommends using this codec unless you need faster encoding performance during broadcasts, or must reach older versions of RealPlayer.
|
|
Note |
|---|
| Most users upgrade their RealPlayers soon after a new version is released, so it is generally safe to use the RealVideo 8 codec. |
The RealVideo G2 codecs are older codecs used by RealProducer G2 and RealProducer 7. These codecs are faster than RealVideo 8, but their visual quality is poorer. Use them for faster encoding during broadcasts, or if you must reach RealPlayers that cannot upgrade to Release 8:
The RealVideo G2 with SVT codec is compatible with RealPlayer version 6.0.6 or higher. RealPlayers with lower version numbers are prompted to auto-upgrade to the latest RealPlayer before viewing the clip.
The RealVideo G2 codec without SVT is compatible with RealPlayer G2, 7, and 8. It is not compatible with RealPlayers version 5 or earlier.
The RealVideo 8 and RealVideo G2 with SVT codecs include Scalable Video Technology (SVT). This technology removes a stumbling block of streaming media by letting you encode clips at high frame rates for fast machines without concern that slower machines might not keep up. SVT even works when delivering clips with Web servers.
RealVideo's variable frame rate means one scene may be encoded at 7 fps, while another is at 15 fps. High frame rates take a lot of processing power to decompress. Although fast PCs handle high frame rates well, slower PCs may have trouble. With SVT, RealPlayer can lower the frame rate "on the fly" to keep the PC's CPU from sputtering. So although a certain scene is encoded at 15 fps, it may play on some RealPlayers at 8 fps, for example, if those RealPlayer machines lack the power to decompress 15 fps.
The loss protection feature adds error correction data to RealVideo streams, helping them maintain quality in lossy environments. RealSystem Producer adds as much error correction data as it can without taking away any video quality. Although you'll get more benefit from this feature when streaming on the Internet than on an intranet, it is safe to leave loss protection on for all encoded content. This feature has a negligible impact on RealSystem Producer's encoding speed.
Variable bit rate (VBR) encoding varies a RealVideo clip's playback bit rate, giving more bandwidth to scenes that are hard to compress, and less to scenes that are easy. Compatible with SureStream and broadcasting, VBR encoding generally provides superior video quality to constant bit rate (CBR) encoding, which RealSystem Producer uses if you do not select the VBR option. VBR makes the most difference in videos that have a mix of high-action and low-action scenes because it can steal bandwidth from low-action areas to give to high-action areas. This is particularly useful for improving video quality at low bit rates.
To illustrate how VBR encoding works, suppose you encode a video for a DSL/cable modem audience at 225 Kbps. With CBR, the video gets 225 Kilobits of encoded data each second. With VBR, though, each second of video may be encoded at a different rate. One second may have 150 Kilobits of data, for example, while another second has 300 Kilobits. The VBR clip will have a streaming bit rate of 225 Kbps, though, just like a CBR clip. So you do not need to worry that a VBR clip will underuse or overload a connection's bandwidth.
Think of the playback bit rate of a VBR clip as a waveform with peaks and troughs, as illustrated in Figure 10. RealSystem Producer preloads the extra Kilobits required to play upcoming peaks in the preceding troughs. So one low-action scene that requires 150 Kilobits of data per second actually streams at 225 Kbps, carrying with it an extra 75 Kbps that RealPlayer uses in an upcoming fast-action scene. The flat line at 225 Kilobits in Figure 10 represents this streaming bit rate.
A VBR-encoded video that starts with a high action scene needs a spike of bandwidth right away. If there are no preceding troughs to carry this data, RealPlayer has to buffer the clip longer. That means it may take the VBR clip longer than a CBR clip to start playing back. RealSystem Producer lets you set the maximum time RealPlayer needs to buffer the clip, though, to ensure that the initial buffering time remains acceptable.
|
|
Additional Information |
|---|
| See Setting VBR Maximum Start-up Latency for information on changing RealPlayer's initial buffering time. |
With two-pass encoding, which is used only when encoding from a digitized source file, RealSystem Producer runs through the entire source video once to gather information about how best to encode the streaming clip. It then makes a second pass to encode the streams. Two-pass encoding can substantially increase clip quality, but it requires more encoding time. The first pass takes about as long as it would to encode the source file for one target audience.
Although two-pass encoding helps when you use constant bit rate encoding, it provides greater benefit for variable bit rate (VBR) encoding, which is described above. With two pass encoding, RealSystem Producer can analyze the entire video file to determine how best to vary the playback bit rate through the length of the clip. Without two-pass encoding, RealSystem Producer sequentially analyzes small sections of the source file during encoding, creating a string of VBR sections within the clip.
The Advanced pane of the preferences dialog has options that affect RealVideo encoding. You should change these only with caution because they can greatly affect how well the clip streams.
The VBR Maximum Startup Latency field affects only RealVideo clips encoded with a variable bit rate (VBR), which is described in Variable Bit Rate Encoding. A VBR video that starts out with a high-speed scene needs more initial buffering because the first scene is encoded at a playback bit rate higher than the audience connection speed. Because RealServer can't stream the scene faster without overloading the connection bandwidth, it streams it longer to deliver the extra Kilobits needed.
The latency field determines how long RealPlayer viewers may have to wait before a VBR video starts back. The default value of 15 seconds means that no matter how complicated the video's first scene, RealSystem Producer will encode it so that it requires no more than 15 seconds to start playing. The field sets a maximum value only, and RealVideo VBR clips may start playback sooner. You can change the maximum to a whole value from 5 seconds to 25 seconds.
The value of 15 seconds is RealNetworks' recommendation. Keep in mind that this represents 15 seconds of clip data buffering, and does not include the time it takes to launch RealPlayer, find the host RealServer, send the request, and receive the host's response. If a low start-up time is critical, lower the latency time to 10 seconds, for example. For comparison, constant bit rate clips are encoded to have a latency of about 5 seconds. If initial image quality is crucial, you can raise the latency time, but this may cause restless viewers to stop the presentation before it begins playback.
RealSystem Producer encodes full data for a frame in a keyframe. Successive frames encode just the data that describes how they vary from the preceding frame, starting with the keyframe. The Maximum Time Between Keyframes field is set initially to 10,000 milliseconds, meaning a constant or variable bit rate RealVideo clip has a keyframe at least every 10 seconds. The main reason to change the maximum rate is to lower it, although you should do this with caution. Lowering the rate generates more key frames for clips and provides several benefits:
File>Edit RealMedia File. You have to cut a RealVideo clip at a keyframe, for example. More keyframes means more precise control over where the cut occurs.
Because keyframes encode much more data than other frames, though, lowering the maximum time between keyframes can lower the clip's image quality if you do not also raise the clip's streaming bandwidth. If you change the keyframe rate, test the clip quality to determine if the modification produced the desired results.
|
|
Additional Information |
|---|
| See Changing RealVideo's Target Bit Rate for information on raising a clip's streaming bandwidth. |