Bamba--Audio and video streaming over the Internet

IBM Journal of Research and Development, Mar 1998 by Willebeek-LeMair, M H, Kumar, K G, Snible, E C

In certain cases (e.g., limited amount of memory), it might not be feasible to process an entire video before starting to encode it. With a little modification, the same algorithm can operate on a segment-by-segment basis. A video can be partitioned into non-overlapping segments, each segment being treated independently. The encoder performs the two-phase compression on all frames in a segment and then moves to the next, non-overlapping segment and encodes it independently. This technique cannot be applied to delay-critical applications when frames cannot be prebuffered. A scheme to deal with real-time applications is discussed in [20].

Bamba stream format and synchronization The Bamba stream format was designed with the UDP/IP environment in mind, where it is assumed that packets can be lost at any time during the transmission and that new clients may join a multicast transmission at any point during an ongoing broadcast. This makes it necessary that the packetized stream contain sufficient information for a client to interpret a packet's content at any point in the stream. This can be done by either a) packetizing the audio and video on distinct audio and video frame boundaries, so that the splitter module can automatically separate audio from video, or b) providing a means to detect the frame boundaries within the stream. The first approach adds overhead to the server, since the server must be aware of the audio and video frame boundaries and perform special packetization. The Bamba file format is equivalent to the streaming format; i.e., the server does not have to process the data in the file, but must simply place contiguous chunks of data from the file into packets and send them. For this reason, Bamba is implemented using the second approach, in which every Bamba file is separated into Bamba frames, each containing a header, a portion of audio, and a portion of video. Each Bamba frame header contains a unique synchronization symbol (bit pattern) that does not reappear within the data (audio and video) portions of the stream. This way, whenever a packet is lost, the client begins searching the incoming bit stream until it detects the unique synchronization symbol. To ensure that the header synchronization symbol does not occur within the stream, the audio and video data are run through a byte-stuffing filter that alters the byte sequence in the event that the special symbol is detected in the input stream. The stream must be destuffed at the receiver. Sufficient information is provided within each Bamba frame header for the client to interpret how the audio and video data are apportioned within the variablelength Bamba frame and to initiate synchronization of the two. The unique synchronization symbol consists of 4 bytes: 00 00 FO FO. The byte-stuffing algorithm scans the stream in search of the pattern 00 00 FO. If the pattern is found, the algorithm inserts an FF. The destuffing routine searches for 00 00 FO. If it finds an FF following the sequence, it removes it; if it finds an FO, it recognizes the header-synchronization symbol (any other byte would represent an error). This guarantees that the synchronization symbol, 00 00 FO FO, can occur only within the header.