How to push a webrtc channel to RTMP?

[fightingbamboo]

If a chatroom has a very large audience, it is easier to do CDN acceleration using RTMP

[codeslinger]

@fightingbamboo I don't speak for the ion project at all, so the following are purely my own thoughts:

You could add RTMP protocol support to ion, but that wouldn't be sufficient to allow you to stream a WebRTC-based conference to a typical RTMP ingestion endpoint, such as those used for Internet broadcasting. These kinds of RTMP endpoints typically require there be only a single video and a single audio stream being sent. (e.g. see Twitch, Youtube, etc)

In order to be able to support that, the "conference focus" (the server to which all of the WebRTC peers are connecting, e.g. ion) would have to continuously:

• decode each peer's audio stream, mix them, and then encode the result into a single composite audio stream, and
• decode each peer's video stream, composite them all together in some layout, and then encode the result into a single composite video stream

These composite streams would then have to be packaged up into a container format (e.g. FLV, MP4, etc) and sent over RTMP to the ingestion endpoint.

Doing all of the above has several downsides:

• It is very expensive, computationally, and greatly lowers the vertical scalability of your focus servers.
• It is fundamentally at odds with some other features that you might also want, primarly end-to-end encryption of media by peers.

More fundamentally, doing this would make ion a form of "MCU". (multipoint control unit) ion has, however, specifically been implemented according to an "SFU" (selective forwarding unit) model, which is a much cheaper and more scalable form of focus, as well as being more suitable to a wide variety of today's popular clients. (Web browsers, mobile phones, etc)

MCUs do have their uses; in addition to supporting the broadcasting use case you've mentioned, they can also be used to support low-powered and/or legacy peers that cannot handle multiple audio or video streams. Certainly, some of the code in ion could be used to make such an MCU, as well.

My take: This is all to say: this functionality doesn't fit very well into the current state or the implied direction of this particular project. It is not clear that ion itself should try to become an "all-in-one" solution that includes both SFU and MCU functionality, as doing so would bifurcate focus and make it more likely to end up as suboptimal for either workload.

Having said all of that, I'd love to hear what the ion maintainers think about this subject.

[leewardbound]

@codeslinger Thanks for replying, this one slipped past my radar!

You nailed the technical complexities part - specifically, ion doesn't have a compositing/muxing component right now. RTMP input/output is actually on the "roadmap" as part of the architecture diagram -- but before it's realistic to build an ion component, I think the list of needed features to finish includes SFU-relay, an AVP-video-mux pipeline, and the planned live node (which will be the primary endpoint for input/output of external formats like RTMP and HLS). It will likely not be supported "soon" as there's a lot of ground to cover first. Note that this is just my rudimentary understanding regarding ion and RTMP roadmap, and everything is of course subject to change.

HOWEVER, @fightingbamboo -- please note that there are MANY projects which try to do this for you, for other conferencing services. Mostly, what they do is launch a headless browser with xvfb, join the meeting as a "ghost", and use gstreamer to push the video to RTMP -- this can be VERY EXPENSIVE, and I've tried a lot of these solutions, and I'm sad to say I don't have one I like to use with ion (yet). In fact, I can't even get all of these to work all of the time, good luck. All of these are designed for other projects and will require lots of modifications to even attempt them with ion, "at your own risk", "your mileage may vary", etc, but if you really want to dive down this rabbit hole, here's a list of places to start reading --

https://github.com/jitsi/jibri

https://github.com/jibon57/bbb-recorder

https://github.com/hipoloco/bbb-recorder

https://github.com/muxinc/webrtc-rebroadcaster

https://github.com/MuxLabs/wocket

If you make any progress on this, I'd be very eager to know about it!

[fightingbamboo]

Our team implemented an audio mixer based on ion for our commercial saas product. Thanks to the ion team for creating such an excellent open source product.