RTMFP:Developing peer to peer applications with Flash Media Interactive Server


Adobe always manages to excite me with the introduction of new features into the Flash Media Interactive Server. I must confess though that none has excited me in recent times as much as the introduction of the peer to peer protocol RTMFP which has now has public viewing in the Adobe Stratus Cloud server. True RTMP has managed to carry us this far but, the inherent problems of a TPD hub server to distribute content was becoming all too obvious to see. In truth the client to server to client model was just no longer efficient enough to cope with the expectation of a user base that now expects all video to be desktop application quality. True a myriad of deployment techniques and the geo-location of server clusters helped to solve this problem somewhat but, at a price too costly for the average user. Problem now solved with the real Time Messaging Flow Protocol, a UDP protocol that allows Flash Player 10 to communicate client to client. Security is maintained by the server which acts a a mediator to authenticate and exchange data keys between consenting users. The result is startling. A video chat application I built with a camera encoded value of 960 x 720 x 10 streamed with virtually no lag in motion or audio. My test partner was my long time friendand tag team partner Prof Bill Sanders and we talked for at least 90 minutes with no change in quality whatsoever. The screen shot above was at full screen.


Development techniques are however not the same as defacto FMIS development as you have access to only the main classes Stream/NetStream, Application and Client (I may have missed some out). Notably you do not have access to Remote Shared Object interaction (for the moment). This makes for some interesting jiggery-pokery to distribute data to multi-users. In this, I have found the Application.broadcastMsg,NetStream.send methods as well as data binding techniques invaluable. Without a shadow of a doubt other creative ways of routing the data will show up as people get more comfortable. In addition you have the same old echo problems so a headset is still absolutely necessary. You also cannot access the raw data of the streams audio and video (for the time being, I hope). Visit http://labs.adobe.com/wiki/index.php/Stratus for more information. You can procure a Developer key there and start to try out the protocol for yourself


I will put up the code for this video chat application once I've cleaned up the mess I created in developing it as well as a demo application you can try out.

4 comments:

Rt_Bower said...

Good discussion of the new FMS. I am particularly interested in the peer-to-peer capabilities. Any chance I may view your code as an example?

mrbinitie said...

I'll put up the client side of the code. An NDA prevents me from putting up the server side code. I'll include that once that is cleared.

Jvy said...

Hi,

Would like to know how does the quality of the video as compared to if you are using Skype. As far as I know, we can only use Flash Sorenson Codec which is H.263 quality.

Btw, the screen shot you posted showed decent quality. And, can you also share what kind of bandwidth you are using to have that kind of 90-minutes video quality. I presume you are not on LAN talking to the professor.

Many thanks.

mrbinitie said...

Hi Jvy, Compliments of the Season. I assure you I was not on a LAN, I'm in London and Bill is in New Hampshire Conn. As I'm sure you know the final output of the video is dependent on a whole raft of elements, camera hardware, lighting etc. All these unfortunately give a whole range of results.
Having said that I definitely prefer the video quality of the new player to that of Skype especially when using large video sizes as I used. I can no longer remember the BW implications so I'll do a test today and report back.

My Instagram