5 Replies Latest reply on Mar 23, 2011 11:01 AM by Michael Thornburgh

    NetGroup vs Non NetGroup video latency


      I've set up a simple video chat application like the sample one available on adobe labs but my version is using NetGroup.


      On the app using NetGroup I am experiencing a period of around 5 - 10 seconds where the received feed is not "live" - there is latency. During this period the audio is out of sync with the video (the audio is behind the video). After this 5-10 second period the video jumps, the latency is removed and the audio is then in sync with the video.


      However occasionally the video feed will freeze for a couple of seconds before resuming (again without latency and with audio IN sync).


      When I use the video chat application which does NOT use NetGroup (such as the one available on adobe labs) the experience seems much better. There is no initial delay, the audio is always in sync and the video never freezes.


      On this basis I am assuming that sending video streams via netStream through a NetGroup is not really suitable for a video chat application however all the documentation I can find suggests it would be better with lower latency etc etc


      Am I misunderstanding something here?

        • 1. Re: NetGroup vs Non NetGroup video latency
          Michael Thornburgh Adobe Employee

          i think you are misunderstanding.


          P2P multicast (using an RTMFP group to send a stream) will usually have much higher latency than the 1:1 P2P mode.  this is the expected and correct behavior.  the latency (and/or jitter) can be up to the NetStream.multicastWindowDuration, which by default is 8 seconds.  the multicast modes are intended for one-to-many distribution  making this mode practial and efficient requires a trade-off with the "time" part.

          • 2. Re: NetGroup vs Non NetGroup video latency
            timdiacon Level 1

            Thanks Michael I suspected that might be the case ;-)


            So if I wanted to build more of a group video conferance application I guess I either go with direct P2P connection where each user sends his video stream directly to each of the other users (no NetGroup) -  there would then become a limitation on the maximum number of people in the group.


            Or I could use NetGroup where there would be no limitation on group size but there would be some trade of either in latency of inconsistent video quality (if I reduced the multicastWindowDuration.


            Is that about right?


            So just out of interest I guess the intended use for multicast over NetGroup would be something like streaming a concert to a large number of people where in reality some latency doesn't matter.

            • 3. Re: NetGroup vs Non NetGroup video latency
              Michael Thornburgh Adobe Employee


              1 person found this helpful
              • 4. Re: NetGroup vs Non NetGroup video latency
                timdiacon Level 1



                Thanks again for getting back to me so quickly. One last question, I think I understand the latency issue and how that is related to the windowDuration.


                However regardless of what I change this too I still get the video intermitently freezing temporarily before resuming again. This generally happens to a far greater extent when there is a lot of motion and audio.


                I'm wondering how I could reduce / eliminate this freezing of the stream. If I increase window duration and so increase latency should this happen less often, or do I need to use a buffer on the stream to help eliminate it? Or something else entirely?





                • 5. Re: NetGroup vs Non NetGroup video latency
                  Michael Thornburgh Adobe Employee

                  a multicast stream can have jitter of up to the window duration.  if you have no buffer on your NetStream to absorb the jitter, then you will see temporary freezes.


                  reducing the multicastWindowDuration can potentially decrease the reliability of the multicast, by allowing less time to get all of the pieces of the stream.  if you don't get a piece before it's out-of-window, the piece is lost, and you'll see for example a video artifact or audio glitch.


                  if your stream doesn't fit in your P2P mesh (the stream is higher bandwidth than the average upload capacity of your peers), then no matter how long the multicastWindowDuration, you will lose pieces and have imperfect playback.  you will also continuously experience maximum jitter.