Large Scale Experiments on
`Low Bit Rate Multimedia Broadcast
`
`Z.Shae*, X.Wang, and S.P.Wood
`
`IBM T. J. Watson Research Center
`30 Sawmill River Rd, Hawthorne, NY. 10532 USA
`
`ABSTRACT
`
`This paper contains our experience with low bit rate multimedia streaming and broadcast, as applied to the Internet/Intranet,
`and focuses on two of the enabling technologies: 100% Java clients and broadcast reflectors. Interpreted Java is slower than
`compiled C/C++ and Java platforms do not currently support video and audio synchronization. Various techniques to
`improve Java performance and to reduce code size are provided in detail. A novel video and audio synchronization
`mechanism for the pure Java environment is devised and investigated. This paper also describes a hierarchical reflector
`network architecture which, superimposed on the Internet, is a practical alternative for broadcasting of events to massive
`client audiences when multicast support of such audiences in the current Internet is questionable and remains untested.
`
`Keywords: Multimedia Broadcast, Reflector, Java Optimization, Streaming, Audio/Video Synchronization
`
`1. INTRODUCTION
`
`Multimedia streaming and broadcast across the web is exploding. Improved processor performance, higher bandwidth
`connectivity and improved compression are important technology trends which are fueling this onslaught. Our experiments in
`this area evolved from initial investigations into key technologies that would allow the integration and composition of
`multimedia with Internet HTML pages and permit media-rich web-based content to be developed. Applications, such as
`distance education and business seminars, based on the playback of stored media were envisioned. Broadcasting, of either
`live or recorded content, extended the application potential to include transmission of live speeches and presentations.
`
`Bamba, developed at the T.J. Watson Research Center. is a solution for low-bit rate audio/video broadcasting and streaming
`across the Internet. Bamba uses standard compliant codecs that can compress video and audio clips down to low-bit rates
`compatible with 28.8k modems and can also scale up, to provide higher quality video, to rates in the low hundreds of kilobits
`per second. The compressed audio and video data is packetized using the Bamba stream format that was designed to operate
`in a UDP/IP environment where packets can be lost at any time during the transmission. It was also designed to allow new
`clients to join a multicast transmission at any point during an ongoing broadcast. The Bamba stream format allows the server
`to fragment video and audio at arbitrary data boundaries that can significantly increase server efficiency. Bamba also includes
`patented provisions for fast video recovery from network error [1,2]. Bamba had its public debut when it was featured as a
`technology demonstration on the official web site of the 1996 Olympics and has then been made available for download from
`the IBM alphaWorks web site.
`
`The initial Bamba client player was designed as a browser plug-in. With the advent of Java and the rapid advances of the
`technology in its application to the Internet, we decided to implement a pure Java version of the Bamba streaming player that
`would allow us to overcome both platform dependency and the complexity of installation for the average user. The move to
`the Java environment, with its notoriously slow code execution and lack of sufficient multimedia support, was extremely
`challenging given our goals: small code size, fast speed, and high quality multimedia performance.
`
`Reflectors, the other technology to be discussed here, were developed as a practical alternative to multicasting. The
`deployment of DVMRP[3] multicast algorithm on the Internet would cause periodic network flooding due to its broadcasting
`
`*
`
`Correspondence: Z.Shae. Other author information: X.Wang; Email: xiping@us.ibm.com; S.P.Wood; Email: woodsp@us.ibm.com:
`Z.Shae; Email:zshae@us.ibm.com
`
`Part of the IS&T/SPIE Conference on Visual Communications
`and mane Processing '99 • San Jose, California . January 1999
`SPIE Vol. 3653. 0277-786X198/$lO.OO
`
`PAGE 1 of 11
`
`WEBPOWER, INC.'S EXHIBIT 1017
`
`

`
`in the tree pruning process. Although various multicast algorithms {4-7} have been proposed or implemented, the multicast
`support of massive audiences in the current Internet is still questionable and remains untested. Therefore, to support
`broadcasting such events, we have developed a reflector solution that provides efficient network distribution of the massive
`live multimedia streams. Some time later, Real Network Inc. installed a similar reflector network (RBN [13]) maintained by
`MCI for its Realplayer broadcasting. We also mention briefly in this paper some reflector network applications beyond their
`primary use in stream replication and distribution.
`
`This paper now presents the details of our efforts in these two major enabling technologies developed for Bamba. First a brief
`overview of the Bamba architecture is covered in section 2. Section 3 details the reflector network as a solution to the
`problem of efficient distribution of live broadcast streams. Section 4 covers the pure Java player, and contains an overview of
`the issues followed by the techniques that used to optimize the Java code and to synchronize video/audio playback. At a time
`when many people were still doubtful that pure Java could be used to implement a multimedia player we show results that
`demonstrate satisfactory end-user performance. Finally, a summary is given in section 5.
`
`2. OVERVIEW OF BAMBA ARCHITECTURE
`
`An introduction to Bamba and architecture overview has been published before [9]. However a short description of essential
`background material for the topics discussed in this paper is included here. The Bamba player is designed as a client-side
`extension to a standard Internet browser, plug-in or applet, that works with an unmodified HTTP web server to stream stored
`multimedia content to a client. This is shown in figure 1 below.
`
`Web server
`
`Client
`Figure 1 . Streaming multindia from a web server to a client.
`
`The multimedia content is played while it is being received — so called "streaming". The only server side requirement is to
`specify a new MIME type for the Bamba multimedia content.
`
`The Bamba live broadcast client player is also launched from a web page. A parameter, authored in the plug-in's HTML
`<EMBED> tag or <APPLET> tag, now specifies another IP address from which to receive the live multimedia stream. The
`live source is captured and encoded at a transmission station and fed to a reflector network. The client connects to one of the
`reflectors in the network, as identified by the IP address authored in the HTML tag parameter, and joins the live broadcast.
`This arrangement is shown in figure 2 below; only one reflector has been shown for clarity.
`
`Web server
`
`Client
`
`Reflector
`
`Live source and encoding
`transmission station
`
`Figure 2. Broadcasting live multimedia to a client via a reflector.
`
`796
`
`PAGE 2 of 11
`
`WEBPOWER, INC.'S EXHIBIT 1017
`
`

`
`For live broadcasts there is a security issue with Java as applets are only allowed to make connections to the host from where
`the applet byte code originated. So for Java clients we also run a minimal web server on the reflector machine whose sole
`purpose is to supply the applet code. The HTML page containing the applet is still obtained from the usual web server to
`ensure that the reflector fulfills its primary role of distributing media.
`
`3. REFLECTORS
`
`There are some major differences between broadcasting a live stream and streaming stored content to a web browser. The
`latter can be done using only a standard HTTP server - a key goal for Bamba was to provide a low cost entry level into
`multimedia streaming and encourage web-based multimedia application experiments. For stored content each client requires
`a unique media stream from the source. Any other clients that may be viewing the same stored content will not, in general, be
`viewing at the same position in the media and also may want to exert individual control over their stream to pause, resume,
`rewind etc. This is not the case for live broadcast.
`
`With live streams all clients will be viewing the same live content at the same time and at the same position in the media
`stream. With many clients viewing the same media stream simultaneously efficient distribution is required to minimize
`network congestion. Multicast, for IP networks, is one solution that has been developed for efficient distribution. Drawbacks
`to using this approach are the current sparseness of deployment and problems in traversing firewalls. So for live Bamba we
`chose to use TCP connections that would allow us to easily traverse firewalls and manage the distribution problem by
`deploying hierarchical reflectors in the network. A single reflector may support many clients and takes but a single live
`stream as input and rebroadcasts it to the many clients connected downstream. However, even for a live broadcast using this
`approach, each client, at some point in the network, requires an individual feed to their end station. Through appropriate
`hierarchical allocation of reflectors live streams can be widely distributed and allow clients to connect to a local reflector to
`minimize the path length of those individual feeds. Reflectors can be cascaded and appear as just another client to an
`upstream reflector (see figure 3).
`
`A live transmitter was designed to capture audio/video and compress the streams in real-time as a source for the live
`broadcast. The stored content client player was modified but remained an extension to a web browser. The player would now
`make its own separate connection to the live feed, as designated by a parameter which gave the IP address for the live feed
`either as part of the EMBED or APPLET tag for the plug-in and Java applet respectively. With a network of reflectors this
`parameter would be set for the optimum reflector nearest the client.
`
`3.1 Technical details
`In the live transmission station audio and video are converted from analog inputs to digital form, compressed and then
`packetized into the Bamba stream format. The packets are then transmitted over a TCP connection that is established by the
`reflector to the transmission station. The reflector manages multiple connections to downstream clients, where clients can be
`other reflectors or actual end-users. Each of these connections is setup by the clients who establish a direct TCP connection to
`the reflector given its IP address. Using TCP/IP allows the connections to easily traverse firewalls and maintain high quality.
`
`Clients may join an ongoing broadcast at any point in the live transmission. The first transmission that the reflector makes to
`the client is the Bamba control header that was broadcast from the live transmitter at the start of the stream. The reflector
`stores this header and sends a copy to the client immediately after the connection is initiated and before sending the live
`stream. To broadcast the live stream the reflector maintains a list of connected clients and replicates every live stream packet
`received from its upstream source to each client that is currently connected downstream.
`
`Multiple broadcast channels can share the same physical reflector node. The reflector node's resources are consumed based
`on demand but upper limits can be set for the number of connections per broadcast channel as well as for the total number of
`connections per reflector. Reflectors can be cascaded and hence the reflector network can be scaled to meet demand. A
`reflector may also be configured for multicast when connected to multicast enabled networks. For example, point-to-point
`TCP connections may be established between reflectors through firewall boundaries that separate Intranets from the global
`Internet. Within the Intranets the reflector can distribute the broadcasts via multicast connections.
`
`The reflector concept also provides a platform in which custom features can be added. For example streams can be
`transcoded from higher to lower bit-rates to accommodate different network bandwidths or client capabilities. It is also
`
`797
`
`PAGE 3 of 11
`
`WEBPOWER, INC.'S EXHIBIT 1017
`
`

`
`possible to have different audio tracks, for the same video feed, and route these audio tracks to different reflectors depending
`on the reflector's local audience preferences.
`
`A hierarchical Bamba reflector configuration is illustrated in figure 3 below. In this example a live broadcast station is
`transmitting to a 'root' reflector in the Internet which in turn is forwarding the signal to multiple reflectors within different
`Intranets. Within each Intranet, the signal is multicast to local playback stations. Modifications to the streams could be made
`locally at each reflector as needed. The lines with arrowheads represent TCP connections and the direction in which the
`connection was made from initiator (connect) to target (listen).
`
`Figure 3. Hierarchical reflector network example.
`
`Using TCP connections, to send these live streams, has advantages from the perspective of firewalls. However it causes
`additional work for the reflector since any attempt to send to a congested downstream connection can block. To ensure the
`live stream is delivered to all other clients this blocking condition is detected and no data is replicated for any congested
`client until the blocking condition disappears. So as far as each client is concerned it must deal with the stream as though it
`has unreliable delivery even though all the connections from the live source are reliable TCP connections. The Bamba stream
`format and client were however designed to run over UDP and can deal with such loss. Indeed joining the live stream at an
`arbitrary point is the case where all the live feed so far is lost -with the exception of the stream header that the reflector stores
`and forwards to ensure the client always gets an initial control packet.
`
`3.2 Reflector network experiment
`The Bamba live broadcast system was designed to support the transmission of live audio and video to multiple recipients
`simultaneously across the web. A key component to the system is the reflector which provides efficient distribution and
`scalability for the system. It has been operational since June of 1996 and has been used to transmit live audio feeds to
`audiences of sizes into the l00000s for events such as the 1996 Olympics, Wimbledon, the Deep Blue Chess matches, and
`even live concerts in Brazil.
`
`The reflector used for the experiments establishes a TCP connection for each feed, both upstream to the source and
`downstream to each connected client. TCP was chosen to allow the reflectors to traverse common firewalls. Thus the network
`of reflectors was superimposed over the existing IP network - it would however be possible to set up dedicated bandwidth for
`each reflector's live input feed to minimize any disruption to that feed. For our experiments the input feed was susceptible to
`network problems, but by only sending one feed over the long distance we were minimizing any disruption.
`
`For example, a reflector network was setup worldwide to allow IBM employees to listen to various events. The IBM CEO's
`broadcast to the IBM employees was one such event. Reflectors were set up both in the USA (Southbury, Connecticut;
`
`798
`
`PAGE 4 of 11
`
`WEBPOWER, INC.'S EXHIBIT 1017
`
`

`
`Raleigh, North Carolina; Austin, Texas), in Canada (Vancouver, BC), and worldwide (Belgium, Croatia, Denmark, France,
`Germany, Hungary, Ireland, Italy, The Netherlands, Norway, Russia, Slovenia, South Africa, Spain, Sweden and UK). There
`were two live encoding stations, one in the USA in Southbury and one in Europe in Belgium. As the broadcast was also being
`televised and transmitted via satellite a local encoding station was also setup in Europe. Employees came to a central web-site
`in IBM and then were directed to choose the nearest reflector. Broadcasts done this way were well received with employees
`worldwide some of whom could now listen to the live audio broadcast where otherwise they might not have been able to.
`
`The above describes a reflector network that was both manually configured and administered and to which clients made a
`manual decision as to which reflector was best to connect to. Further experiments were done which permitted centralized
`management over a network of reflectors. Where, more than one live feed was permitted, reflectors could be brought on-line
`as required and reflector connectivity dynamically altered to optimize the reflector network. To which reflector a new client
`should connect was automated for optimal performance with reflector loading being distributed, managed and adjusted.
`
`4. JAVA STREAMING PLAYER
`
`The Java streaming player consists of a network interface, demultiplexer, audio decoder/renderer, video decoder/renderer and
`Java applet controller as shown in figure 4 below. The applet plays exactly the same low-bit rate Bamba encoded content that
`the native plug-in plays. The Java player can also handle the streaming playback of both stored content and live broadcasts.
`
`When playing stored content the Java applet (streaming player) and media content are loaded onto an HTTP server. When the
`client navigates to the HTML page containing the applet, the Java streaming player code is fetched by the Java enabled
`browser, using the HTTP protocol, and executed locally. The Java applet itself then opens an HTTP (or TCP) input stream to
`play the media content. The Java applet controller implements a VCR-like user interface to allow the user control over the
`playback. When playing live content the arrangement is little different and is described in the reflector section above.
`
`The implementation of the pure Java streaming player was extremely challenging to achieve acceptable multimedia playback
`performance and at the same time kept the code small to minimize applet download time. So the main effort, having ported
`our native code to Java, was on performance improvement, code size reduction and audio-video synchronization.
`
`I
`
`Java Applet Controller
`
`I
`
`Figure 4. Bamba streaming player Java applet architecture
`
`4.1 Performance optimization
`The audio and video compression standards used by Bamba are designed for very low bit-rate multimedia applications. The
`respective decoders contain complicated algorithms that take a significant amount of processing to decompress the data. Java
`is still much slower than the natively compiled C/C++ that we used to code the Bamba plug-ins. Even when the Java VM
`contains just-in-time (JIT) compilation technologies the performance is still slower than C/C++. To achieve an acceptable
`performance for audio/video playback in pure Java the code had to be analyzed and optimized for speed and code size. This
`code optimization was undertaken in three main aspects:
`
`Algorithmic : Use faster alternative algorithms to speed up process
`Use alternative coding methods to minimize code size
`Code size :
`Code speed: Use better programming techniques to maximize performance.
`
`799
`
`PAGE 5 of 11
`
`WEBPOWER, INC.'S EXHIBIT 1017
`
`

`
`4.1.1 Algorithmic optimization
`The video compression used by Bamba is a motion compensated DCT based algorithm. During the process of decoding an
`8x8 block-based inverse DCT transform is applied to every coded block. The inverse DCT is the most computationally
`intensive operation for the video decoding. An algorithm proposed by Arai, Agui and Nakajima [8] is the fastest well-known
`algorithm for performing inverse DCT transformation. This algorithm requires only 29 additions and 5 multiplications for
`1x8 inverse DCT operation if the scaling factor is absorbed into the division needed to dequantize the outputs. We chose to
`use it in our Java implementation due to its superior performance.
`
`Video rendering is also critical to performance since the YUV color space output of the video decoder needs to be converted
`to an RGB format before the frame can be rendered. In our experiment we found that color conversion is even more
`computationally intensive than inverse DCT in Java. To substantially reduce the number of operations we chose to apply
`color conversion only on the changed macro blocks. Figure 5 below shows the relationship of the ith macro block in frame n
`and frame n+l . Ifthe two blocks represent the same portion of a moving object then MBn+l(i) is just a copy of MBn(i) with
`a motion vector applied. When compressing MBn+1(i), the video algorithm simply encodes the motion vector. At the
`decoder, MBn+l(i) is reconstructed by moving MBn(i) using the motion vector. As the block does not change there is no
`
`Framen
`
`Frame n+l
`
`MBn (i)
`
`Er—i::;;-------
`Motion vector for
`the macro-block
`
`Figure 5. Macro-block relationship in successive frames
`
`need to perform a new color conversion and the previously converted block of pixels from the previous frame can be used.
`This is especially important when dealing with low bit-rate video below 64kbps as the prediction error of a large number of
`blocks are quantized to zero due to the bite rate regulation and only their motion vectors are required to be encoded.
`
`We further significantly reduced the number of operations for color conversion by taking advantage of the observation that
`adjacent pixels of an image are highly correlated, especially after quantization in low bit-rate streams. In these cases, we do
`not have to perform the color conversion for each individual pixel.
`
`4.1.2 Code speed optimization
`Even when the Java VM has JIT support, as most do nowadays, the performance of Java is still slower than native C/C++
`code. In our experience we found the following techniques to be very useful for Java code speed optimization. It is however
`important to test the results as any gains in speed are often dependent on the particular implementation of the Java virtual
`machine. Some of the techniques listed below are optimization techniques that are more widely applicable.
`
`It should be noted that the 80/20 rule applies to optimization. 80% of the time is spent in 20% of the code. Java performance
`analyzers are now available to aid this quest for speed and to identify the key routines where most of the time is spent. It
`should also be noted that some of the techniques shown can lead to code that is harder to read and maintain.
`
`Use mt's where possible
`Shorts and bytes lead to slower code due to conversions for arithmetic etc. Java VM has many more instructions for
`ints than for shorts or bytes. This is especially true for our video decoder where pixel values are represented in bytes.
`Using ints instead of shorts or bytes significantly improved performance.
`
`800
`
`PAGE 6 of 11
`
`WEBPOWER, INC.'S EXHIBIT 1017
`
`

`
`Loop invariants, common sub-expressions etc
`Calculate invariants outside of loops, move common sub-expressions into a single calculation.
`
`Unroll loops
`A performance improvement can be achieved by reducing the number of iterations by partially unrolling the loop
`where the number of iterations is a multiple of a known factor. This avoids re-evaluating the ioop termination
`condition on every iteration at the expense of additional code size. Small ioops may be completely unrolled.
`
`Use a local variable in loops
`Using a class member as an index in a ioop is much slower than using a local variable because of the additional
`overhead Java requires accessing a field variable. It is better to copy the value into a local variable at the start of the
`loop rather than use it directly —and update the field after the loop should the value change. Similarly, this can be
`applied to class array members, e.g. make a copy of an array reference into a local variable rather than use it directly
`from the class.
`
`Make methodsfinal where appropriate
`Code can be called directly (rather than indirectly as would be necessary if there was a possibility that the function
`could be overridden in a derived class).
`
`Make function Private/final/static as appropriate
`Small functions can then become candidates for being in-lined thus reducing call overhead (although this may
`increase code size which it may be considered detrimental in some cases).
`
`Avoid System.arraycopyfor small copies
`Although the first thought of an 80x86 programmer may be to use a memcpy() function -even for a few bytes - the
`equivalent use of System.arraycopy may be slower than a ioop (unrolled) copying the bytes due to the overhead of
`invoking the function which is implemented as a native method in the VM.
`
`For example, the following code copies an 8x8 source pixel block to an 8x8 destination pixel block. The
`Systein.arraycopy of Java is used to copy 8 pixels 8 times.
`
`private final void Copy8x8Pelx (mt src[], mt srclndex, mt dest[], mt destlndex)
`mt widthl = FrameWidthDiv2;
`mt width2 = xFrameWidthDiv2;
`
`for(inti=O;i<8;i++) {
`System.arraycopy(src, srclndex, dest, destlndex, 8);
`destlndex += width1;
`srclndex += width2;
`
`The new code below executed in approx. 84% of time above old code when using the JDK1 .1 .4 JIT and in a
`staggering 34% for Microsoft Jview on Win 95 (measurements done on a 486-DX2 66). Pentium figures were not
`quite as good. Note - the code below can be 200% slower than the above old code on a non-JIT Java environment.
`But since most implementations now have JIT support this was not a concern for us (a non-JIT environment would
`not be fast enough anyway)
`
`private final void Copy8x8Pel (mt src[], mt srclndex, mt dest[], mt destlndex)
`mt width 1 = FrameWidthDiv2 - 7;
`im width2 = xFrameWidthDiv2 - 7;
`
`for(inti=0;i<8;++i) {
`dest[destlndex] = src[srclndex];
`dest[+÷destlndex} = src[++srclndex];
`dest[++destlndexl = src{++srclndex];
`dest[-i-+destlndexj = src[++srclndex];
`dest[++destlndex] = src[++srclndex];
`
`801
`
`PAGE 7 of 11
`
`WEBPOWER, INC.'S EXHIBIT 1017
`
`

`
`dest[++destlndex] = src[++srclndex];
`dest[++destlndexj = src[++srclndex];
`dest[++destlndex] = src[++srclndexj;
`destlndex +=widthl;
`srclndex += width2;
`
`Test the results where possible.
`Results differ across the virtual machines. What is best for one VM may not be best for another. Sometimes a
`compromise is necessary to get acceptable gains for all platforms.
`
`Rearrange local variable and/or method parameters
`Java VM has specialized byte codes for accessing the first 4 local stack parameters. These will be used for method
`parameters and then for local variables. Making the most commonly used parameters the first parameters in the
`method list and/or the first declared local variables can both improve performance and reduce code size.
`
`++i versus i+1
`Java VM also has some specialized byte codes for operations on integer numbers 0 though 3. Hence the sequence i;
`i+1; i+2; i+3; i+4 may be better than using i++; i++; i++; i++. However experience has shown that it needs to be
`tested under each JIT in question - sometimes the JIT comes out faster one way than another does.
`
`Avoid use of2D arrays
`It is faster to access a 1D array than a 2D array.
`
`Avoid use ofsynchronized methods where possible
`Using a synchronized method is slower than an unsynchronized one. Try an alternate coding technique if possible.
`
`Avoid creating new objects on the fly
`Try re-initializing an existing object and allocate all objects needed once at initialization time. This avoids invoking
`the memory manager and hopefully the garbage collector too.
`
`4.1.3 Code size optimization
`Code size optimization is very important because the Java streaming player has to be downloaded to the client
`machine before it gets executed. The larger the code size, the longer the download time. Therefore it is crucial to
`reduce the code size to an acceptable level so that the user does not get deterred due to long wait times. As
`mentioned in the previous section, this often is a tradeoff between speed and the code size.
`
`Replace Java compile time array initialization by run time initialization using aformula
`Where an array for a look-up table can be easily initialized by a formula it is preferable to use this method to reduce
`code size. We used this technique to create some look-up tables in the decoders and substantially reduce the code
`size. Java initializes the array at run-rime anyway and each of the unique initializers are in addition stored in the
`class file in the constant pool increasing the download size.
`
`initialize arraysfrom strings
`Where look-up tables cannot be simply generated programmatically, for example codebooks for the audio decoder,
`initialize each array from a string table comprising the initialization values. To do this first remove any initialized
`arrays declared directly in the Java code, e.g. float[] AnArray = { 1.98F, 2.893F, 8.765F, 34.OF, 67.90F ....} . Each
`unique initializer element in Java is stored separately in the class file header (constant pool area) and then when the
`class is loaded each array element is individually initialized with load and store Java byte code. This generates a
`significant overhead to initialize the table over what would be expected for C/C++.
`
`Our alternative is to store the float values as Unicode characters and then read the string and convert it back to a
`float table when the class is instantiated. Since Unicode uses VTFA variable length coding format, an additional
`improvement can be achieved by switching the order of bytes. For example, VTFA variable length coding uses one
`byte to code values in range of 0 — 7F, 2 bytes in range of 80 — 7FF and 3 bytes in range of 800— FFFF. We need 12
`
`802
`
`PAGE 8 of 11
`
`WEBPOWER, INC.'S EXHIBIT 1017
`
`

`
`bytes to present String table = '\uOAOO\uOBOO\uOCOO\uODOO. However, if we change string definition to String
`table = "\uOOOA\uOOOB\uOOOC\uOOOD" we only need 4 bytes. This technique can significantly reduce the code, for
`example our initial audio decoder was 113KB and only 55.84 KB after applying this technique.
`
`Merge class files
`A size reduction can also be made through merging separate Java classes into a single larger class. Whilst this may
`be a backward step in terms of the object oriented structure of the code it is a necessary evil on the road to keeping
`the download time short and the applet 'user' contented. It also improves the performance of code, because of the
`removal of the overhead for inter-class calls.
`
`Obfuscate the class files
`Obfuscation serves mainly to prevent code from easily being reverse engineered by replacing long meaningful
`variable names by short meaningless names. This however has the useful side effect of reducing the class file size
`when string names in the class file constant pooi are made shorter.
`
`4.2 Audio/video synchronization
`Basic multimedia requirements for synchronization are not supported in today's Java environment. The Bamba streaming
`player for Java makes use of sun.audio package to support audio playback. The sun.audio package uses a pull mode operation
`that requires a standard InputStream read() method to be provided as a source data. The read() method is called whenever
`sun.audio needs audio data. However, sun.audio does not provide any feedback about either when or how many bytes in its
`internal buffer have been played out. Consequently, there is no precise control due to this lack of feedback information for
`when the audio data will be played or when it stops. That makes any ongoing time stamp information associated with the
`audio stream virtually useless since once the stream is started no corrections can be reasonably made. Another problem with
`Java implementations can be the coarse resolution of its system clock. For example, we observed a clock resolution in the
`order of 5Oms for a Win95 virtual machine implementation. This coarse system clock resolution also degrades dramatically
`the capability to precisely render video according to the finer grained time-stamps associated with the video frames.
`
`The topic of video and audio synchronization has attracted a lot of attention [10-12]. In general, video and audio
`synchronization requires the knowledge about the exact time of the audio and video data being rendered. It also requires a
`precise clock both at the source and client sites; even better if the client clock can genlock with the source clock. The lack of
`such properties in the current Java virtual machine implementations will make a general solution for the synchronization
`between audio and video extremely challenging, if possible at all. We observed that the delay, between the time sun.audio
`reads the first data byte from the audio stream into its empty internal buffer and the time that this first audio data byte is
`played, stays reasonably constant across platforms. Therefore, we designed a solution for Bamba based on this assumption
`and where the audio clip and video clip start at the same time and