6 Replies Latest reply on May 30, 2011 8:39 PM by moongod.gao

    About Flash P2P live streaming from non-webcam sources

    moongod.gao Level 1

      Hello, I am a university student. Our lab is attempting to work on a p2p live streaming using flash p2p features. The media source is not from a webcam but a file from a certain server, which is not directly supported by any of the 4 methods flash player offers(posting, direct routing , object replication,and multicast.) As some of the forum threads mentioned, our method is to use NetStream.publish() a stream and use send("callbackname", data)  to all subscribers that have joined in a NetGroup. So we can use p2p transmission. Now here are our questions:


      1. We know from MAX 2009 that flash p2p camera video multicasting implements pull-push mechanism inside which makes full use of p2p features like buffer map exchange. If we use NetStream.send() API to send non-webcam source data, will it also make use of this pull-push mechanism to spread data among all peers(subscribers) with proper data exchange?


      or more detailedly,


      I saw the P2P Gaming Libs at flashrealtime.com. It uses DIRECT_CONNECTIONS when creating publish-used NetStream in order to send data with lowest latency. My question is if I do not use DIRECT_CONNECTIONS, than when the NetGroup grow large (1000), will those peers that are not direct neighbors to the publisher in the same group relay data to each other using pull-push via buffer map?


      2. I have written a sample app and use send() to deliver data only (NetStream.bufferTime = 0) without camera video and audio. When the publisher sends the data  in a "for()" stantence for 20 times, the subscribers can only receive about 8 of them. But when I set a timer and periodically send them(e.g., 500ms), the subscribers can receive them correctly. My questions are: Is the packet loss caused by UDP unreliability? Can this be solved by setting the NetStream.dataReliable = ture? Can this totally be solved by setting a timer? How to set the delaytime property in timer? Are all data sent are orderedly received?


      I'm very appreciated if you can answer my questions? thanks.

        • 1. Re: About Flash P2P live streaming from non-webcam sources
          Michael Thornburgh Adobe Employee

          1. the P2P multicast (group NetStream) system treats all NetStream data the same, so audio, video, and NetStream.send() messages all use the normal push/pull methods that Matthew described in his session at MAX 2009. short answer to your question: "yes".


          2. i assume this is happening in the DIRECT_CONNECTIONS case.  this is a known bug that will be addressed in a future release of Flash Player.  the problem is that the NetStream.send() queue backs up when the corresponding RTMFP flow buffers fill up.  once that happens, the NetStream queue(s) aren't polled again until a new event adds something to one of them.  normally when you have a camera or microphone attached, the periodic video and audio frames provide a continuous poke at these queues to keep data moving into the RTMFP flows as the flows drain.  i believe the RTMFP flow for NetStream.send() has a buffer size of 128KB.


          the near-term workaround for this problem is to ensure that you periodically add new things to the NetStream in order to poke at the queue processor. without a camera or microphone, the best bet is to use a timer to drive the NetStream.send()s.


          note that NetStream.dataReliable is true by default; that means NetStream.send() data will be sent with full reliablility on DIRECT_CONNECTIONS NetStreams.


          multicast NetStreams are always partially reliable; the reliability is controlled by the NetStream.multicastWindowDuration parameter.  if it takes longer than that to send your data, some must be discarded.  example: the default window duration is 8 seconds.  imagine you have one peer and your link to that peer is 100kbps.  in 8 seconds you can send 800kb, or 100kBytes.  if you send more than 100kB in 8 seconds, not all of the data will have gotten through before the window moves past and it is abandoned.


          note also that as a new multicast stream starts up in the P2P mesh, the first few messages may be discarded in the interest of keeping latency low.

          • 2. Re: About Flash P2P live streaming from non-webcam sources
            moongod.gao Level 1

            Great, thank you for your answer.It's very helpful to my project. Here are my further questions

            1. According to what you said, does it mean all data that NetStream.send() delivers maybe arrive at each peer disorderly?

            2. Currently, can my solution achieve the shortest latency for a live streaming application?

            3. Will new version of FP be able to support live streaming function from non-webcam source in the near future?

            4. I'm also considering perform p2p vod using object replication. But little details have been reported in any materials ever mentioned.

            Can you tell me about the mechanism object replication uses? This may help me know what else should I implement such as

            bitmap exchange and so on.

            5. And can you give some advices or something that I should pay particular attention to when developing p2p vod?

            Thank you very much for your help.

            • 3. Re: About Flash P2P live streaming from non-webcam sources
              Michael Thornburgh Adobe Employee

              1. NetStream.send() data is delivered in the order it was sent, whether in client-server, DIRECT_CONNECTIONS, or multicast mode.


              2. the lowest latency will be achieved with DIRECT_CONNECTIONS.  however, that isn't scalable to large numbers of recipients.  the P2P multicast system trades low latency for scalability.


              3. there are no plans to support a natural NetStream streaming source that's not a camera/microphone.  Flash Media Server can perform that function.


              4. you should never need to implement "bitmap exchange"; the object replication system handles all the communication needed to accomplish its function. typically you will divide a file into segments, giving each one an index number. object replication uses ranges internally, so the index numbers should be contiguous.  nodes that have indices use NetGroup.addHaveObjects().  nodes that want indices they don't have use NetGroup.addWantObjects().  nodes that have objects will send them to nodes that want the objects.  when a node receives an object, it's automatically removed from its "want" set; once the node decides the object is acceptable, it adds it to its "have" set, at which point it can answer requests from other nodes who still "want" it.  eventually every node will have all the pieces and not want any.  for an example, please see Tom Krcha's articles on using object replication:



                 http://www.flashrealtime.com/video-on-demand-over-p2p-in-flash-player-101-with-object-repl ication/


              5. please see Tom Krcha's articles.  for VOD you will probably want to use the "LOWEST_FIRST" replication strategy, as that may allow you to start playing earlier.  for general file replication you'll get better sharing if you use RAREST_FIRST.

              • 4. Re: About Flash P2P live streaming from non-webcam sources
                moongod.gao Level 1

                Now my main concern is whether my solution can meet the needs for live streaming. If I set NetStream.send() to FALSE, it will retransmit data for a limited time. How much is the limited time interval for FP to decide to retransmit data?

                • 5. Re: About Flash P2P live streaming from non-webcam sources
                  Michael Thornburgh Adobe Employee

                  presumably you mean "if [you] set NetStream.dataReliable to false...".  that setting is only effective for client-server or DIRECT_CONNECTIONS RTMFP NetStreams.  when dataReliable is set to false, (currently) the reliability parameters are similar to "UDP-like best effort".  specifically, the data will remain in the transmit queue for one second (or it won't be transmitted at all), and will not be retransmitted if lost after the first transmission.


                  NetStream.send() reliability for P2P multicast is determined by the NetStream.multicastWindowDuration property (just like all other multicast data).  that setting controls how long the system will try to get pieces before giving up and moving on.

                  • 6. Re: About Flash P2P live streaming from non-webcam sources
                    moongod.gao Level 1

                    Sorry for my wrong typing. Now I have understand it. Thank you very much.