Skip navigation
adam duston
Currently Being Moderated

Recording multicast RTMFP streams

Dec 19, 2010 5:12 PM

I know this question comes up from time to time, but it's completely unaddressed in the documentation and I'd like there to exist a more authoritative treatment of the subject. Like many other developers, we're trying to record multicast RTMFP streams. We see three options:


  1. Broadcasting clients open two outgoing NetStreams: one for the multicast group through RTMFP, and another directly to FMS through RTMP for recording. One downside to this solution is that now the user has two outgoing streams, so available outbound bandwidth for any broadcasting client could easily become a constraint on video quality.
  2. One can stream to FMS 4 using RTMP and have FMS-side code that records and broadcasts the stream to the multicast group using RTMFP (recommended by JayCharles at I haven't tried this out yet but my guess it that it will have worse video quality than a pure RTMFP solution. Is my concern justified?
  3. Super-hacky solution: one could have flash player running in some kind of virtual environment on a server. This flash player could subscribe to the multicast stream and record the video at a systems level. Has anyone tried a hack as daring as this?


What solution is recommended by Adobe?


It's incredible to me that FMS 4 can't act as an RTMFP consumer, thereby both acting as a multicast node and also recording the video. Can anyone at Adobe comment on this omission in functionality?


Thanks very much,


Adam Duston


Message was edited by: adam duston. I realized that I didn't make it sufficiently clear that I meant multicast.

  • Currently Being Moderated
    Dec 21, 2010 2:12 PM   in reply to adam duston

    Hi Adam,


    The recommended approach to record in this scenario, given that the goal is to multicast the stream into a Flash Group, is for the publishing client to publish its stream to the FMS over its client-server connection, and using server-side script at the FMS, both record and republish the stream into the proper Group at the server. This doesn't have any impact on the video quality, and worse case, may have some impact on total playback latency at subscribing clients within the Gruop but you can minimize that by disabling aggregate messages in your server configs. You can also try tuning the multicastWindowDuration values used by the NetStream instances at subscribing clients (a lower value results is less total latency before playback begins, but may also lead to more visual artifacts during playback if the client isn't receiving the multicast stream from its peers fast enough - a larger value here gives the Group more time to push/pull stream data to this peer) .


    The advantage in this approach is that the hop from the publisher to the server will generally be robust/uncongested and the publisher need only push out a single copy of the stream. Uplink at a client host is generally much more tightly constrained than uplink at a server host. So, when you republish into the target Group from the server, your server-side NetStream can use a larger multicastPushNeighborLimit (default value is 4) than a client host could. This property controls the upper bound on the number of neighbors within the Group that the server-side peer will push the stream to. A larger value here seeds the multicast stream to more peers within the Group faster than you'd be able to do from the client host.


    Hope that helps,


    Mark as:
  • Currently Being Moderated
    Dec 22, 2010 5:10 PM   in reply to adam duston

    When disabling aggregate messages did you also disable message queueing? This shows up in a few spots in the configs.. From Jozsef's recent article:

    function(){return A.apply(null,[this].concat($A(arguments)))}


    ...disable Aggregate Messages and Queuing (by disabling AggregateMessages in Vhost.xml, Queue and AggregateMessages in Application.xml); see also Send aggregate messages in the Flash Media Server online documentation.


    The message queueing may still be introducing more latency in the republish pipeline at the server.


    If you're still seeing multisecond latency, you might want to try setting up the server-side NetConnection and NetStream at the FMS for the multicast republish as soon as you know the small group of collaborating clients has formed, so ahead of the actual publish of the stream to broadcast. Then, all that needs to happen at republish time is the call to attach() and publish() on the multicast NetStream.



    Mark as:
  • Currently Being Moderated
    May 16, 2013 7:46 PM   in reply to adam duston

    i tried your fmstesting serverbroadcast code, in 4min it works well, but after that  the server side p2p connection closes, i can't find the reason, need your help, thanks! 

    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points