This page contains documentation describing various aspects of the
project, and links to related material.
Proposed Architecture
Ok, proposed architecture is a little more than what I actually have at the moment. More like the general layout of how we should split up our efforts. Below is a diagram I whipped up in xfig describing my view of how the various parts of the system will fit together.
As you can see, the communication paths are fairly restricted (which is a good thing). The server and protocol are split for a few reasons, (1) in case RealNetworks ever decides to enforce intellectual property rights on RTSP we won’t have to rely on it, and (2) to allow for new protocols (say from academic research) to be cleanly integrated in the future. SRM refers to “Scalable Reliable Multicast” which is under development by the
MASH project at Berkeley. Also, we can allow for protocols that manage two-way communications without building those concerns into the server (so we if someone wants to implement a video conferencing protocol, all they’d need to do is build a codec and protocol, then run both server and client on the same machine).
The dashed line in the codec class is to indicate that it’ll probably be split (somewhat cleanly) into server side encoding/client side decoding, though it’s logically a coherent package.
The path from the server to the codec is so the server can tell the codec the bandwidth it has, and the codec can transmit back the appropriately compressed data. This way we avoid building any specific knowledge of codecs into the server.
Notice that the client and the player are separate entities. The sole purpose of the client is to receive data from the server, and coordinate transmission. The client will talk to the codec to have it decompress the data, and the codec will tell the client if there are any problems with the data.
The path from the client to the player is one I’m uncertain about. That could be from the codec to the player instead (and
probably should be). The player may vary depending on what kind of data is being transmitted (say a streaming VRML) so we shouldn’t try and make a “one size fits all” solution, though we obviously will provide a default player – we just shouldn’t mandate its use. And there may be some “playing” that won’t be worth our while to support. With streaming 3-D worlds, perhaps some enterprising maker of VR hardware (gloves, helmet, etc) would want to write a player that actually uses all that, while the default player would only display the graphics on the screen.
Correspondence
Anemail that discusses requirements .
References
A list of references to books about C++, software engineering, and digital signal processing. Mainly of interest to people who are thinking of working on Free Expression.
The localCVS Repository
contains the sources of a number of other free projects (academic and otherwise) we will be ravaging for code.