Bandwidth savings
The KulaByte process creates a CBR-like stream. However, because the encoding is based on VBR, video quality is roughly 20 percent better than if the video had been encoded with just CBR. Using identical codecs and settings, internal tests have shown that the PSNR (Peak Signal to Noise Ratio) of an 800Kbps stream encoded with the KulaByte process is equal to that of a standard CBR stream encoded at 1Mbps.

Using KulaByte with multiple processors
In addition to improving the quality of encoded video, the KulaByte process provides a better way to configure your encoding computer to use multiple processors.

Typically, when a codec is used in a multi-processor environment, each video frame is split into horizontal tiles, which are then encoded with different processors. (Figure 7 shows how this works with a dual-processor or dual-core encoder.) The problem with this approach is that motion vectors cannot span the junction between the tiles, and as a result the encoding process is not as efficient. This results in a slight reduction in PSNR when using two processors. The problem worsens with four processors; instead of one horizontal line across the picture, there are three (see Figure 8). As you can see, this introduces a problem of scalability; as you add more processors to reduce encoding time, you lower the quality of your video.

Figure 7: With dual-processor or dualcore encoder.

Figure 8: With four processors.

Another problem is the amount of development time it takes to build an encoder that works properly with multiple processors. The encoder has to be engineered specifically to divide the picture into tiles, and then send the right data to each processor. For this reason, many current codec implementations are only single-threaded. This is fine for a lightweight codec, but it means that many heavyweight codecs cannot be used for real-time streaming, because there is no single processor that can handle the load.

KulaByte uses a different approach to multi-processor encoding. Each processor runs a different instance of the encoder, and successive TimeSlices are sent to each encoder in turn. There is no limit to the number of processors that can be used, so scalability is not an issue. Kula Media Group engineers have shown that live encoders can run effectively in a multi-processing environment with no modification to the underlying single-threaded codec software at all.

Even though this approach requires that a new I-frame be generated at the beginning of each TimeSlice, there is only a slight impact on PSNR. The total impact is less than with tiling, because the TimeSlice method affects the motion vector calculation only for the frame of video at the beginning of each TimeSlice, compared to every frame when tiling. As a result, the PSNR value does not decrease as more processors are added. Regardless, the problem is easily mitigated by starting each TimeSlice on a frame that would be encoded as an I-frame anyway.

Next: Live streaming with KulaByte, High Speed encoding