For a good number of months I’ve been working on creating a very basic RTMP live video streaming server. Now that I have a very, very basic usable system (after several complete rewrites) I wanted to release it out into the world in case anyone was interested at least.
amf0 - Library with functions for serializing and deserializing data in the AMF0 encoding format. It’s not 100% complete on the spec but it has the core types implemented.
rtmp_handshake - Library that allows systems to perform an RTMP handshake, both as client and a server. It supports both simple and digest handshake formats.
rtmp_session - An abstraction that represents a single peer in an RTMP connection. This is essentially the core brain of an RTMP peer where you give it TCP packets and it spits out events and tcp responses. Right now it is only programmed to work as a server, but the client portion is on my todo list.
gen_rtmp_server - Behavior that makes easy to create your own RTMP server and provides callbacks for your own custom application logic to respond to RTMP events
These have all been put together to create a simple RTMP server. This server allows connections via any stream key and application name for publishing and video playback. It is dead simple but it works well enough to watch video from. I definitely would not say it’s production ready yet in any capacity.
The long, long term goal of this project is to create a completely free and open source alternative to Wowza, and the like. RTMP is just the start, I want to support both input and output of RTSP, RTP, Mpeg-TS, HLS and Dash streams (a secondary goal is to get this to a usable state to make an NVR for my home IP cameras as well).
My next high level steps (outside bug fixing) on the project are:
Allow saving an RTMP stream into HLS fragments with manifest
Create an gen_rtmp_client abstraction to support relaying video out to a secondary RTMP server
Add libraries to parse FLV and MP4 files, and serve them to an RTMP player (vod support)
Thank you for making this and making it available for anyone to use. This is one of those things that I would love to come up with a use case for for me personally, so that I can sit down and use it. Great work on the reusability of these libraries. I’ll definitely keep an eye on this for when a use case jumps out at me.
Do you mean adding a reply with this info or updating the first post with it in it? Cause if it’s the latter I don’t seem to have the ability to do that.
The latter - you should be able to edit the first post as you are on Trust Level 2 (and it only requires TL1). What happens if you click on the pencil icon in the post controls?
Edit: Ah my bad, I forgot to make it a wiki should be ok now
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.
If there is anything in https://github.com/evercam/evercam-server that is of interest to you, then go for it. We used Nginx-RTMP to do the rtsp>rtmp transcoding which has worked well. HLS is also produced. The purpose of the software is as an NVR for IP Cameras. Is this very different to your use case?
It was on my mind to add RTSP re-restreaming as I imagine this will play better & faster on some clients such as Android & iOS. It was also on my mind to see if the jpegs we ingest might be playable as HLS (sounds a bit odd, but currently we’ve 2 modes: HLS or Jpeg and it would be nice to combine them).
This looks fantastic, I am definitely bookmarking this project!!!
Due to a attempted robbery at my house 3 weeks ago I invested in a Foscam NVR system. The NVR software works ok for what it is (outside the fact that it requires an IE ActiveX plugin for the web interface, sheesh). After doing some research and finding the ONVIF specifications and RTSP specifications I was really really really interested in making an NVR system in Elixir.
I put it off because I wanted to focus on one big project at a time and I think the high level goals for what I"m trying to achieve here (with the full service media server) will translate very well with the NVR.
Seeing evercam has made me more giddy than you can imagine. It looks like it’s the complete other piece of the puzzle other than the media server I’m intending to build. If I can successfully make this media server I think our two projects can complement each other perfectly.
Use evercam to coordinate the video streams, use the media server to record and roll them over in HLS (for both easy roll over support and HTML5 playback), allow playback via the media server (one issue I’ve noticed is the RTSP stuff only allows one client watching at a time, so if I have it up on my computer my wife can’t look on her phone), use either project for motion detection (not sure if that’s ONVIF or not but this is something I 100% believe needs to be improved and I think it’s doable from some research), etc…
I can see a lot of opportunity for our projects to work together if I can get mine off the ground. I need to get my butt into gear.
Edit: And just to clarify, the NVR stuff is only a recent use case for my media server. The core use case of the media server was for a media server we can use for my live streaming company. The NVR scenario was just icing on the cake.
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.
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.
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.
should be ok now 
