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.
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.
1 person found this helpful
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?
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.