An all new encoding mode: KulaByte
KulaByte, a patent pending process developed by Kula Media Group, solves these issues and allows almost any codec to stream high-quality video over a fixed bandwidth network without any dropped frames. Being codec independent means that KulaByte works with codecs such as WM9 (VC-1), Flash, ON2, MPEG2, MPEG4, H.263, and H.264. KulaByte even enables live encoding using codecs that were not engineered for real-time use.

KulaByte works by dividing a file into short TimeSlices, and independently encoding each TimeSlice with twopass VBR. The TimeSlice can be anywhere from less than a second up to the size of the targeted client size buffer, but is typically around 5 seconds.

With traditional one- or two-pass VBR encoding, the Q value is the same throughout an entire video stream. With KulaByte, a specific 2PVBR bit rate is applied individually to each TimeSlice, and then the Q of each TimeSlice is normalized to meet the specified output bit rate. The result is a CBR compatible stream that is guaranteed to not drop any frames!

Figure 5 shows the bit rate normalization of each TimeSlice.

KulaByte with a Client Buffer
There are times when some variability in the stream is acceptable, or even desired. Because CBR and VBR are both used in this hybrid model, the KulaByte process is very flexible.

In most server/client streaming products, there is a client side buffer specifically meant to smooth out network fluctuations. This buffer can be intelligently utilized by the KulaByte process. The calculation below, which is part of the patent pending KulaByte process, can be used to generally determine how to fill the client side buffer, and can be used to ensure that the variable bit encoding process does not exceed the overall predetermined bit rate.

Figure 6: Varying bit rates according to TimeSlices

A variable encoding bit rate for a particular TimeSlice to be delivered to the client may be calculated. In Figure 6, The TimeSlices labeled 1, 2, 3, and 4 have been previously encoded at varying bit rates of 700 Kbits/second, 300 Kbits/second, 200 Kbits/second, and 1800 Kbits/second, respectively. In order to find an encoding bit rate for TimeSlice 5, the following equation may be used:

where x is the variable encoding bit rate for a current TimeSlice that needs to be compressed (e.g., segmented media file 5 of Figure 6), y is equal to the client buffer size (here, measured in units of seconds), z is the number of previous segments that can fit in the client buffer with the segment that needs to be compressed (here, 4, since 4 previous segments plus the segment being compressed will fit in the client buffer), and the targeted client bandwidth is the value discussed above, which can be chosen based on what the desired CBR bit rate would be.

In the example of figure 6, if we assume the targeted client bandwidth is 700 Kbits/second, the use of the above equation yields: [(700+300+200+1800) +x ]/5 is less than or equal to 700. Solving for x, one finds that the 5th segmented media file can be encoded at a bit rate up to about 500 Kbits/second without exceeding the client buffer.

Note that in this example, the variable encoded bit rate for segmented media file 4 is much greater than the targeted bandwidth of the client. This is possible due to a re-allocation of bit rate bandwidth not used during the encoding of prior TimeSlices.

How does this affect streaming quality over a network? In general, a traditional CBR stream is most efficient only when the desired bit rate of the video is very close to the available bandwidth. You would think that any variability in the stream could push the bit rate over the top, resulting in dropped packets, and a bad experience for the viewer. However, the KulaByte process is both network and viewer friendly. Field testing has shown that the higher bandwidth TimeSlices do get delivered more slowly to the client, but the client is playing out of its buffer during this time anyway. The overall average bit rate is maintained by the equation above, the client buffer does its job in smoothing out the network peaks and valleys, and the visual result is high quality video images with no dropped frames.

Next: Bandwidth savings and multi-processor design