1 Reply Latest reply on Dec 17, 2012 6:30 PM by Michael Thornburgh

    Live video application for multiple users with RTMFP

    rombooth1 Level 1



      We developed a live video application in Flex that uses RTMP. In one session up to 5 users are able to publish their stream and up to 20 users can join a group. For saving bandwidth costs and making use of lower latency with UDP we check RTMFP. From reading the documentation it seems that RTMFP multicast is the way to go.


      Our frist results and additional research surfaced two 2 issues:

      - Streams have a live delay (which seems to be multicastwindowduration + buffertime) that takes up to 30 sec to disappear but seems to increase again

      - The application allows one user to change the size of a published video (camera.setMode). This causes a freeze with RTMFP for the publisher and all subscribers. Changing the size several times can cause to make the video work again for the publisher and subscriber (some bugs are already reported here)


      For solving these issues I wonder:

      1.) Is RTMFP multicast able to deliver a low latency solution that is needed for face to face v/a communication?

      2.) if yes - are there any settings suggested by Adobe for the RTMFP NetStream multicast properties (like multicastwindowduration property) and if not can you give me some hints what would work for reduce the latency that face to face communication gets acceptable?

      3.) How to deal with the setMode issue - does this happen because I misconfigured RTMFP or is this API not supported? Will unpublish and publish solve the issue (what api series do I need to use to do so?)


      Best regards,


        • 1. Re: Live video application for multiple users with RTMFP
          Michael Thornburgh Adobe Employee

          1) any practical use of P2P multicast will have a delay measured in seconds. it shouldn't go to 30 seconds unless you have a large NetStream.bufferTime.


          2) i strongly recommend against changing the multicast stream parameters. they all interact with each other. decreasing the window duration will decrease the effective reliability of the stream, by reducing the amount of time to receive all of the fragments of the stream as they pass through the P2P group -- especially when people join or leave the group, which can disrupt the low latency "push" trees that are constructed in the group.


          3) you should be able to change the encoding parameters on the fly without a major disruption. are you using H.264 or Sorenson Spark?  it's possible that your camera doesn't like to have its capture size changed and it is freezing temporarily.  i'm not having any trouble changing the capture size with my camera (and using H.264).  i recall there being some issue with changing the frames-per-second on the fly (at least some time ago, and i don't remember what the issue is) -- there was enough of an issue that i disabled it in my little app while actively publishing.