The live video streaming market is expected to hit $70 billion in 2021 was shown in a study from 2016. With the COVID-19 pandemic crisis, this process has accelerated drastically, and a lot of offline activities have moved online and Satya Nadella the CEO of Microsoft has stated that according to metrics from Microsoft, we had "2 years of digital transformation in 2 months".
Video content is the king nowadays, with more than 80% of US users preferring to watch a video than reading a blog post or articles, in addition to this, the viewing rate of videos is 10 – 20 times higher for live content than for prerecorded, on-demand one.
Live video streaming is really popular, we find it in Facebook's products, Instagram live stories, or on Twitch where a lot of gamers stream their plays. However, there is still much room for innovation as more and more of our activities are moving online, live training sessions, courses, conferences, or live assistance are just a few of the topics which started to be enhanced by live streaming solutions. In addition to this, due to privacy issues, many companies, and people are moving away from video communication tools from big companies.
Smartphones are our most personal devices, and they have great hardware capabilities for creating, streaming, and watching live video content. Today we are going to talk about the technology behind live-streaming apps, what should you consider if you want to solve a problem through live streaming and what are the costs of developing such an app.
How to build a live streaming app MVP?
Never build on assumptions is our mantra at appssemble, before building a product it's important to understand what's its purpose, and the business model around it.
From a business model perspective, live streaming apps implement a subscription-based model (monthly, yearly subscriptions), but there are also cases where Ads are used as a revenue source.
When building an MVP, the focus is on the core of the product, the main feature only, but that core needs to function remarkably well. When building a streaming app there are a couple of things that make the live streaming experience a pleasant one:
The content needs to be available instantly and the streams must have an as little delay as possible
Streaming content should not consume too many network resources - the internet is not cheap in many countries, especially the one from carrier providers, when building a streaming app you should make sure you're not using more bandwidth than you're needing
Streaming or watching a video should not drain the battery - unfortunately, this is the case with many apps where streaming, encoding, or decoding live video takes a big toll on the energy efficiency of the devices it runs on
Privacy - we are strong advocates of privacy, the content of the user should be his own and have full control over it
Last but not least, the UX/UI represents a major part in the success of the app, the flow of the user as well as how it interacts with the content can be a deal maker or breaker
The most popular live video streaming protocols are WebRTC and RTMP/S each with its own strong and weak points. Depending on the scope and budget custom solutions can be built that implement WebRTC and RTMP/S services, those usually cost more to develop but have lower operational costs, or third party services can be used to lower the development time but the operational cost is going to be greater.
When developing an MVP what we usually recommend is going with a third-party service provider for the first iteration of MVP, to test the market, user engagement, acquisition, etc., and if the product is successful move onto a custom solution with lower operational costs.
WebRTC in mobile apps
This technology allows for an extra layer of privacy as the connection (if possible) is made directly between the users involved in the communication, meaning the video goes straight from user A to user B without using an intermediate server, which results in lower latency, and lower operational costs. In cases where this approach fails, a relay server is used as a middle man for communication.
The downside of using this protocol is given by its strong point, in the case of apps where more than 2 participants are live streaming, the bandwidth used for streaming increases drastically.
To illustrate this example, let's imagine 3 users (A, B, C) that are engaged in a live streaming session. For this to work, each one of them has to send the stream from his camera to the other 2 users (user A streams its video stream to user B, and also streams it to user C) in addition to this, it needs to download streams from the other two users (user A downloads the video feed from user B and user C) to be able to see them.
As you can see, the network usage is affected by this quite a lot, as well as battery usage. Using WebRTC works well for around a maximum of 5 users who stream at the same time, after that point the resources consumed are too heavy for devices that are not constantly plugged into an energy source or have a WiFi connection.
Lower operational costs
Does not work well for more than 5 users on mobile devices - in general, it should be used for apps where communication is restricted to a low number of users, or when only a video feed is sent (the presenter sends the video to all of the participants, the participants are only watchers).
RTMP / RTMPS in mobile apps
This protocol is the most used for high-definition streaming, where a delay of 10–15 seconds (from the moment when it was streamed to when the user sees it) is acceptable, this is used for instance when streaming a conference, a sporting event, or a concert in which there is no real-time interaction with the viewers (only trough messages, and other means different than video).
The content from the streamer goes to a server that processes it and viewers interact with that server for viewing it, hence the delay. In terms of privacy, in this protocol, the communication always happens through a mediator (third party server).
The downside of this technology is that does not allow live streaming between the participants and it's also less advanced from a privacy point of view as the video is processed before viewers can view it. In addition to this, the streamer server knows who are all the watchers of the stream and can represent a single point of failure - in the case where there aren't multiple servers
High-quality videos, that can be modified (eq. applying watermarks)
Supports a large number of users - it can be scaled to any number of watchers
Videos can be stored and viewed on-demand after the stream has ended
Usage of third parties for communication
A delay of 10–15 seconds
Does not support real-time communication for all the users involved in the conversation
Features & Costs
Every MVP is different in its way, compiling a definitive set of features for a live streaming MVP is not possible, but many of the mobile apps which have streaming as their main component have some of the following features
User registration / login
A list of streamers/feeds and the ability to search or filter them
Streaming or watching a live stream
From a cost-wise perspective, an accurate estimate for such a project can not be made as it heavily depends on the features set, design, number of users, etc. A ballpark estimate for such an app, assuming no complex design interfaces, heavily relying on native components, which uses WebRTC for communication is given in the following table.