Page 1 of 2 Last week at the Macromedia MAX 2004 conference in New Orleans, Chris Hock and Srinivas Manapragada of the Macromedia Flash Communication Server (aka Comm Server, FlashCom, or FCS) product team conducted a 30 minute discussion regarding potential new features that might find their way into the next major release of the product. While I won't cover the details of the discussion in this article, I would like to conduct a "state of the union" review of FCS. Before you go any further, though, you should watch the recording of the interview, and review the coverage that other top FlashCom developers have written:
Comm Server extends the features of Flash Player 6 and higher considerably. You can share data simultaneously among several users, enabling real-time chats, efficient synchronized data transfers, multi-player games and collaborative environments. The most advertised feature by far is Comm Server's capability to stream live audio/video feeds or broadcast pre-recorded video clips (so long as the clips are compressed in the FLV file format). If you polled a range of Flash designers and developers, those that know anything about FlashCom know it's a streaming audio/video streaming server.
If you have taken a look at Macromedia Breeze Live, you might see some similarities. Breeze Live enables users to participate in live audio/video-enabled conferences, text chats, and screen-sharing. As such, it should come as no surprise that the heart of the Breeze Live server software is the Comm Server engine. With the exception of screen-sharing, which is the ability to share your desktop window with other connected users, a team of Flash developers equipped with a Comm Server account could feasibly re-create many of the features shown in Breeze Live. And herein lies the problem: how can Macromedia continue to market FCS to its development community while withholding other features from future revisions? I believe the short answer is that they can't. Thus far, Macromedia has gone to great lengths to push the live and pre-recorded audio/video streaming services that FCS provides, while the company tries to gather market share for its own custom Comm Server application, Breeze Live.
While you can create powerful feature-rich multi-user experiences with the current release of Comm Server (1.5), there are a few areas that could use some improvement. A few of these limitations were addressed at the MAX Get Together, but some were noticeably absent, or their necessity was minimized. Here's my short list of wishes for the next version of Flash Communication Server.
As I learned during the writing of my book, Macromedia MX: Building Rich Internet Applications (Macromedia Press), you can't keep two separate audio/video streams in sync with one another with any guarantee. For example, if you create a live video conference room with two participants and record each of the live streams on the Comm Server, the latency of one participant's audio/video packets can vary substantially from the latency of another participant's packets. (Latency is the delay between sending a network packet from a client and receiving the same packet on the server.) Comm Server doesn't take latency into account while recording a stream; due to the way that Comm Server records streaming data, packets can only be appended to the existing stream file as they are received.
You can think of this problem in another way: suppose you had a deck of cards representing all of the packets of your audio/video stream. The cards (packets) have a finite thickness (or count). If you were to drop the cards one at a time to the ground into a neat stacked pile, the interval between each card hitting the new stack will vary. The magnitude of the variance depends on how many cards you drop at a time. Now suppose you had two people dropping cards into their own stacks (or sending a stream from each person's computer), starting at the same time. It's highly likely that one person will finish rebuilding the stack (or streaming their packets) before the other. The stacks are the same thickness when the task is done, regardless of how much time was spent. Once the cards are stacked (or in the case of packets, recorded to a stream file) you've lost any information related to the separation in time that occurred while the stack was being built. As such, it would be impossible to replay both stacks being built in exact real-time; the variances in transmitting and receiving the packets is lost.
So, what can Macromedia do about this problem? I believe there are two possibilities: one involves the way in which individual stream files are recorded, and the other involves a new type of stream. The first potential solution is to record the latency between packets received by the Comm Server into the stream file. If frame 1 of a video stream was received at 0.00 time and frame 2 was recorded at 0.05 time, the stream would "remember" the 5 second delay between frame 1 and 2, pausing frame 1 for 5 seconds on playback. Maybe this could be a new attribute added to the NetStream.publish() and NetStream.play() methods, a Boolean value indicating whether latency delay should be recorded/played, respectively. The other alternative is a "mega" or manager stream, to which you could subscribe one or more streams. So, if you were to begin the recording of two live streams, the two individual live streams would be recorded the traditional way (one packet simply appending another packet) while the mega stream records the latency of each stream's packets. If you want to replay the experience of both streams, the mega stream would be played back and would manage the playback of the two recorded audio/video streams. In practical terms, the mega stream would be a new variation of the FLV format. A two-person video conference would be recorded as one stream file, made of three parts: the mega stream track and the two audio/video tracks of the participants.
Another confounding factor that affects the successful synchronization of two or more recorded streams is buffering. Currently, the Flash Player does not have the ability to retain data in the buffer while a stream has paused, stopped, and started playing.
Keywords
Flash Communication Server, FlashCom, FCS, Comm Server, streaming, ASC, MAX
