After you record a clip, the confirmation dialog has a View Statistics button you can click to pull up a wealth of information about the clip. Even while RealProducer encodes the clip, you can watch statistics in real-time with View>Statistics. Although it's easy to pass these dry numbers by, they tell you a lot about your clip, including which speeds they're encoded for. The statistics dialog has up to three panes:
Figure 13 shows the basic recording information that appears at the top of the General, Audio, and Video panes of the statistics dialog. This example is for a SureStream RealVideo clip encoded with RealProducer Plus and targeting seven audiences.
As shown in Figure 13, the information at the top of each statistics pane indicates the basic choices made for audio format and video quality. When you view this information while encoding a file, the Clip Position field shows precisely where in the file's timeline RealProducer is encoding the clip. If it's two minutes and thirty seconds into the file, for example, Clip Position reads 00:02:30. When you broadcast, this field is labeled Duration, and shows how long the stream has been broadcasted.
The Time Remaining field indicates how much longer RealProducer will take to finish the encoding. RealProducer may finish faster or slower depending if other computer processes use the CPU during the encoding. The Time Remaining field doesn't work when broadcasting or encoding a clip from a media device. In these cases, the encoding lasts until you turn the input off.
The Real-Time Performance field shows a percentage value that indicates overall codec performance. The lower the percentage, the faster the codecs are working. If RealProducer takes just under five minutes to encode a clip that lasts five minutes, the performance is around 100%. On a fast machine, performance will more likely be a lower value. If it takes four minutes to encode the five-minute clip, performance is around 80%. On a slow machine, the performance value may go above 100%. Taking six minutes to encode a five-minute clip, for instance, delivers a performance of around 120%.
 |
Note |
|---|
| Performance is a measure of codec speed only. It does not take into account the time required for other activities such as disk reads and writes. |
A performance over 100% is not a problem when you encode from a file. This just means it takes longer to encode the clip than to play the original file start to finish. Performance over 100% is a problem when you encode from an input device or broadcast a stream, however. It means RealProducer cannot encode the input as quickly as it comes in. For broadcasts, RealNetworks recommends a performance of 80% or less to ensure smooth operation. If performance is above 80%, reduce the number of SureStream streams, run RealProducer on a faster machine, or turn off filters that may slow encoding time:
The General statistics pane, the main part of which is shown in Figure 14, appears only for RealVideo clips. It lists the total bit rate, video bit rate, audio bit rate, frame rate, and buffer time for each stream in the clip. Figure 14 is for a SureStream RealVideo clip targeting seven audiences.
Note the number of audience targets. Even though the clip is encoded for seven targets, 11 show up in this statistics dialog, which illuminates the inner workings of SureStream. Look at the two entries for Corporate LAN. They both use a 32 Kbps RealAudio codec, but the first has a total bit rate of 152.5 while the second has a 104.9 Kbps rate. The second stream is the duress stream that RealServer uses if the connection bogs down and it can't stream the full 152.5 Kbps of data. The audio stays the same, but as you can see from the Frame Rate column, the frame rate drops from 13.9 fps to 9.9 fps when RealServer downshifts.
 |
Additional Information |
|---|
| For more on duress streams, read "Duress Streams". |
If you look at these statistics from top to bottom, you can see exactly how the clip compensates if it starts to lose bandwidth. Each time it needs to downshift, the clip reduces bandwidth consumption with one or a combination of three things:
The last column of the statistics pane lists the time in seconds that RealPlayer takes to buffer a stream before playing it. A value of 3.5, for example, means RealPlayer starts to play the clip 3.5 seconds after it begins to receive clip data, assuming that the connection's bandwidth holds up and there's no network congestion. Ideally, you want buffering to be under 15 seconds. This buffering occurs only when the clip begins to play, not during downshifting or upshifting.
The Audio pane, shown in part in Figure 15, appears in the statistics dialog for RealVideo and RealAudio clips. It gives the frequency responses of the RealAudio codecs used to encode the clip. "RealAudio Codec Reference" lists the frequency responses for all RealAudio codecs.
Like the general real-time performance value shown at the top of each pane, the real-time performance value for each codec shows how quickly RealProducer created each RealAudio stream. Any value over 100% means RealProducer could not encode the track as fast as the data came in. As noted in "Basic Recording Statistics", an overall performance of 80% or higher can cause problems when you encode live input.
Illustrated partially in Figure 16, the Video pane displays only for RealVideo clips. It gives the video bit rate and frame rate for all streams, just like the General pane. In addition, it provides a quality index and information about real-time performance.
The quality index is useful only during live broadcasts. A value of 100% indicates the codec could keep up with the data coming in. A value below 100% means the computer does not have enough processing power to encode the stream in real-time. In this case, the codec compensates by dropping frames from the stream.
The real-time performance value for each video encoding tells how quickly RealProducer created each visual track. Any value over 100% means RealProducer could not encode the track as fast as the data came in. As noted in "Basic Recording Statistics", an overall performance of 80% or higher can cause problems when you encode live input.
