Why We Built Red5 Pro: An End-To-End Solution

Reflecting on 2015 and what we’ve built over the last couple of years, I started thinking about Red5 Pro and the reasons why we built it in the first place. So I figured I should write a post.

Why did we spend so much time and energy building this thing? Not only did we see that there was a trend of people wanting to make new mobile experiences based on live streaming like Periscope and Meerkat, but we also weren’t happy with the developer tools available to build these kinds of experiences. We saw two approaches towards creating live streaming tools for developers, and we didn’t like what we saw with either approach. First, we have media servers doing a poor job of supporting mobile, and… well, anything but Adobe Flash. Then second, we saw platform as a service companies providing good, but very limited tools.

Media Servers

One thing is increasingly clear–traditional media servers by themselves aren’t sufficient for building a live streaming app today. Why? Because all of them focus on the server side, and they rely on others to do the client. It’s not a full stack solution, and when you don’t control both the client and server endpoints, things can get messy rather quickly.

So, what is the origin of this issue? It’s because the servers, when they were originally designed, were relying on Flash as the client. This makes sense, because at the time Flash was the only viable client for streaming. Now of course, the world has shifted to other platforms. iOS, Android, and even modern browsers on the desktop don’t properly support Flash; the direction is towards native apps or WebRTC.

Before we came out with Red5 Pro, if you wanted to build your own mobile streaming app you would need to find a useable SDK for iOS and for Android. You would then need to install something like Wowza on the server and stream to that with your 3rd party SDK. What we found is that many of the open source SDKs weren’t well supported, and the paid ones just didn’t work that well. The flaws were obvious: they lacked flexibility and extensibility, and they all relied on RTMP, an older Flash based protocol. We decided this just wasn’t acceptable.

Hosted PaaS

The other trend we saw happening for live streaming solutions was the advent of hosted PaaS (Platform as a Service) products. Companies like LiveStream and TokBox are a few of the best ones in this category. What we found is that these solutions don’t provide enough control for the developer. Companies like TokBox have done a good job providing easy-to-use SDKs and make it super simple to setup since you don’t need to install the server–but this comes with a price.

Lack of control is a big one.

You have to rely on what the platform gives you. Either you are forced to include advertising in your streams, or you can’t easily modify portions of the SDK to grab a video source other than the device’s camera. Maybe it’s latency you are having trouble with like with Kickflip, or it could be a whole number of things that you want to do with your app that the provider’s SDK won’t allow you to do.

The PaaS solutions are also harder to scale and will cost more if you do achieve massive scale. The primary issue here is that you are basically locked into them handling the server for you. There is simply no way to host it where you want it. You can’t modify the server program easily to do things like live transcoding, moving recorded files to S3 buckets, integrating third party software like FFMPEG, etc. To make it worse, some companies can’t use cloud solutions and need to be deployed on networks that they control. Do you think your bank is going to allow video calls about proprietary financial information to flow through a 3rd party that they don’t control? How about medical software? I don’t think so–good luck getting around HIPAA.

Another thing to consider is that the major cloud hosting platforms offer credits to startups, and it would make sense to be able to easily move between platforms to take advantage of these deals (think of it like how consumers switch cable providers to get better deals). We designed Red5 Pro to be hosting agnostic so that where you host your solution is up to you.

Our Solution

We think we’ve taken the right approach by building the whole stack and providing super flexible SDKs for mobile (JavaScript WebRTC SDK coming soon!), Plus we give the power of where the server is hosted to you the developer. We are always looking for ways to improve, and if there’s something you are looking for, and we don’t currently do it, please let us know.