Just to extend and be original, I wanted to test the video feed exchange over Adobe Stratus, and to my surprise I found that the plumbing code required to bind the feeds to the NetStreams is very similar when working with text chat. In fact when you look at the code, you will find that only two new methods are written to publish and subscribe the video streams

//Used to bind your local camera (webcam) to the VideoDisplay
private function nearId_videoDisplay_creationComplete():void
{
   var camera:Camera = Camera.getCamera();
   if (camera)
   {
      vdispNearId.attachCamera(camera);
   }
   else
   {
      Alert.show("You don't seem to have a camera.");
   }
}

//Used for streaming your local webcam video feed
public function onVideoSend():void
{
     var camera:Camera = Camera.getCamera();
     //var mic:Microphone = Microphone.getMicrophone();
     sendStream.attachCamera(camera);
     //sendStream.attachAudio(mic);
     btnNearIdVideoStream.enabled= false;

}

//Used for displaying remote camera(webcam) video feed
public function onVideoRecieve():void
{
     remoteVideo = new Video();
     remoteVideo.width = 320;
     remoteVideo.height = 240;
     remoteVideo.attachNetStream(recievedStream);
     vdispFarId.addChild(remoteVideo);

}

The two NetStreams, sendStream and recievedStream, is what one would work it. You can practically attache (publish) audio, video and byteArray data to the sendStream, and the remote host can subscribe to your feed. One thing that really makes me interested with RTMFP is the ISP bandwidth cost. Earlier, when AV exchange sites (running on Media Servers like FMS), had to bare the cost of the video feed exchange over their bandwidth, but with RTMFP, they no longer have. With services like Adobe Stratus, which only maintain the session between the two Flash Player 10 clients, and the binary feeds exchanged between the Flash Player 10 clients is at the user’s cost.

Stratus Video Feed App

Below is the source code attached for you to try to and test. Also remember you would need Flash Player 10 installed and two different browser to test out. Also you would need your Adobe Stratus Developer Key which can be obtained here.

Sample Stratus Video App Zip

Adobe Stratus Demo Chat App

I have attached the source code of FB3.3 sdk based chat application which was used by Ryan Stewart to demonstrate here, for code review and how to make it work, use the video to understand. Also note to run the application you will the need the developer key, which you can obtain here. And two different browsers, so that two different Flash Player clients can connect to each other.

SampleStratusChatApp

As I was discussing with my team at office today about collaborative apps, and when I asked “Does someone know here about RTMFP ?”, SOMEONE popped up “Its an upcoming extension to the RTMP protocol”. I had to hold on and say “Vinay I don’t think its an extension to RTMP but instead its a communication standard for a whole different breed of apps”. So after getting back to home, I thought it would be interesting if I could put up a blog post that differentiates out RTMP and RTMFP. So here is what I feel are the differences :

1. Looking at the specifications of RTMP and RTMFP (as they are open source now), the first observation is in the underlying transport layer protocols that RTMP and RTMFP use. RTMP uses the Transmission Control Protocol (TCP), where as the RTMFP uses the User Datagram Protocol (UDP). With the above highlight, it would be necessary to look at TCP and UDP to understand the what RTMP and RTMFP offers.

As we know TCP is the most commonly used protocol on the Internet. The reason for this is because TCP offers error correction. When the TCP protocol is used there is a “guaranteed delivery.” This is due largely in part to a method called “flow control.” Flow control determines when data needs to be re-sent, and stops the flow of data until previous packets are successfully transferred. This works because if a packet of data is sent, a collision may occur. When this happens, the client re-requests the packet from the server until the whole packet is complete and is identical to its original.

On other side UDP (User Datagram Protocol) is another commonly used protocol on the Internet. However, UDP is never used to send important data such as webpages, database information, etc; UDP is commonly used for streaming audio and video. Streaming media such as Windows Media audio files (.WMA) , Real Player (.RM), and others use UDP because it offers speed! The reason UDP is faster than TCP is because there is no form of flow control or error correction. The data sent over the Internet is affected by collisions, and errors will be present. Remember that UDP is only concerned with speed. This is the main reason why streaming media is not high quality.

Well if UDP is not suitable for streaming media, then why is chosen for RTMFP ? To answer this lets look at a scenario, if I am gonna use the TCP protocol for streaming audio and during transmission a 300ms audio was lost, then as per the mechanism, the media server will reinitiate the streaming from start. This would get painful if each time some data is lost. This is reason why UDP is used, even if I loose the 300ms audio, the gap is not that large that I have to start over again, so the drop packets are compromised and I get the whole data packet.

2. Communication model when using RTMP and RTMFP is different, when using RTMP, clients when needed to interact with each other has to route messages through the Flash Media Server, which means that a direct connection between the user’s flash players cannot be made. But with RTMFP the scenario is different, because the protocol has been designed to build collaborative apps, Adobe made it possible for individual Flash Player clients to connect with each other and pass messages while maintaining the session with the media server or the Adobe Stratus service. Below figures, illustrate the two different communication models.

RTMFP Communication Model

RTMP Communication Model

3. Bandwidth consumption is much better when using RTMFP as it avoids much of the client-server communication for inter-client communications as it prevails in the RTMP implementation.

4. Security and firewall restrictions are always part of the application design considerations, RTMFP fails to impress at this point, because most of the firewalls implemented in corporates are not UDP port friendly. So when RTMFP and RTMP are to be considered, the implementation considerations are always different for both the protocols.

5. RTMFP cannot be used for broadcasting high quality live video or swarming, it can only connect and stream live audio and webcam, whereas the RTMP can be used to stream high quality video, audio and webcam (from different sources).

In coming time the RTMFP protocol, I feel would evolve the way P2P or C2C applications are built using a common communication framework.