1 Introduction
Without any development, it is possible to realize real-time video live broadcast with zero lag in a weak network environment. Does it sound like a fantasy? After reading this article you will know how we did it.
study Exchange:
- Instant messaging development exchange group: 320837163 [Recommended]
- Introductory article on mobile IM development: " One entry is enough for beginners: developing mobile IM from scratch "
(This article is simultaneously published at: http://www.52im.net/thread-1406-1-1.html )
2. Related articles
3. The author of this article
4. The pain point of live video: Caton
Caton is one of the factors that most affects the live broadcast experience, and it is also one of the most difficult problems to solve. In the transmission link of streaming media, packet loss in any link may cause users to watch freezes.
Among them, the streaming freeze on the anchor side affects the viewing experience the most, and will directly affect all end users watching the live broadcast. In some scenarios, the stream jam of the anchor will be particularly noticeable. For example, the outdoor live broadcast will test the stability of the stream in the case of complex network conditions.
Reducing lag has always been a major technical challenge for developers, so continue to see what kind of countermeasures we have?
Since Google launched the QUIC protocol in 2014, it has been practicing the protocol on audio and video products. Now, after more than a year of exploration and practice, our live streaming cloud products have embraced QUIC. The latest live streaming QUIC push solution can greatly reduce the problem of live streaming, and can provide customers with services in various complex network environments. Excellent live streaming experience. (For a detailed introduction to the QUIC protocol, please read " Technical Literacy: A New Generation of UDP-Based Low-Latency Network Transport Layer Protocol - QUIC Detailed Explanation ")
5. What is QUIC and why can it reduce lag?
Since QUIC can solve such an important live broadcast experience problem, let's first understand the QUIC protocol as a whole (for a detailed introduction to the QUIC protocol, please read " Technical Literacy: A New Generation of UDP-Based Low-Latency Network Transport Layer Protocol - QUIC Details " ).
5.1 Definition of QUIC Protocol
QUIC stands for Quick UDP Internet Connection, which is a low-latency Internet transmission protocol based on UDP protocol developed by Google.
We know that the TCP/IP protocol suite is the foundation of the Internet. There are only two transport layer protocols: TCP and UDP. Compared to the TCP protocol, UDP is more lightweight, but has much less error checking. Since UDP is an unreliable protocol and does not guarantee in-order delivery, its reliability is not as good as that of TCP.
The QUIC transport layer is based on the UDP protocol but is a reliable transport protocol because it shifts many of the reliability verification strategies from the system layer to the application layer, so that congestion control strategies more suitable for modern streaming media can be used.
Regarding the differences between TCP and UDP, the following articles can give you some answers:
" Briefly describe the difference between the transport layer protocol TCP and UDP "
" Why does QQ use the UDP protocol instead of the TCP protocol? 》
5.2 The position of QUIC in network transmission
As can be seen from the figure, the QUIC transport layer replaces TCP with the UDP protocol. (In addition, for a more in-depth computer network protocol diagram, please refer to " Computer Network Communication Protocol Diagram (Chinese Collector's Edition) [Attachment Download] ")
5.3 Why QUIC has advantages in transport
From all the above definitions of QUIC, it is obvious that the comparison object of QUIC is TCP. So all the enumerations of advantages below are based on a comparison of QUIC and TCP.
[QUIC Advantage 1: Better Congestion Control]
Although protocols such as HTTP/2 or SPDY now support the transfer of multiple pages of data over a data link, this feature does speed up the transfer of data. However, since the TCP protocol processes packets in a strict order, it still encounters the problem of head-of-line blocking.
For example, when the problem in the scenario shown in the figure below occurs, when one of the data is not sent successfully, the TCP connection needs to wait for the packet to be retransmitted before proceeding. Therefore, even if logically a TCP connection is multiplexed in parallel, other unrelated data will be blocked because of this:
The QUIC protocol uses the UDP protocol directly through the transport layer to avoid this problem. Since the UDP protocol does not have strict sequence requirements, when a data packet encounters a problem and needs to be retransmitted, it will only affect the resources corresponding to the data packet, and other independent resources will not be affected and block transmission:
[QUIC advantage 2: more flexible]
The TCP protocol stack is usually implemented at the operating system level, such as Linux, Windows, iOS, and Android operating systems. Therefore, if you want to modify the TCP protocol, you need to do a lot of things from the operating system level, which is a complicated project. Relatively speaking, the UDP protocol is simpler to implement at the operating system level. Based on UDP, QUIC has done a lot of optimizations at the network congestion control level at the application layer to help users reduce the stall rate in complex networks and improve fluency, which TCP cannot do. arrived.
5.4 QUIC Summary
As can be seen from all the above introductions, if we need to use QUIC to improve the live broadcast experience, it is to use it to replace the role played by the TCP protocol in live broadcast. Everyone knows that the protocol used in live broadcast is basically RTMP protocol, and the transport layer of RTMP protocol is based on TCP protocol. Therefore , our QUIC streaming solution is to replace the transport layer protocol in RTMP with QUIC, so as to achieve the effect of reducing the streaming jam rate .
6. The effect of using QUIC
The above mentioned so many theoretical advantages of media transmission based on QUIC, so is there any actual experimental test as theoretical support? Let's take a look at the test data.
Test parameter configuration:
test method:
In the weak network environment simulated by ATC, use the srs player to play for 5 mins, and record the fluency and the number of freezes.
6.1 Weak network configuration in test scenario 1
ATC configuration: delay 100ms loss 1%
The results are shown in the figure:
6.2 Weak Network Configuration 2 in Test Scenario
ATC configuration: delay 200ms loss 10%
The test results are shown in the figure:
Under the network configuration of TCP, it cannot be pushed up, or it will be disconnected after pushing for a while.
Attachment: More Live Video Technical Articles
[1] Articles on open source real-time audio and video technology WebRTC:
" Current Situation of Open Source Real-Time Audio and Video Technology WebRTC "
" Interview with the Father of the WebRTC Standard: The Past, Present and Future of WebRTC "
" Sharing Conscience: WebRTC Zero Basic Developer Tutorial (Chinese) [Attachment Download] "
" Introduction to the overall architecture of WebRTC real-time audio and video technology "
Getting Started: What is a WebRTC server, and how does it connect to calls ? 》
" WebRTC real-time audio and video technology foundation: basic architecture and protocol stack "
" On the technical points of developing a real-time video live broadcast platform "
" [Viewpoint] Four reasons why WebRTC should choose H.264 video encoding "
" Real-time Communication RTC Technology Stack: Video Codec "
[2] Other highlights of real-time audio and video development:
" Instant Messaging Audio and Video Development (1): Theoretical Overview of Video Coding and Decoding "
" Instant Messaging Audio and Video Development (4): Introduction to Video Codec Prediction Technology "
" Instant Messaging Audio and Video Development (6): How to Start Learning Audio Codec Technology "
" A Brief Description of Audio Processing and Coding Compression Technology in Real-time Voice Chat "
" NetEase Video Cloud Technology Sharing: Quick Start to Audio Processing and Compression Technology "
" Learn RFC3550: Basic knowledge of RTP/RTCP real-time transport protocol "
" On the technical points of developing a real-time video live broadcast platform "
" How to use the easiest way to test your real-time audio and video solutions "
" Technology Revealed: Facebook Live Video Broadcasting Supporting Millions of Fans to Interact "
" Detailed Explanation of Mobile Real-time Audio and Video Live Technology (2): Collection "
" Theory and Practice: Realizing a Simple HTML5-based Live Video Broadcasting "
" Detailed explanation of echo cancellation technology during IM real-time audio and video chat "
" Introduction to Android Live Streaming Practice: Build a Simple Live Streaming System by Hand "
" Real-time audio and video chat technology sharing: anti-packet loss codec for unreliable networks "
How does P2P technology reduce the bandwidth of live video broadcasting by 75%? 》
" Qiniu Cloud Technology Sharing: Using QUIC Protocol to Realize Live Video Live with 0 Stalls! 》
(This article is simultaneously published at: http://www.52im.net/thread-1406-1-1.html )