RTMP, HTTP, HLS protocol comparison

RTMP HLS HTTP Live protocol one time to see enough

Live from 2016 to 2017 years of fire, now in their own app to join the live broadcast function, just find a ready-made SDK on the line, what shooting, beauty, push flow, one-stop service. But as the most important part of the live stream: The push-flow protocol, many people are not very clear. If you're interested in live streaming and want to learn about the various mechanisms behind it, you can start by understanding the push-flow protocol in this article.

Purely from a technical point of view, the ability to implement live streaming protocol, more commonly used is rtmp HLS http this technology. But they will have a few different options in particular to the application scenario.

RTMP

The real time Messaging protocol Live Messaging Protocol is an Adobe company's proprietary protocol for the development of audio, video, and data transmissions between flash players and servers, not fully disclosed. Keywords: block! The majority of the current show live using the protocol.

Advantages: High Real-time:

RTMP real-time in 3 seconds, after the multi-tier CDN node distribution, real-time is about 3 seconds. In some of the real-time requirements of the application of rtmp-based. Compared to the kind of UDP private protocol yy, RTMP calculation delay, compared to the HTTP stream delay (typically more than 10 seconds) rtmp low latency. For general live streaming applications, rtmp latency is acceptable as long as it is not the type of phone conversation. In general video conferencing applications, rtmp delay can also be accepted, because others in the speech when we generally listen, in fact, 1 seconds delay does not matter, we also have to think (say some people CPU processing speed is not so fast).

Measured and detected, when the network is in good condition:
. RTMP delay can be achieved in about 0.8 seconds.
. Multi-level edge nodes do not affect latency (and SRS-homologous CDN Edge servers can do)
. Nginx-rtmp latency is a bit large, it is estimated that the processing of the cache, multi-process communication caused?
. The GOP is a tough, but the SRS can close the GOP cache to avoid this effect.
. Server performance is too low, it can also cause the delay to become larger, the server too late to send data.
. The client's buffer length also affects latency. For example, the Flash client's netstream.buffertime is set to 10 seconds, then the delay is at least 10 seconds.

High encoding Compatibility:

RTMP is actually an industry standard protocol for encoder output now, and basically all encoders (cameras and the like) support rtmp output. The reason is the PC market is huge, the PC is mainly windows,windows browser basically support Flash,flash and support rtmp support is very good.

Support encryption:

Rtmpe and Rtmps are cryptographic protocols. Although HLS also has encryption, but on the PC platform Flash to rtmpe/rtmps support should be quite good.

High Stability:

On the PC platform the most stable flash playback is rtmp, if you do CDN or large and medium-sized cluster distribution, choose a high stability protocol must be necessary. HTTP is also stable, but HTTP is stable on the protocol, stability is not just the service side of the thing, in the cluster distribution, server management, primary and standby switching, client support, rtmp in the PC distribution this way is still very advantageous.

Because rtmp support is very perfect, so can flash play rtmp stream for a long time, the test is 1 million seconds, that is, more than 10 days can be played continuously. For commercial streaming media applications, the stability of the client is of course also necessary, otherwise the end user can not see how to play? I knew there was an education client, the initial use of the player to play the HTTP stream, the need to play different files, the result is always a problem, if the server side to convert the different files to rtmp stream, the client can play all the time, the customer after the rtmp scheme, after the CDN distribution, did not hear the client problem.

Encoder Access:

The encoder outputs to the Internet (which can also be output as a UDP multicast application), mainly rtmp. For example, professional encoders, or flash Web encoders, or FMLE, or ffmpeg, or security cameras, support rtmp output. If you need to access multiple devices, such as a cloud service, or if you want a Web page to capture a camera directly, or you can switch between different encoders, rtmp is the best choice for the server's input protocol.

System Fault Tolerance:

There are many levels of fault tolerance, the RTMP cluster implementation can specify n upper level, in the error when the switch does not affect the lower or the client, the rtmp stream is not identified, cut to the other server stream can also continue to play. The stream hot standby switch of HLS is not so easy. Choosing rtmp is a good choice if you have high fault tolerance requirements for live streaming, such as reducing the probability of a problem.

can monitor:

In the view of monitoring system or operation and maintenance system, the flow protocol should be more suitable for monitoring. The flow monitoring of HTTP is not so perfect. This is not an absolute advantage, but more advantageous.

Disadvantage: Poor playback compatibility:

RTMP biggest weakness, because it is Adobe's private agreement, many devices can not play directly, such as iOS, need to plug the third-party decoder, which will bring heat, power and other problems. HTML5 is also unable to play rtmp directly, so you can see a lot of live streaming on the mobile page, which is pushed by HLS below.

Protocol complexity:

The RTMP protocol is much more complex than HTTP, resulting in poor performance.

Test found that two servers directly connected to the 100GBPS network, HTTP can run to 60Gbps, but rtmp can only run to 10GBPS,CPU occupancy rate rtmp is much higher. Complex protocols lead to the development, expansion, maintenance of software systems without HTTP so convenient, so the HTTP server is now big line, Apache/nginx/tomcat,n Multi-HTTP server, and the RTMP protocol, although long-time public, but really in large-scale distribution of good performance did not , Adobe's own FMS often has problems in the CDN.

Cache trouble:

Streaming protocol caching is inconvenient. For example, on-demand, if you do rtmp streaming protocol, edge cache rtmp will be very troublesome. If it is HTTP, the cache is actually very cumbersome, but the HTTP server cache has been done for a long time, so only need to use just fine. This is the reason why on-demand HTTP is on the go.

There is a cumulative delay:

Technology must know weaknesses, rtmp has a weakness is cumulative error, because rtmp based on TCP will not drop packets. Therefore, when the network status is poor, the server will cache the package, resulting in a cumulative delay; When the network condition is good, it is sent to the client together. The solution to this is that when the client's buffer is large, it disconnects the re-connection.

HTTP

HTTP is talking about HTTP streams, such as on-demand streaming of major video sites. It's essentially a file distribution.

Advantages: High Performance:

HTTP performance has no say, the protocol is simple, a variety of HTTP high-performance server is also perfect. If the amount of distribution is particularly large, such as on-demand video sites, there is no real-time demand for live streaming, the HTTP protocol is the best choice.

No fragmentation:

HTTP is not fragmented than HLS, and HTTP distribution of large files can be much more convenient than small file distributions. Especially storage, small file performance is very low, is a mishap.

Through the wall:

The Internet cannot be open to the HTTP protocol, otherwise it is not called the Internet. So any port that is sealed off will not cause HTTP streaming to be seen. (But rtmp can also wear walls, with rtmpt protocol).

Disadvantage: Poor real-time:

There is basically no real-time explanation.

Native support is not good:

On the PC Flash for HTTP streaming support can also, Android/ios seems to only MP4, in short, the mobile side of the HTTP support is not very perfect.

HLS

HTTP Live streaming, an open standard for Apple, is based on an HTTP stream that was originally developed by Apple for mobile devices such as the iphone, IPod, itouch and ipad, and now sees many applications on the desktop, thanks to HTTP-based So many of the advantages of HTTP have been inherited.

Advantages: High Performance:

is the same as HTTP.

Through the wall:

is the same as HTTP.

High compatibility:

Native support for IOS, Android, HTML5.

Disadvantage: Poor real-time:

Basically HLS has a delay of more than 10 seconds.

File Fragmentation:

Small file distribution is not very friendly if you distribute HLS with low bitstream and smaller slices. In particular, some storage-sensitive situations, such as the storage of the source station, embedded SD card.

Summarize

. Pc/phone+ Live + real-time requirements High: use Flash to play rtmp.
. Pc/phone+ Live + No real-time requirements: Use rtmp or HLS.
. Pc/phone+ on Demand: Using HTTP or HLS.
. phone+web+ Live: What do you want, honestly use HLS bar.

Some people say, I want to broadcast on the mobile website again, and want him to delay low, how to do it. How can there be such a sentimental person in the world, asking so much, it happens that our company has such a person, is our supervisor. Our products focus on the light live, the player has no client, all through the web as a carrier to achieve. In fact, there are still a lot of solutions to achieve this goal. Most of the video streaming service providers have provided remote code functions, the stream pushed up, automatically encoded into rtmp and HLS, you want to give the app to take the rtmp stream, you want to give the Web use you take HLS. As for HLS delay, some vendors have started to launch an optimized version of the hls+ to optimize the HLS bottom to accommodate low latency live broadcast. According to our internal testing, we have been able to reduce the delay to about 7s, although not enough to catch rtmp, but also reluctantly available.

RTMP, HTTP, HLS protocol comparison