12 Platforms for Golang Video Streaming

Golang (officially Go) is an open-source programming language that is a favorite choice among many developers. Developed by Google as a way to increase programming productivity in the face of limitations of the C++ language, Go is implemented through Google’s self-hosting compiler keychain and uses gccgo (a part of GCC) for the frontend. Further increasing versatility, GopherJS can compile Go to Javascript as well.

Another versatile tool used by software engineers are SDKs. An SDK is an essential tool for adding specific features or advanced functionality to web applications. Rather than going through the arduous and time-intensive process of building everything from scratch, an SDK gives developers a springboard for advanced functionality.

This is particularly 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. Furthermore, the resulting live stream should be scalable so that as many people can interact with the stream as possible.

Of course, for live content no matter how high quality a stream is, it will still need to stream with low latency. Even with a smooth stream comes the risk of high latency if the proper protocols are not used. High latency degrades the user experience with unnatural delays in conversation and synchronization problems which leave users vulnerable to spoiler alerts among other issues.

With all the importance live streaming has for a variety of applications from entertainment, to chatting with friends and even just conducting essential business services, more and more people are looking to create live streaming applications. Obviously, Golang developers will be among many of the people tasked with creating or modifying applications.  

This post will cover different services or platforms available for Golang video streaming.  

Pion WebRTC

While it is fairly straightforward to make your own Golang video streaming server using HLS, there are many limitations to HLS which we have covered in the past and will cover in more detail later on in this post. Thus, it would be better to use a modern, low-latency based protocol such as WebRTC to deliver your live streams. This is where Pion WebRTC comes in.

Similar to Google’s C++ based WebRTC implementation, Pion WebRTC is a pure Go  implementation of the WebRTC API. With full ICE/STUN/TURN signaling, peer-to-peer connections, and data channel implementation, Pion looks like a solid place to start building a live streaming application.

Therein lies the main concern with Pion: building your own. Despite the availability of a variety of good examples, Pion WebRTC is not a full golang video streaming platform on its own.  Pion lacks out of the box autoscaling that will work on multiple platforms so you will have to build everything out to get a completely functional platform. Beyond a limited POC, getting an application ready for real world production will require a good amount of coding (which takes time) to create clustering for scalable distribution.

The peer-to-peer nature of WebRTC, creates inherent challenges to making it completely scalable to large audiences, or multi-chat applications such as conference calls. While it’s certainly not an insurmountable challenge, it is quite labor intensive and will consume a good amount of developer hours. Just ask those of us at Red5 Pro and we can tell you that it took a number of years to figure this out.

Obviously, every offering on this list will involve some sort of extra configuration, but like most other open source software, Pion does not offer dedicated support. Their broadcast example is a good start to building a webrtc media server making it very possible to build a complete application It’s a matter of practicality concerning how much time you can realistically devote to it.

While Pion WebRTC is the only offering on this list specifically written in Go, the other ones on this list will work as well.

Kurento

Another open source software written to integrate with WebRTC, Kurento is a solid choice for live streaming. With a completely open-source code base, it will undoubtedly be cheaper than the other paid options. Their Java source code (note, not JavaScript) is fairly well documented, and Kurento has got a nice set of features focused on WebRTC streaming.

It bears mentioning, that just as convenience has a price, so too does a completely free, DIY pre-solution. While it won’t require upfront software costs, it will require time and effort to build a full-featured application from the ground up. Those indirect costs can often exceed the price of a more full featured solution. That said, 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.

As a Go developer, you’d likely opt for Pion over Kurento or any of the other open source WebRTC media server implementations simply because, well, it’s written in Go.

NGINX

Nginx is another piece of open-source software for media streaming, web serving, caching, reverse proxying, load balancing, and more. Though it was initially created as a web server for delivering websites, it has since evolved into a multifaceted solution for proxying content. In fact, it is so versatile it is currently the most widely deployed web server in the world.

In response to scalability issues with solutions like Flash Media Server and Wowza, NGINX added RTMP support to address scalability problems with plain RTMP streaming. NGINX’s RTMP support provided for stability and better performance.

Unfortunately, RTMP has many limitations. RTMP 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. With Flash reaching end of life status for 2020, RTMP is more often being used for fallback support. That means it is relegated to a secondary slot rather than the primary protocol for streaming.

Though it can still be an effective transport protocol for internet content, newer innovations in such as the development of the new Web Standard WebRTC, are quickly replacing RTMP. 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 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.

Beyond sustainability and compatibility, there is a concern about latency. As a TCP based protocol, RTMP will also introduce more latency than UDP based protocols. 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  backed up packets and thus 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.

We recommend looking for solutions that add more modern real-time protocols like WebRTC. Though NGINX also supports HLS as a streaming protocol, HLS creates streams with latencies measured in multiple seconds. That means NGINX does not provide for truly interactive live streams which will negatively affect the user experience.

Dacast

Dacast is a convenient hosted solution with an HTML5 player that supports mobile devices and browsers. One of their standout features is expanded VOD support with the ability to insert ads.

Browser support is useful for running your application on laptops. It can also support mobile devices as it can be run on mobile browsers as well. However, mobile browsers do not always provide the best user experience due to how different browsers implement various methods and elements. Dacast lacks a native SDK for mobile-specific development with an iOS or Android specific application. As such, UI and feature performance can suffer meaning a bad UX for your customers.

When it comes to low latency, Dacast is further hampered by the tech stack they implemented. They use CMAF which requires segmenting the stream into small chunks which inevitably produces high latency. In fact, their website states a latency of 10 seconds (although realistically CMAF should be able to get down to 3 seconds or so). Any platform that measures latency in seconds cannot, by definition, produce low latency video streaming.

Mux

Mux created an easily managed service designed to get a streaming application up and running in a short timeframe. Designed with developers in mind, their detailed documentation makes it easy for those with a basic understanding of software code to establish a simple streaming video platform regardless of any experience specific to live video.

Mux differentiates itself through an innovative multi-cdn approach. This helps optimize stream distribution across different regions and avoids some of the concerns of being locked-in to a specific CDN. That said, you are still unable to stream outside of their network which could be confining.

Though the multi-cdn approach is quite impressive, it still runs on a CDN infrastructure. This will result in inherent limitations, due to the fact that CDNs use high latency HTTP based protocols to deliver the stream. 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.

Phenix

Rumour has it that Phenix is a well-functioning streaming service with reliable performance. Among their most notable features is a fast time to first frame and sub 500ms of latency at scale. We’ve also had a few of our customers who’ve tried it mentioned that HD streams don’t look crisp. Although, it is difficult to confirm this ourselves as they do not have any exposed example code, free trials, or live demos. You might just have to purchase it to see how it works for yourself.

It’s also 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 secrecy, they can arrange a rendezvous with a secret agent (or maybe just a salesperson). Who knows?

Millicast

Led by the outspoken Dr. Alex, Millicast is a hosted solution integrated with WebRTC. This platform combines the convenience of pre-packaged hosting with WebRTC’s streaming performance producing a low latency of 200-500 milliseconds. This means that you can stream relatively easily while still getting real-time interactivity.

Like all things, there is a tradeoff. Since you will be completely relying on third party architecture, you will have to make due with any changes that third party makes even if they are not convenient for you. This is known as a service trap since you are essentially bound to the service (in this case, Millicast) that your application was built on.

Another problem with Millicast’s hosted model means that your app’s infrastructure is shared with other companies’ apps. For some, this might not seem like a major issue. However, we have heard reports of Millicast servers being blocked by network-based child content protection filters. This is due to many Millicast customers being in the gambling space and/or other inappropriate non-kid-friendly businesses. If your app is geared towards education, for example, this may be a show stopper for you.

Furthermore, the back end infrastructure is inaccessible, so customization options will be limited. You will be blocked from implementing your own server-side logic including custom authentication, transcoding, and pushing your stream out to other processes. Rather than creating an application specifically tailored to your needs, you will be confined to a pre-built sandbox. You can avoid this issue by using hosting agnostic solutions, such as Red5 Pro.

TokBox

Among all the hosted solutions on this list, TokBox is one of the best. With a quick setup time and relatively easy to use interface, they are as close to plug and play app development as it gets. Their SDKs are fully-functional, well-built, and excel 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 continue to use that name.

As we mentioned above, that convenience comes at a large cost. The areas of extra features, customization potential, and scaling costs are all affected.

ToxBox’s pricing model charges per stream per minute. Ideally, your application will gain more success, and thus have more users consuming more streams. Without tiered based pricing, every single user costs money and your expenditures will continue climbing. This creates a situation where success can actually hurt and cause you to lose money. One the other hand, if your application is designed around a small number of predetermined 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.

Not only are there additional costs with scaling but there are performance tradeoffs as well. After 3,000 viewers TokBox switches to HLS delivery. Since HLS adds many seconds of latency, the stream will be sluggish and the user experience unbalanced. TokBox clearly cannot deliver real-time streaming at any sort of real scale.

Finally, there is the inevitable consequence that comes with a simpler install. While TokBox is easier to get installed, it will limit the options for customization. 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.

ANT Media

ANT Media forked the Red5 open source code, to build their solution with a claim that they are able to provide an expected latency of 500 ms or less using WebRTC. While this sounds promising, the real-world results might not live up to that hope.

First and foremost, ANT Media faces scalability issues. 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. This low threshold will greatly throttle any growth of your application in the future. However, they do offer a Custom Scalable Cloud with a “flexible” number of viewers and publishers.

That’s not the only issue that ANT Media faces. Staying updated with the latest feature sets required in the marketplace can be a problem as well. Like Red5 Pro, ANT Media built their platform on top of the Red5 open-source software. However, there is an important distinction in that the team at Red5 Pro still retains control of the open-source Red5 code. This means that open-source Red5 will simultaneously update with Red5 Pro as new features and optimizations are added. This is done in order to ensure that both the Red5 Pro and open-source Red5 systems maintain parity and seamlessly synch together to minimize any regression bugs or conflicts.

Additionally, this lack of ownership has a negative effect on customer service considering ANT Media doesn’t have the same detailed understanding as Red5 Pro has. The act of creating something from the ground up will inherently benefit your understanding of the product. Thus it is fair to argue that we have a more complete understanding regarding the capabilities and possible configurations for custom feature development.

Without any direct contributions 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.

Limelight

A 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. Considering that Limelight handles all the server infrastructure for you, the process of configuring everything correctly is a little easier. Additionally, their solution was built on top of Red5 Pro, meaning you can easily build native apps using our mobile SDKs. Featuring reliable content delivery and consistent performance, Limelight is a solid option for creating a live streaming platform.

Built using Red5 Pro’s software, the RTS feature is a fairly new offering that has enabled Limelight to support true ultra low latency streaming. The Red5 Pro technology unlocked sub 500 milliseconds 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.

Despite the crucial nature of latency, there is more to live streaming than just low latency. Ensuring that you have a full set of features to improve the overall functionality and usefulness of your application is just as important as the stream performance. Limelight has yet to enable all the current features of Red5 Pro, thus preventing you from using the full power of Red5 Pro. 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. CDNs were designined around the HTTP based infrastructure of the internet, meaning they have historically served an important role in the delivery of content. However, this is starting to change as new, 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. As such, cloud hosting is a big problem for Limelight considering their entire business model is built around these constantly running data centers.

Wowza

A giant in the live streaming industry, Wowza has a long history positioning them as popular choice for live streaming.  Their biggest strength comes from their ability to support a variety of ingest types.

Reflecting this, a large percentage of their clients use Wowza for a single purpose serving as an ingest point in their origin server. This works by enabling the origin to take in a variety of streaming protocols, then converting the streams delivery over a CDN. Wowza works well for this kind of stream repackaging.

However, those looking to build a mobile application will find Wowza lacking as they recently discontinued support for their mobile SDK.  Without a native SDK, those looking to use a

mobile app with Wowza will be forced to build an entire back end as well as the front end from scratch. That’s a lot of work. Wowza also doesn’t have a JavaScript SDK, which means you either have to write everything from scratch or find a third party player to implement the streams in your web application.

While the prominence of Wowza denotes their ability to create a viable product, their large size can work against them as well. It’s well known that the tech industry is always innovating: what’s here today may be gone tomorrow. That means successful tech platforms need to be open to evolving and keep an eye on the horizon. 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. The deadline for replacing Flash (thus remaining technologically relevant) is quickly approaching. WebRTC is definitely the replacement but is certainly challenging to implement. By all appearances, Wowza’s efforts to fully implement WebRTC have stalled or perhaps even been put on hold.

If you have the resources, you should give Wowza’s WebRTC implementation a try in order to see the results for yourself. You will find a dearth of features: no transcoding between codecs, no client side SDK, and a lack of support for what should be core features like packet resending for subscribers and ABR. New protocols are intended to be better than older ones. Not implementing all (or even most) of the advancements is counterproductive and a waste of innovation. Furthermore, Wowza’s WebRTC attempts face major scaling issues due to the fact that they do not have a clustering deployment for WebRTC streams.

Without production 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 when using CMAF). That is a long way from the sub-500 ms delivery that WebRTC produces on other streaming solutions. Wowza tried to innovate workarounds such as using Apple’s latest streaming protocol LLHLS but that still comes up short on latency. Two seconds is far too high for any sort of interactive live streaming experience, even if you can find a player and CDN that supports LLHLS.

Also, if you choose to setup Wowza on their hosting platform, Wowza cloud, it could mean getting locked-in to their Wowza network. Due to the lack of an easy way to port your existing application to a different hosting provider, you would be forced to adopt any changes they make to their network. One such change you be the recent choice Wowza made to end 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.

Red5 Pro

Latency, scalability and customization are among some of the chief strengths of Red5 Pro. Like others in this list, we leverage WebRTC to deliver media with sub 500 milliseconds of end to end latency. We sprint ahead of the pack by extending 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. All these features and optimizations are available for iOS, Android and Linux (currently in beta).

As a highly customizable solution, there may be some additional configurations to get everything working as needed, but that will ensure that your application does everything you need it to. Nothing extra just what you need. We’ve been told that our documentation is pretty useful for walking you through all our customizations and explaining all of Red5 Pro’s capabilities. 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 info@red5.net or schedule a call. We are always looking to improve.