Skip to main content
A
Anonymous
December 16, 2010
Question

Recording multicast RTMFP streams

  • December 16, 2010
  • 1 reply
  • 3794 views

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 http://forums.adobe.com/thread/736733). 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

http://www.linkedin.com/in/aduston

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

    This topic has been closed for replies.

    1 reply

    S
    seth_hodgson
    Participating Frequently
    December 21, 2010

    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,

    Seth

    A
    Anonymous
    December 22, 2010

    Thanks, Seth.

    I created two projects, one which uses solution #2 (have server record and then publish to group -- this is the solution that you recommended), and another which uses solution #1 (client opens rtmp connection to FMS for recording plus RTMFP connection to group for broadcasting). I put the code here in case anyone is interested in reproducing my experiment: https://github.com/aduston/fmstesting .

    Now, this is far from scientific but, to make things as exact as possible, I'm using FMS 4 Dev on a small EC2 instance running CentOS. I have an Average Joe network connection -- I just measured my upload speed at 370 Kbps (46 KBps) [EDIT: wow, my upload speed is relatively very slow: http://www.netindex.com/upload/ ].

    When having the server publish to the group, my computer is uploading about 16-20 KB of data per second. I didn't hook up my mic properly, so this is just a 320x240 video, I believe. I disabled aggregate messages as you suggested. I observed a latency of about 2.5 seconds between publisher and subscriber. When I set multicastWindowDuration to 0.1 I observed a latency of 1.8 seconds. The video quality looked pretty good to me in both cases.

    When recording via rtmp and publishing via rtmfp to a group simultaneously, my computer is uploading about 37-40 KB of data per second. This is pretty close to my maximum upload speed but it's not quite exceeding it. The latency was so small that I couldn't measure it with my stopwatch. The video quality looked slightly worse -- some blockiness -- but still good enough.

    The ultimate solution here, of course, would be to have FMS acting as a group peer and recording the video. Of course the server-side NetStream can only publish, not subscribe, so I understand that this can't be done with FMS 4. It would be pretty cool if Adobe were to release a product to make this possible.

    Thanks again for your advice,

    Adam

    S
    seth_hodgson
    Participating Frequently
    December 23, 2010

    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:

    ...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.

    Best,
    Seth

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices