Problem:

       Streaming video solutions currently offered not effectively scalable. Existing endeavors in the realm 
of scalability have been largely insufficient and not suited for the smooth, reliable playback required by 
the medium.  The two biggest providers of streaming media protocols and software are currently RealNetworks 
and Microsoft.  Microsoft's MediaPlayer platform is currently ill-suited for scalable streaming video, as 
the only bandwidth selection it offers is at stream "download-time" (users may select their bandwidth when 
they initiate their streaming session) and it does not adapt to available bandwidth during stream playback at 
all.  RealNetworks' RealPlayer scales the stream to available bandwidth during playback by dropping frames, 
which often degrades user experience beyond what is acceptable for the medium.



Goals:

        Create a streaming video protocol with congestion control that doesn't extensively degrade the viewing 
experience in spite of network congestion. Also create a communication protocol between multimedia client and 
server necessary for implementing congestion control. Like the TCP-friendly protocol the congestion control 
should react appropriately to packet loss.





Approach:

        Existing Approaches are moving in the right direction by attempting to scale back video quality to 
reduce network load. However, most of these methods require separate video streams of differing quality to 
be transmitted concurrently over the network. This approach is inefficient, as it tends only to increase 
network congestion and is unsuited for real-time scaling. Our approach splits a single stream into components 
that can be quickly reassemmbled by the player. Each component builds on the quality of the last component, 
minimizing superfluous transmissions. Our research found that a similar approach was used to optimize image 
downloads during the early days of the internet when bandwidth was more severly limited.  One protocol 
developed in this vein was the image interlacing used by the GIF image format, in which an image was broken 
down into interlaced components.  A more intelligent approach was taken by the JPEG group, whose progressive 
JPEG format divided an image into several progressive components, each of which could be used by the JPEG 
decoder to display a full image. Our approach uses the progressive JPEG standard to encode each frame of 
video as a set of component files.  On stream initiation, the stream server sends all of the frame components
 for each frame to the stream client.  If the client is not receiving all of the frames quickly enough to 
show smooth video, it notifies the server, which then scales down by sending fewer frame components for each 
frame.  If the client experiences a stream buffer surplus during playback, it notifies the server, which 
then scales up by sending more frame components for each frame.  Thus, the protocol allows for real-time 
quality scaling of the video stream.



Results:

        We were able to successfully create a video stream server and client that make use of our protocol. 
The format is limited because it only uses frame based compression and not frame to frame motion compensation 
(as is used in the MPEG specification). However, since MPEG and its derivative formats are based on the JPEG 
specification, our approach could be used to create a progessive scalable MPEG protocal.