Just thought I’d update in case anyone is interested.

I’ve now gotten a fully functional RTMP client behaviour working. With that I have created a RTMP player that can connect to an RTMP server and receive audio, video, and metadata for the specified stream key, as well as an RTMP proxy server that allows you to publish RTMP data to it and will publish that video to an external RTMP server.

I still have a little bit of infrastructure work to do (for example to drop packets if the network is getting backlogged) but for the most part in my tests it has shaped up pretty well.

What’s really exciting about this is that the critical parts are in place for my open source media server plans. Being able to receive and distribute RTMP means that I can now start working on a media server that is not only able to receive RTMP and playback to video players, but can also duplicate and redistribute video feeds to multiple RTMP services (e.g. Youtube and Twitch simultaneously).

Taking it further this capability also opens the door to utilize FFMPEG to patch the holes until I can write Elixir native equivalents. For example HLS feeds can be generated by spinning up ffmpeg to pull in the local rtmp feed and create hls renditions of it. Another example is pulling video from security cameras via RTSP via FFMPEG and pushing it into the RTMP server.

Just as an update in case anyone is interested.

Previously I was given the feedback that socket handling should be in its own process for the best performance. At first I was apprehensive because I wanted media data to be sent from publisher to client with as little latency as possible. After doing some benchmarks I came to the conclusion I was doing way too much premature optimization and I should embrace the power of the BEAM VM.

In that vein I did a pretty hefty re-architecture of the system, depreciating some of the previous modules (not totally sure the best way to depreciate them on hex.pm though) and creating the new eml_rtmp library. The code is a lot better organized and easier to follow (imo), though I still have a few areas I personally want to address. It also has better testability I think.

For anyone wondering, the new architecture for server handling has ranch creating a GenServer for the socket handling. After handshaking completes it spawns 2 more processes, a protocol handler process and a server session handler process.

When TCP data comes in it sends it to the protocol handling process. As messages get deserialized it sends those unwrapped messages to the session handler process so it can run it through the core logic processor. It will then send the protocol handler messages it should serialize (which then get sent out over the socket) or it sends events to the parent GenServer to pass back to the implementation of the generic RTMP server (GenRtmpServer behaviour adopter).

The end result of this is I can already see performance increase (and stability) over trying to do everything on one process per connection. Timings seem much better as well, and I still have some more optimizations I want to do.

So after getting some feedback I"m in for a pretty big refactor/rearchitecture of this, so if you do actually plan on using this just outside of the higher level simple_rtmp_server then just be aware that things will probably change in a non-backwards compatible way.

Essentially it comes down that socket handling should really be done in it’s own thread for performance and timing reasons. So I need to split out the input/output parsing from the session, and make the session just react to rtmp messages, and send replies to the socket for serialization + output. After thinking about it a lot I think this will make things a lot more testable and more organized anyway, so it’s probably for the better to do this now if I intend to make this into a bigger product later.

While flash is dying that just means that RTMP is dying for video playback but not for live video distribution. Most encoders almost always use RTMP to send video out and Twitch, Daily Motion, Beam, Facebook, Periscope etc… only accept RTMP ingestion.

Youtube accepts DASH ingestion but if you want low latency video (to facilitate chat with viewers like is common on the consumer platforms) then DASH and HLS are a no go from a distribution standpoint. Not to mention I don’t really know of any encoder that supports it so you’d have to do something like setup a script to push up manifests and video segments as they are completed.

So RTMP has it’s place, and for a media server that may record and relay live video streams it’s important to support it properly.

Added