5 New Experiences We Had Developing a Live Video Broadcasting App b.live
We have recently launched an app called b.live for Android and iOS devices. It was our first take on the domain of live video broadcasting services, and, of course, we had to adopt some new technologies to make the project possible. In this article, we’re going to tell you about these new experiences we achieved developing b.live.
1. Got access to and worked with Facebook and YouTube APIs
In April 2015, Facebook restricted the access to the API that allowed apps to get a user's friends' data. Now, to get access to some of these data, developers need to contact Facebook developers directly making an official request.
In our case, we only needed access to the “publish_actions” and the “user_education_history” APIs. The former provides access for the app to publish feed posts, Open Graph stories, achievements, scores, and other activity, so we could add links that allow watching b.live’s translations in Facebook via a web browser. The “user_education_history” API, in its turn, allows the app to find on Facebook those b.live users who studied or are studying at the same place and suggest them to follow each other.
We inquired Facebook to get access to these APIs attaching information about b.live’s flow and its video capture as a visual reference. That information was enough to get a quick approval from Facebook and enable in b.live the features these APIs provide.
To enable b.live users to broadcast their video on a YouTube channel as well, we’ve got the YouTube API keys. To broadcast video on YouTube simultaneously with the b.live stream, the video streams are being encoded on our server with the help of the FFmpeg libraries.
2. Successfully used RTMP for live video streaming
For our first project dealing with live streaming, we chose Real Time Messaging Protocol (RTMP) as a proprietary protocol for transmitting data between users and servers. RTMP allows to deliver video and audio streams smoothly and transmit as much information as possible by splitting streams into fragments by adjusting their size dynamically based on the connection between the client and server.
The advantage of RTMP over other live streaming protocols is that all video and audio files are being sent in the .swf file format which is compatible with the Adobe Flash Player and, thus, can be embedded both in a web page and in a mobile app.
3. Got more practice in socket integration
We use socket protocol manage all followers’ actions during the broadcasts including:
- sending follow/unfollow requests,
- banning from and allowing users writing text messages,
- rating broadcasts with ‘stars’,
- inquiring server to send an RTMP link for a YouTube broadcast;
and notify users about:
- the start and the end of a broadcast,
- received messages,
- new followers,
- joining and leaving broadcast viewers.
The WebSocket protocol also helps save some amount of video stream bandwidth because we don't always have to send a request to the server in order to receive information. This allows reducing the number of servers you would need to provide a service to your clients. Clients also don’t need to waste networking and resources for polling and making requests. Pretty efficient on both sides.
4. Adopted the VideoCore library for adding graphic objects to a video stream
VideoCore is a third-party library that a allows interacting with the video stream by applying graphic and audio manipulations to it.
We used VideoCore to enable b.live’s stream viewers to add custom drawings, emoji, and apply Instagram-like video filters to the broadcast.
5. We are currently working on the integration of Twitter and Facebook Live APIs
Now, our team is working with Twitter and Facebook Live APIs, and in the nearest future, b.live users will be able to broadcast and view streams via these two platforms as well. This will make b.live the only live streaming app able to broadcast on three major social media platforms at the same time.