Another thing that makes a software engineer's life a little easier are SDKs. These development toolboxes jumpstart the process of adding specific features or advanced functionality to web applications. Rather than building everything from scratch, an SDK can form the basic framework to meet your requirements.
This is especially true when it comes to the complexities of live streaming. The process of encoding and decoding video and audio codecs, packaging them into transport protocols and ensuring a smooth (not to mention fast) delivery takes a variety of complex components. These components must be seamlessly spliced together or the whole thing falls apart, dropping connections or degrading into a garbled video with blocky artifacts.
All this begs the question: what about using node.js for real time video streaming applications? Are there any SDKs or video streaming platforms that can be used?
In no particular order, we present some options for real time streaming:
First on the list, NodeMedia Server is the only server specifically written in Node.js. Though that certainly does not mean it is the only platform that will work with Node.js, it is useful to have it written in a platform you are most familiar with, especially if you want to alter the source code and create custom features on your own.
However, there is a large limitation in regards to effectiveness for this open source implementation, namely that it only supports RTMP. With Flash reaching end of life status for 2020, RTMP is finding itself relegated to secondary status for fallback support. While RTMP can still be an effective transport protocol for internet content, newer developments in the live streaming sector such as the development of the new Web Standard WebRTC, will and in most cases have already replaced it. Designed around creating low latency, WebRTC has proven itself to be a very effective protocol for browser-based live streaming.
With this in mind, a platform that relies solely on RTMP, may not be the best choice in regards to sustainability and performance. RTMP (Real-Time Messaging Protocol) is an application-level protocol owned by Adobe. It was originally designed for delivering on-demand media and live media (i.e live audio, video, and data) over the Internet between a Flash player and RTMP Media Server.
RTMP lacks HTML5 Support, which means it will not work in the browser, unlike WebRTC which can run directly in the browser. Of course, you can stream RTMP over HTTP, but that will negatively affect the performance.
As a TCP based protocol, RTMP will also introduce a great amount of latency. TCP (Transmission Control Protocol) is a transport layer protocol used for sending bits of data—known as packets—over the Internet. As a connection-oriented protocol, it requires lots of back-and-forth communication to reorder packets and ensure their complete delivery. This constant exchange of messages introduces latency in many networking scenarios.
Lastly, there are issues with firewalls and encryption due to the fact that most RTMP content is sent via the non-standard port 1935 rather than the standard HTTP port 80. This issue can be prevented by streaming in RTMPT (tunneling over HTTP), which comes at a server and client performance cost.
To make matters worse NodeMedia Server doesn’t have corresponding client side SDKs to make integration easy. You will have to dive into finding compatible Node.js based RTMP client implementations to use this solution.
There are other attempts at RTMP implementations written for Node available on Github, such as this Node.js module that also includes a client implementation. However, even in this implementation you don’t have any way to create browser based clients without resorting to the outdated Flash player. Simply put, RTMP based implementations are likely not the best solution.
Wowza has a long history in the live streaming industry, making them a common choice for live streaming. Their biggest strength comes from their ability to support a variety of ingest types.
Accordingly, a large percentage of their clients use Wowza for a single purpose serving as an ingest point in their origin server. After taking in a multitude of streaming protocols, the origin then converts the streams for CDN-based delivery. This repackaging of streams for CDN delivery is a good use of Wowza’s software.
While the large size of Wowza denotes their ability to create a viable product, their large size can work against them as well. As you know, the tech industry is always innovating meaning that most tech platforms need to be open to evolving. Specific to the live streaming industry, platforms must adapt to new and more efficient protocols that can drastically improve streaming quality and performance. Live streaming software (and those using that software) must anticipate these changes to continue delivering a successful product.
As we mentioned before, the end of Flash means that new standards, such as WebRTC, are poised to replace or at least supplant the old RTMP protocol. In the face of this ever-increasing urgency, Wowza’s efforts to fully implement WebRTC have apparently stalled. If you have the time,you should certainly give Wowza’s WebRTC implementation a try and see the results for yourself. You will find that lack of transcoding between codecs, no client side SDK, and lack of support for core features like packet resending for subscribers and ABR can be show stoppers for any production application. This doesn’t even get into the scale limitations due to the fact that Wowza has no clustering deployment for WebRTC streams.
Without real-world ready scalable WebRTC integration, Wowza still relies on CDN based video delivery causing them to suffer from high latency of around two or three seconds (at the very lowest using CMAF for example). This is nowhere near the sub-500 ms delivery that WebRTC has produced on other streaming solutions. Even Wowza’s latest attempt at Apple’s latest streaming protocol LLHLS comes up short on latency. Two seconds is far too high for any sort of live, interactive experience, even if you can find a player and CDN that supports this new protocol.
Also, if you go down the path of using Wowza cloud, it could mean getting locked-in to their Wowza network. Without an easy way of porting your existing application to a different hosting provider, you would be forced to adopt any changes they make to their network like what recently happened with Wowza ditching support for their Ultra Low Latency SDKs.
Lastly, there is a limitation on customization. Wowza created a general-purpose platform with basic functionality which made their platform very accessible. However, that simple functionality means custom feature development or even modifications can be hard to implement or receive support on. Customization is the key to ensuring your product stands out and does everything needed.
Built on top of our open-source Red5 code, ANT Media claims they are able to provide an expected latency of 500 ms or less using WebRTC. While this sounds great, in reality, it might not be as effective as one would hope.
Scalability is a big weakness for ANT Media. Their Large Enterprise Instance hosted package limits you to 8 concurrent broadcasters and 400 HLS (high latency) subscribers. WebRTC subscribers are confined to only 300 clients. Such a low ceiling greatly restricts the potential growth of your application. However, they do offer a Custom Scalable Cloud with a “flexible” number of viewers and publishers.
ANT Media can have issues staying up to date as well. Like Red5 Pro, ANT Media built their platform on top of the Red5 open-source software. However, there is an important difference in that the team at Red5 Pro still retains control of the open-source Red5 code. This means that as new features and optimizations are added, the open-source is updated as well. This ensures that both the Red5 open source and Pro systems maintain parity and seamlessly synch together to minimize any conflicts or regression bugs.
Additionally, customer service can be negatively affected as well since ANT Media doesn’t have the same detailed understanding as Red5 Pro has. By building our own product from the ground up, it is fair to argue that we have a more complete understanding regarding the capabilities and possible configurations for custom feature development.
Without directly contributing to Red5, ANT Media cannot ensure entirely consistent functionality. More importantly, innovation is stifled as they simply copy the features that Red5 Pro adds to their product. Without progressive development, this lack of originality results in slow product features and/or updates at best and outright dysfunction at worst.
However, if price is your main concern, and scalability of your app is minimal, Ant Media could be a good option. Their pricing options offer good choices for hobbyist developers and those doing quick MVPs on a budget.
Another long time contender in the live streaming industry, Limelight’s RTS (Real-time Live Streaming) platform is a managed solution offering basic functionality that works well. As a managed solution, it will be fairly straightforward to configure everything since Limelight handles all the server infrastructure for you. Using Red5 Pro mobile SDKs, you can also build native apps. With consistent performance and reliable content delivery, it can certainly be considered a platform that works well.
The RTS feature is a relatively new offering that has enabled Limelight to support true low latency streaming. This gives broadcasters the ability to send video out as quickly as possible and subscribers to respond to events in real-time which facilitates interactive experiences.
Limelight built their RTS platform using Red5 Pro’s software. As such, they are able to achieve sub 500 milliseconds of latency. However, there is more to live streaming than just low latency (as important as that is). Limelight has yet to enable all the current features of Red5 Pro, thus blocking you from using the full functionality. Additionally, you cannot deploy your own server-side apps with Limelight which means you can only use what they choose to expose.
Lastly, Limelight is a CDN which means that the delivery of their content depends upon a series of fixed data centers. Built off of the HTTP based infrastructure of the internet, CDNs have been around for a long time and have enjoyed an important role in the delivery of content. However, flexible cloud-based systems are starting to replace fixed bare metal based data centers due to their elastic scalability. That makes cloud based systems a little more performant than bare metal servers. This creates a big problem for Limelight as their entire business model is built around these constantly running data centers. For a more detailed examination of CDNs, please take a look at this blog post.
TokBox is a really good platform. They boast a quick setup time effectively allowing for plug and play app development with a relatively easy to use interface. Their SDKs are fully-functional, well-built, and really good at point-to-point communication. TokBox is ideal for quickly building a POC to meet an investor deadline or testing new concepts during a hackathon.
Over two years ago, TokBox was acquired by Vonage, so it’s official name is the “Vonage API”. However, most people still refer to it as TokBox so we will use that name.
As with many things, ease of use can have it’s own set of pitfalls; specifically in the area of extra features, customization potential, and scaling costs.
ToxBox’s pricing model charges per stream per minute. Ideally, your application will gain more success, increasing the number of users and consuming more streams. That means you will be paying more and more for each additional user. You don’t want to be in a situation where you will be punished for your success. Still if your application is designed to never support many users, then TokBox could be an excellent choice.
Furthermore, “advanced” features such as recording and interactive broadcast (which excludes a specific mention of expected latency) come at an additional cost. Not only that, anything over 2,000 connections will switch over to CDN delivery. As we’ve covered before, CDNs mean higher latency.
After 3,000 viewers TokBox switches to HLS delivery. This means that any sort of real scale will negatively affect your user experience since HLS adds many seconds of latency. As such, TokBox clearly cannot deliver real-time streaming at scale.
Finally, there is the inevitable tradeoff that comes with a simpler install. While TokBox is easier to get installed, it will negatively impact customization options. If you are looking to expand the functionality or add new features, you may be forced to wait on TokBox’s roadmap rather than implementing it yourself.
Another convenient hosted solution, DACast has an HTML5 player which supports mobile devices and browsers. One of their most useful features is expanded VOD support with the ability to insert ads.
While full browser support is useful for laptops and mobile devices running internet browsers, DACast lacks a native SDK for mobile-specific development with an iOS or Android specific application. This can likely have a negative impact on UI and feature performance.
Another negative against DACast concerns latency stemming from decisions made on how it was built. DACast uses CMAF which will inevitably produce high latency due to how it segments the stream into small chunks. In fact, their website states a latency of 10 seconds (although realistically CMAF should be able to get down to 3 seconds or so). By definition, any platform that measures latency in seconds cannot produce low latency video streaming. More details on the inner workings of CMAF can be found in this blog post.
Millicast, led by the outspoken Dr. Alex, is a WebRTC based fully hosted solution. By using WebRTC they are able to achieve a latency of between 200 and 500ms. Further increasing its usability is adding the convenience of a pre-packaged hosting solution. This means that you can get smooth streaming performance and real-time interactivity, in an easy to install package.
However, with more convenience comes higher costs. Completely relying on third party architecture exposes you to a service trap due to how building an application on providers such as Millicast effectively binds you to their service. Furthermore, you will also be limited from implementing your own server-side logic including transcoding, custom authentication, and pushing your stream out to other processes. This lack of flexibility confines your product to a pre-built sandbox by hindering customization options. You can avoid this issue by using hosting agnostic solutions, such as Red5 Pro.
I’ll set is also quite expensive. Their rates for data transfer are much much higher than what the others like CDNs in the live streaming space offer.
Mux created an easily managed service designed to get a basic streaming application up and running in a short timeframe. Designed with developers in mind, their detailed documentation makes it easy for those with basic developer skills or software code understanding to establish a simple streaming video platform regardless of specific video experience.
Where Mux really starts to stand out is their innovative multi-cdn approach. This helps optimize stream distribution across different regions and avoids some of the concern of being locked-in to a specific CDN. That said, you are still confined to their network; unable to stream outside of it.
Though the multi-cdn approach is quite innovative, it's still, afterall, a CDN which means it will face all the limitations apparent to CDNs. All the video delivery is performed through high latency HTTP based protocols. In Mux’s case, they use HLS which results in the highest of latency: anywhere between 10 - 30 seconds. Even if they are using Low Latency HLS (LHLS) that would still produce a latency of 2 - 5 seconds. With a delay that high, any sort of live, interactive experience is impossible.
Again cost is an issue with Mux for any large scale application. They have a price per GB transfer model that is higher than using most CDNs directly.
Word has it that Phenix is a reliably performing streaming service with solid functionality. A “fast time to first frame”, is among their most notable features. However confirming this is rather difficult as they do not have any exposed example code, free trials, or live demos. It’s said that they are expensive but there is nothing posted on their site to either confirm or deny that claim. If you really want to find out more you will have to contact them. Perhaps with all their mystery, they can set up a rendezvous with your local secret agent.
Nonetheless, just as convenience has a price, so too does a completely free, DIY pre-solution. It won’t (directly) cost money, but it will cost time and effort (which ultimately cost money) as you will have to build a full-featured application from the ground up. Kurento will provide a good backbone given you know how to effectively use it.
There are other open-source WebRTC options available as well like Jitsi, Media Soup, and Janus. While these others can work well too, Kurento is the best known and most widely used of the many WebRTC based media servers.
Nginx is open-source software for web serving, reverse proxying, caching, load balancing, media streaming, and more. It was originally created as a web server for delivering websites and has evolved into a multifaceted solution for proxying content. Today it’s the most widely deployed web server.
Eventually, NGINX added RTMP support to address scalability problems with plain RTMP streaming. That provided good performance and stability for live streaming over less scalable solutions like Flash Media Server and Wowza.
As we’ve already covered in our above review of the open source NodeMedia Server, RTMP has many limitations. We recommend looking for solutions that add more modern real time protocols like WebRTC. NGINX also supports HLS as a streaming protocol, but as has already been discussed with other solutions, HLS creates streams with latencies measured in many seconds.
That means NGINX falls short on providing ultra low latency modern protocols for a node js real time video streaming application.
As our tagline states, we provide live streams to millions of concurrent users with milliseconds of latency. Like others in this list, we use WebRTC to deliver sub 500 milliseconds of end to end latency. What separates us from everyone else is that we can further extend that real-time latency to millions of concurrent connections. Furthermore, our hosting agnostic solution leverages cloud providers thus avoiding any lock-in concerns which gives you a great degree of flexibility over your back-end architecture. With full-featured SDKs for iOS, Android and soon Linux, you can get the same performance with mobile devices.
As a highly customizable solution, there may be some additional configurations to get everything working as needed, but we’ve been told that our documentation is pretty useful for addressing that. Our knowledgeable and responsive technical support helps ensure that you can make the most of our software.
Though we don’t currently provide a hosted solution, we are working on one so keep an eye out for a future announcement about that. For those looking for a hosted solution right now, we also offer an Enterprise Plan where we can set up and manage your account for you. That way you still have the flexibility and security of running your own servers without having to do any additional maintenance.
To explore everything we can do check-out our ultra low latency video streaming demo and sign-up for a 30-day free trial.
Of course, if you think we’re leaving something out (or are just plain wrong), please let us know! Send an email to firstname.lastname@example.org or schedule a call. We are always looking to improve.