Choose low-latency RTC or CDN for live broadcast distribution?

[Follow Global Internet Communication Cloud ] Last month, "unpopular singer" Stefanie Sun once again occupied the hot search. Her live concert opened just 16 minutes and received over 100 million likes. In fact, Stefanie Sun is not the first to try live a live concert. Since the epidemic, all online and cloud activities have become commonplace. Not only a lot of singers have held online concerts one after another, concerts, music festivals, and even very lively dramas have begun to use the form of live broadcast.

Mobile Internet brings us to the digital economy society, and live broadcast is a very important tool among them. Whether it is the enduring entertainment live broadcast or the popular answering live broadcast, the live broadcast is responsible for the traffic of the past few years. The fresh tricks of the past have become the standard configuration of Internet applications, and we have entered the era of "everything can be broadcast live".

So how do developers implement a live broadcast application? How to ensure the user experience through technical means? This article will combine Rongyun's in-depth research and practical experience in sub-industry to answer one by one.

Live link selection

To put it simply, the principle of a complete live broadcast application is: the host collects audio and video, pushes it to the server, and then distributes it to the audience for viewing by the server.

The host is responsible for streaming, and needs to be configured to select the RTC link to distribute the live screen or use the CDN link to distribute. If you need to consider how to do MCU confluence if you are involved in Lianmai, the advantage of the audience subscription confluence is that it can ensure that the dialogues of multiple anchors are basically aligned, and there will be no screen freeze or delay caused by a certain anchor when subscribing to multiple anchors due to network differences "Slow half a beat" and other phenomena.

(Live link flow chart)

Several issues affecting user experience

The core of the competition of the live broadcast platform, whether the fulcrum is on the anchor or the content, is inseparable from the experience of the application itself. From a technical logic point of view, live broadcast should be infinitely close to offline real-time communication, which means to achieve low-latency and high-fluency interaction.

In the face of such complicated link selection and scene switching in the realization of live broadcast scenes, live broadcast applications often encounter problems such as delays, link switching failures, and long first screen time consumption, which cause users to give "bad reviews". This is also a key consideration for developers. The place.

Delay problem

Early live broadcast applications were generally single anchors, who could only interact with the audience through text. At that time, the industry did not have high real-time requirements for live broadcasts. Software developers generally chose RTMP push-pull streaming to distribute live images on CDN links. In this way, the delay between the host and the viewer is generally 2 to 5 seconds, that is to say: the live broadcast picture that the viewer sees or hears, the sound is made by the host 2 to 5 seconds ago.

When the host interacts with the audience, such as asking everyone what song they want to listen to, it takes a long time to get feedback. This situation particularly affects the overall effect in e-commerce live broadcasts. When the anchor releases products for viewers to snap up purchases, the purchase entrance will appear first, and then the anchor’s oral broadcast "The product is on the shelf, quickly buy it". This kind of misplaced experience is really not high-quality.

To solve this problem, developers must choose a reliable CDN live broadcast acceleration service, or simply choose an RTC service for live broadcast distribution. In this regard, Rongyun’s CDN link has in-depth cooperation with domestic head manufacturers to jointly build multi-scenario and multi-link switching of interactive live broadcast scenes; on RTC live broadcast, Rongyun has achieved a low latency of less than 500ms from the host to the audience. live streaming.

(Comparison of live link)

Failed to switch the link when the microphone is connected

If the CDN link is used for live broadcast distribution, the switch from the CDN link to the RTC link is involved when the viewer switches to the mic-linked anchor in the mic-linked scene, and the terminal needs to switch the audio and video player. Developers need to maintain the status of the two players, often black screen, freeze and other issues.

Rongyun fully considers various abnormal situations when switching between these two scenes to avoid switching failures, black screens and other problems that affect user experience; when using Rongyun SDK for live broadcast, single room with microphone or multi-room with microphone can be used at any time By switching, the host can also conveniently and quickly control the picture style seen by the audience in the room.

(Multi-room anchor with microphone)

First screen takes a long time

With the development of network technology and communication technology, our tolerance for delay is getting lower and lower. However, the traditional CDN link involves a series of time-consuming operations such as live broadcast address distribution and data request, which cannot meet the user's demand for "opening a live broadcast and wishing to load the video image immediately".

Rongyun fully considers various scenarios when doing low-latency live broadcasts, integrates various data interfaces, and can realize videos in seconds, and it only takes 1 second for users to enter the live broadcast room to load the video.

Live broadcast stability

In terms of ensuring the stability of live broadcast, Rongyun's self-developed algorithm can ensure the reliability of the upstream data pushed by the anchor on the anchor side under weak network conditions. Even if video packet loss is 40% and audio packet loss is 80%, the live broadcast service will not be interrupted. In addition, the host's voice can be transmitted to the audience with better quality after 3A processing and Bel Canto services.

Regardless of whether the viewer subscribes to low latency or CDN links, it can resist weak networks, and supports viewers to switch to only audio subscriptions or subscribe to smaller-sized videos when the network is poor.

Looking back, let's talk about the benefits of Rongyun CDN. First, the CDN distribution cost is low, and the cost consumption is often much lower than that of the RTC link, which is very good for price-sensitive projects; secondly, with the help of Rongyun's service nodes around the world, the transnational live broadcast of overseas business can also respond quickly; finally, Rongyun and Major CDN vendors have cooperated to adjust links to meet different project requirements and support individual requirements such as video transcoding and encryption.

After reading the above sharing, when developing live broadcast applications, which link do you prefer for content distribution? Welcome to click the link participate in the interaction, and get Rongyun consulting service in 10 seconds.