11 Things to Consider When Building an Android Live Streaming App

Creating a fully functioning Android live streaming app can be complex. You have to configure all of the backend system infrastructure required for a basic web application, plus all the additional considerations (i.e. potential pain points) for native app integration. Accordingly, some live streaming software companies have added mobile SDKs to their offerings in order to make that process easier.

Why build something from scratch and needlessly spend extra money and time to recreate something that already exists? However, it does need to work well, lest all that saved money and efforts will go right back into fixing everything.

Let’s discuss some of the key features you should look for in choosing a platform and SDK when building an Android live streaming app.

1) Latency

Live streaming should not be later streaming. If there is a delay of seconds between when you publish and when your viewer actually sees what was sent, then it’s not really live. This long latency creates a poor user experience without the interactivity that true real-time latency provides.

Drone guidance, live auctions, conference apps, event broadcasts, as well as two way conversations all need real-time latency. Even a relatively small time of a second or two is more than enough for your user to notice an unnatural delay. With high latency comes spoilers, stuttered conversations and an overall feeling of imbalance. In other words, latency is bad and creates a bad experience.

Achieving low latency in your Android live streaming app requires the use of protocols which were developed specifically with low latency in mind. For example, RTSP is designed to deliver live streams with speed and reliability. Similar to WebRTC, RTSP will send a stream with under 500 ms of latency. This is because RTSP uses RTP (or SRTP for a secure connection) which is the same transport protocol that WebRTC uses. That is one of the reasons why we at Red5 Pro opted to use RTSP in our mobile SDKs.

Other attempts to lower video latency include CMAF, WebSockets and Media Source Extensions, Low Latency HLS, and Apple Low Latency HLS ultimately failed in achieving real-time latency in real world production environments. Another common protocol selected for use in mobile streaming apps is RTMP.  However, RTMP is limited as well, typically adding more latency to your streaming app.

More information on how RTSP provides low latency, can be found in this blog post.

2) Scalability

It’s not just enough to have low latency. Rather all of your users must be able to watch a stream with that same low latency no matter how many others are watching. This is especially challenging but just as important when considering streaming to millions.

In order to scale, some streaming platforms like Vonage Video API (formerly TokBox) switch to higher latency protocols after reaching a certain threshold (currently 3,000). This switch results in an unequal experience for viewers who joined the stream earlier versus those that joined later. Effectively, these platforms trade performance and user experience for scalability. Your users should not be punished with high latency for joining a live stream after other subscribers.

While having a threshold on the number of low latency users is bad, some platforms can’t offer low latency in the first place. Streaming platforms built entirely on traditional CDN infrastructure are forced to use high latency, HTTP based protocols. Simply put, there is no way to get real-time latency with HTTP based protocols. One such example is Wowza. As they rely heavily on traditional CDN infrastructure to scale, they will tell you that CDNs are critical for any live streaming app built on their platform. The truth is that CDNs are not critical but simply easier to implement by pushing the scaling problem to them.

When keeping in mind the user experience, the impetus is to maintain real-time latency while scaling out to large audiences.

One way to get around caching mechanisms used by CDNs is to leverage cloud networks to spin up new compute instances creating a cluster of server nodes to deliver content. Employing this approach enables the platform to scale to millions of concurrent users while maintaining sub 500 milliseconds of latency. Red5 Pro in particular uses RTSP (more on that later) to broadcast large concerts, sporting events, or other happenings with under 500 milliseconds of latency unlocking a fully interactive experience.

For a deeper dive on how we approach scaling on cloud networks, take a look at our post on the cross cloud distribution system model.

3) Efficiency

Another thing to consider is efficiency. While you don’t want to sacrifice latency for scalability, you also don’t want to create a bloated, laggy system while increasing that scalability. You don’t want your users waiting around while the back end infrastructure strains to setup everything correctly. Ensuring a smoothly operating streaming system requires a streamlined platform that maximizes the number of connections you can get per server instance.

Thus, a stable connection that maintains a link between broadcasters and clients is very important. With correct connection logic, you will ensure that there won’t be any interruptions to the live stream. Furthermore, certain features, such as relay nodes, will simultaneously increase scale and optimize streaming performance.

Efficiency with the media server implementation allows for more streams per server instance; streamlining the delivery of data. Through the implementation of more efficient transport protocols, the streams themselves are more streamlined requiring less processor power to handle them. Smaller CPU consumption means each server instance can handle more streams. Avoiding the need to run more servers then necessary will cut costs. When it comes to large events, this can mean substantial cost savings.

Red5 Pro, for example, implemented RTSP in our mobile SDK. RTSP is lightweight in comparison to browser-based WebRTC streaming. This allows RTSP to handle 5 times more streams per server instance vs WebRTC.

More specifically to Android, a good streaming SDK needs to leverage both hardware decoding and encoding. Most modern Android devices include highly efficient chipsets for decoding and encoding live video and audio. Some other streaming SDK providers rely upon software to implement encoding and decoding. The problem with using software instead of the much more efficient hardware is that you will peg the CPU and drive up power consumption. Thus it will quickly drain your battery.

Unlike Apple, not all Android devices are made by the same company, thus there’s a large amount of variation and inconsistency in the implementations of hardware encoders and decoders. Prior to Android 4.1, this meant that as a developer you had to use each manufacturer’s API, which was a real headache. Luckily Google decided it was best to create a single API to access Android hardware video chipsets. Now it is relatively easy to access hardware for encoding and decoding through the MediaCodec class. Thus modern solutions for live streaming on Android should not use pure software for encoding and decoding the live video stream. If they do, you should look elsewhere.

Graphic acceleration is also important for rendering and displaying graphics. Your app should leverage the latest OpenGL for rendering your video. If you’re not taking advantage of efficient graphic rendering on each Android device, the seemingly simple process of displaying live video will kill the battery. Having to charge your phone while watching video results in a fixed orbit around a wall outlet, thus defeating the purpose of a mobile device. Simply put, hardware acceleration is very important, whether it’s a hardware decoder, graphics card or encoder chip.

4) Portability

Adapting to the ever changing world of the tech sector requires using a product that is maneuverable and flexible enough to change. As Platform as a Service (PaaS) providers make decisions, you may need to move your application onto one that better supports your needs. You shouldn’t have to rebuild the entire application from scratch for this.

PaaS providers are subject to the same issues as any other business. A buyout from another company, changing market trends, or just internal decisions can trigger changes. Those changes can be minor: from dropping a feature you didn’t really need in the first place, to more impactful like increasing their pricing. Having the ability to proactively respond to these developments can make the difference between a company that continues to thrive or one that goes into decline. Being chained to a particular platform can be very uncomfortable.

Ideally, you would want a solution that is as flexible as possible. In particular, your choice is critical when it comes to where you deploy and host your server infrastructure. The best option is then to use a hosting agnostic solution with a flexible API to ensure you can have the freedom to port your application over to another hosting provider. “Port” is the keyword here as you don’t want to tear everything down and have to build it all up again. Multi-platform support eliminates the risk of being permanently fixed to a single provider. DigitalOcean, AWS, Azure, and GCP are some of the many cloud providers, all with a variety of disadvantages and disadvantages. Your Android live streaming app should be built with an API that allows you to plug into any back-end. That will maximize your portability to move your application to another system without having to overhaul the entire infrastructure.

Obviously, your solution provider should be aiming to stick around for the long term duration, like we are at Red5 Pro. We didn’t build our business to be flipped and quickly sold to the highest bidder, and we won’t leave you holding the reins like many PaaS developer solutions have in the past.

5) ABR

Video streaming is a bandwidth intensive activity. Unfortunately, not every user will have access to super fast, always available 5G connectivity. Even users who are in highly connected areas can still suffer through periods of throttled bandwidth or instability.

One of the key tools and responsive features used to safeguard against choppy video is Adaptive Bitrate (ABR).  ABR works by allowing the client and/or publisher to automatically request a lower bitrate that is more conducive to the connectivity they are currently experiencing. By enabling both the publisher and subscriber to make this switch, it further maximizes the effectiveness.

As opposed to high latency HTTP based protocols, implementing ABR is more involved when working with real-time protocols like RTSP. With HTTP protocols such as MPEG DASH and HLS, all that is required is to request a new manifest and pull new segment files. Adjusting on the fly during the actual streaming event with RTSP requires the capability for the stream variants to shift via information provided over a control protocol.

Our approach to transcoding streams and ABR  is detailed in the Red5 Pro server documentation along with an example for iOS on Github.

6) Backwards Compatibility

Mobile phone users are no strangers to updates. The constant barrage of updates mean that some people may have an “old” phone that won’t support the most recent update. Not everyone can just always buy the latest piece of technology so you will need to have some form of backwards compatibility. Specifically, Red5 Pro supports Android version 4.1+. This allows your users a grace period to upgrade at their own pace rather than forcing them to keep up with a constant churn of updates.

However, support for legacy OS is not the only thing you need for compatibility.

7) Compatibility with Other Devices

It would be quite limiting if your Android app could only communicate with other Android devices. It’s better to support a variety of hardware and platforms (think different browsers and IoT devices). That will make your app much more useful. If you build an app solely for Android devices, you will shut yourself out from a larger market.

As such, now that you are considering building an Android app, you also likely want to release an iOS app. Your users may want to use a desktop or laptop as well which requires the further support of a variety of browsers. Of course, the user experience should remain the same so every supported platform should have the same performance, scalability and real-time latency. Red5 Pro’s HTML5 SDK allows you to build a webapp to increase your reach to most available devices.

Beyond just mobile devices, you might want to support IoT devices as well. Drones, VR headsets and IP cameras, can all enhance the live video streaming experience.

By converting from RTSP to WebRTC, the Red5 Pro solution will run directly in the browser without a plugin. With the support of all the major tech players, WebRTC will run in Safari, Firefox, Chrome, Opera, and Edge. You can even use mobile browsers as well. Our restreamer plugin lets you grab streams from IP Cameras and feed them to other devices running MPEG-TS, SRT or RTSP.

With all those flexible options, you can stream to all the devices your customers are looking for.

8) Customizable

If you want your application to stand out you will need to implement custom features. Or you might just be looking for a general set of fairly basic features and don’t want to have a piece of bloated software with all these extra features you will never use.

Beyond that there are security considerations to make as well as ensuring that the live streaming portion of your app fits in with the rest of your app.

The Red5 Pro Android SDK has such flexibility. It allows you to manipulate a stream directly on the device with custom video and audio sources. You can also access the raw frames of the audio and video on the subscriber side to do things like chroma key greenscreen effects and more. A wide feature set and high degree of customization are crucial components in building an Android live streaming app.

However, customization is only valuable if you can actually make it work which brings us to our next point:

9) Technical Support

No matter how well built a product is, there will always be a need for technical support. Given the myriad of devices and programming languages there’s bound to be a few hiccups along the way, so you will need a team to help guide you through any roadblocks. Accordingly, you will also want to make sure that everything is optimized efficiently and that you are making the most of all the features available. All of those things require the assistance of technical experts that understand how the product works.

With increased flexibility and custom options comes a potential increase in how much support you will need. If no one shows you the best way to configure something, what is the point of custom configuration in the first place. A custom suit needs a tailor, afterall. You need a good support system with chat channels, online ticketing systems, and advanced support contracts to help meet all your needs.

Considering that some companies treat a mobile SDK as an afterthought, it is no surprise that their support team can reflect this. When looking for technical support for a mobile SDK, the person addressing your issue or answering your question should have specific experience in building mobile apps. In short, if you have a concern about your mobile app, you want to talk to a mobile developer.

10) Forward Thinking Platform

Obviously, it is a very high priority for your application to function well. Of equal importance is the ability to continue to perform well. With new protocols, codecs and methods emerging all the time, tech platforms are especially prone to quickly becoming irrelevant. Just look at the recent downfall of Flash for example.

Something that works well today, may not work quite as well tomorrow. More efficient codecs and streamlined protocols are all part of the marketplace. However, implementing something “new” might not always be worth the extra effort from a cost-benefit perspective. Partnering with an organization that has a lot of experience in the live streaming industry allows you to benefit from their expertise in identifying the right improvements to make at the appropriate time.

Simply making a high performance video streaming platform isn’t enough. A truly good platform needs to continue to improve by responding to customer feedback and shifts in the technological environment.

11) Well Tested and Proven

Similarly, it’s not enough to just identify the right improvements. Those updates need to be prioritized and implemented correctly. The only way to ensure that something has been implemented well is to conduct thorough testing examining. This includes examining a new feature using a variety of methods and device combinations. Effective testing guarantees (as much as is practicable) that your application will perform consistently and dependably.

With sub 500 milliseconds of latency, a fully customizable API, automatic cloud based scaling, and cross device compatibility, Red5 Pro is trusted by major corporations such as the New York Times, Novetta, Invaluable Auctions, Sony, Google, and many others. Additionally, some US government agencies power their drone surveillance and command control systems with Red5 Pro.

It can’t be overstated enough that building an Android app for live video streaming from scratch can be hard. Live streaming server infrastructure in and of itself is challenging which is why we built Red5 Pro in the first place, but adding Android based live streaming functionality like encoding, decoding, transport protocols, encryption, and everything else you need to consider is a whole additional layer. Why waste your time pouring developer hours and money creating something that already exists?

Looking to build a new application or switch over an existing one? See what Red5 Pro can do for you. Send an email to info@red5.net or schedule a call directly. Happy coding!