3 Replies Latest reply on Jul 18, 2012 12:04 AM by Michael Thornburgh

    using cirrus to go one way only


      I've been using Adobe's Flash Media Live Encoder for some time. But the latency is too great, so I found Cirrus and now have it all operational.


      The biggest obstacle was getting the P2P operating using the cgi script. But that's all behind me now.


      At this point, looking at the various renditions of P2P code that are on the web that require the users to manually exchange their usernames, it dawned on me that it may not be necessary to exchange names since I am only streaming one way and not doing a real P2P.


      If the p2p were divided between two kinds of users... the primary streaming site.. and the "client" receiving sites, It seems like it would be possible to create a one way streaming without having to exchange usernames... ie have the primary use one version of the program and the clients use another. That way the stream server's name could be hard wired. So the clients, as in the case of Live Encoder, have no role to play in the connections.


      Is this possible or am I missing something. Will cirrus still distribute if the stream is only one way?



        • 1. Re: using cirrus to go one way only
          Michael Thornburgh Adobe Employee

          if you're talking about using the 1:1 APIs as illustrated in VideoPhoneLabs, then the subscriber must still know the peer ID of the publisher. and the publisher's peer ID is ephemeral; it is new for every new NetConnection, and it is cryptographically pseudorandom and cannot be influenced or predicted.


          so the subscriber(s) still need some way to learn the ephemeral peer ID of the publisher, perhaps via a web service or something. a one-way exchange will probably be easier.


          of course, in this model the publisher is sending a separate copy of the stream for each subscriber who's watching it. this is not scalable to more than a few subscribers.


          there's also P2P multicast, but the latency there will be even higher than with FMLE and FMS, and the stream must fit into the average *upload* capacity of the subscribers. but as long as you stay within the average upload capacity of subscribers, you can scale up indefinitely.

          • 2. Re: using cirrus to go one way only
            joedart Level 1

            Thanks Michael. I've experimented a little and can now clearly see that

            saving an old number doesn't work. No way to activate it again. The word

            'group' came up in one of the older programs and I tried it in cirrus.

            It does not appear to use a web service (at least not a visible one) It

            only exchanges text although it displays the local cam. Is a 'group'

            some previous scheme to exchange usernames?


            An idea I tried was to write two versions of the program, one for the

            publisher and one for the subscribers. Run the publisher program first

            and copy its number into the code for the subscriber version. Keep the

            publisher program running. Compile the subscriber program with the

            publisher's number in the code. As long as the publisher does not shut

            off the program, subscribers can run their version and connect. Stupid,

            yes, but if one is desperate, it does work.


            Also, there seems to be a 320X240 size limit on the video images

            transmitted. No matter which parameters I change the image (distant peer

            image) remains the same size. I can adjust the size of the local video

            image ok, but the incoming image is pretty small. Is that a limitation

            to p2p?

            • 3. Re: using cirrus to go one way only
              Michael Thornburgh Adobe Employee

              there is no limit to the size of video images you can send with P2P. you set the capture resolution (and fps) with Camera.setMode().


              "RTMFP Groups" refers to self-organizing P2P mesh networks. these meshes support several different communication modes which are distinct from the 1-to-1 P2P that you have seen with VideoPhoneLabs.  most of these modes are accessed via the NetGroup object. however, you use NetStream, only constructed with a "group specification" instead of a peer ID (think of it like a "peers ID"), for P2P multicast streaming (since NetStream is the natural interface for video streaming).


              for more information about RTMFP Groups, i strongly recommend watching Matthew Kaufman's session from MAX 2009 and my session from MAX 2011:





              and also to go through my labs from MAX 2009 and 2010:



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


              the real MAX 2009 archive site seems to be offline, so i put copies of the materials on my computer.  the lab from 2009 is probably more relevant, especially for getting started with multicast.


              also, see the files i attached to this thread, which are slightly modified versions of my MAX 2009 lab: