Starting with your own product is tough, especially if you care about the ownership of your product - PaaS solutions are quick and easy to deploy, but terrible when it comes to the latter point.
Which is why we decided to transition towards a more open approach with our in-house tech. An #opensource approach.
rtmp.ts is a media live-streaming server, which we utilise in-house for our own media streaming solution. Is it perfect? No, of course not. It's not meant to be. But it does the job, and does it pretty well. It's designed to be a flexible; the server is split into modules, which can be easily replaced without interfering with the rest of the app (for the most part), the communication between modules is largely based on node's native events-bus to help with that.
It's not very well documented, as it was never designed as an open-source project. That aspect will hopefully improve as time goes on.
Anyone interested in contributing is welcome to.
this project is not a pure RTMP implementation. It consists of modules, each working side by side - not dependent on each other, but rather responding to events broadcasted by one another. Modules should not be cross referenced, should NOT modify each others properties - unless proxied by the parent (the main app). Modules should be seperated by directories, which are their own, seperate environments. An exception to the rule might be a module purely built for the purpose of extending RTMP limitations. you'll probably find a couple of instances where that happens - such as the AUTH module, which is a middleware between the API and the RTMP client, however - those interactions should be limited to minimum. By following such pattern, we end up with a flexible environment, allowing us to switch modules without affecting the workflow of the entirety of the app, as long as…
Top comments (0)