Skip to main content
A
Anonymous
August 19, 2011
Answered

P2P Settings for Flash Media Server on Amazon AWS

  • August 19, 2011
  • 2 replies
  • 2564 views

Hello,

I'm trying to develop a p2p (RTMFP) webcam chat application with AS3 and FMS. For test purposes I've been using "rtmfp://p2p.rtmfp.net" and now I'll use FMS on Amazon AWS.

What I couldn't understand is which application type should I use on FMS? There is four preconfigured application types on FMS, these are live, livepkgr, multicast and vod. I guess live or multicast but I cannot choose between them, I'm a little bit confused. Or maybe I don't have to setup any application? Can you help me about that?

My application scenerio is; a user will connect to FMS and webservice and will get other person's farID from webservice and will be on audio/video chat with remote side as he sends stream. (with one person) Pretty much like sample Cirrus application.

Also I've another issue, I also want to publish one person's (consultant in my case) video to several people (customers) at the same time (one to many), customers won't publish any video or audio, they'll only watch and hear consultant. Can I use RTMFP and P2P for that? I guess it will insanely increase publishers bandwidth needs, so should I use streaming on FMS and let customers to get stream from FMS?

Thanks in advance

    This topic has been closed for replies.
    Correct answer Michael Thornburgh

    any of the built-in applications that work with RTMFP will perform the P2P lookups similar to Cirrus.  if you make your own application you could use it for peer ID exchange and not bother with the web app.

    you could use P2P multicast for your 1-to-many video scenario.  in that case the peers will help redistribute the stream to other peers; the original publisher doesn't need to send a separate copy to each subscriber.  peers will need (on average) at least 1x the stream bandwidth in upload capacity for that to work effectively.  in practical testing we've found that the original publisher will need to be able to upload about 3-5x the stream bandwidth for effective distribution into a P2P group, independent of group size.

    if 3-5x upload at the original publisher is impractical, but 1x-ish at each peer is practical, you can use P2P multicast publishing from FMS.  this can reduce the bandwidth needed at FMS from 1x per subscriber to about 3-5x (ish) independent of number of subscribers.  the "multicast" FMS app and multicast stream configurator page can be used for that.

    i covered using the "multicast" FMS app and doing P2P multicast in my lab at MAX last year.  you can download my presentation, exercise handout, and exercise source code from the MAX site:

       http://2010.max.adobe.com/schedule/by-session/#filter_speaker=036c28fe-ae9f-4907-b880-47af677168b9

    2 replies

    A
    andym62
    Participant
    August 29, 2011

    Hi-

    I was just curious how you made out with your P2P Webchat application - ie. performance, audio, etc...

    We are currently developing a Video Chat application for our service and are wondering if we should stay with the Adobe Media Sever and use RTMP or use the enterprise server with RTMFP?  We are having some issues with audio echo and delay with the RTMP solution so far.

    Thank you

    M
    Adobe Employee
    Michael ThornburghCorrect answer
    Adobe Employee
    August 19, 2011

    any of the built-in applications that work with RTMFP will perform the P2P lookups similar to Cirrus.  if you make your own application you could use it for peer ID exchange and not bother with the web app.

    you could use P2P multicast for your 1-to-many video scenario.  in that case the peers will help redistribute the stream to other peers; the original publisher doesn't need to send a separate copy to each subscriber.  peers will need (on average) at least 1x the stream bandwidth in upload capacity for that to work effectively.  in practical testing we've found that the original publisher will need to be able to upload about 3-5x the stream bandwidth for effective distribution into a P2P group, independent of group size.

    if 3-5x upload at the original publisher is impractical, but 1x-ish at each peer is practical, you can use P2P multicast publishing from FMS.  this can reduce the bandwidth needed at FMS from 1x per subscriber to about 3-5x (ish) independent of number of subscribers.  the "multicast" FMS app and multicast stream configurator page can be used for that.

    i covered using the "multicast" FMS app and doing P2P multicast in my lab at MAX last year.  you can download my presentation, exercise handout, and exercise source code from the MAX site:

       http://2010.max.adobe.com/schedule/by-session/#filter_speaker=036c28fe-ae9f-4907-b880-47af677168b9

    A
    Anonymous
    August 20, 2011

    Thank you very much Michael! I have a little more to ask, can I use "multicast" FMS app for also one-to-one RTMFP connections? Or should I use different "FMS app" type for one to one connections?

    And, for peer ID exchange I use my web service and I saw same in Cirrus sample application but you said I should not bother with the web app (in fact I use AMF by the way if makes any difference), so is that means I can handle this without using web service and how?

    I'll download your presentation and samples

    Thank you very much again

    M
    Adobe Employee
    Michael Thornburgh
    Adobe Employee
    August 22, 2011

    you can use the "multicast" FMS application for 1:1 as well.

    you may choose to use FMS, and write some server-side script of your own, to do peer ID exchange instead of using a web service.  that's up to you.  the semantics of doing it with FMS are cleaner, since FMS knows the peer ID of each connected peer, and especially can tell immediately when a client disconnects.

    FMS server-side scripting is out of my area of expertise, but the source code for the "live" and "multicast" apps is included with FMS, and you can copy one of those and modify it to suit your needs.

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices