RTSP rtmp http Comparison

reproduced in this document: Http://www.cnblogs.com/my_life/articles/5593892.html, thank the blogger enthusiastic dedication

The following content is reproduced:

Http://blog.chinaunix.net/uid-26000296-id-4932817.html

Http://blog.chinaunix.net/uid-26000296-id-4932822.html

http://blog.csdn.net/zhangxinrun/article/details/50739237

In the live app, rtmp and HLS can basically cover all the clients watching,
HLS mainly is the delay is relatively large, the main advantage of RTMP is the low delay.

1. The features of rtmp are as follows:

1) Adobe supports it very well:
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 huge PC market, the PC is mainly windows,windows browser basically support Flash,
Flash also supports rtmp support very well.
2) Suitable for long time playback:
Because rtmp support is very perfect, so can flash play rtmp stream for a long time,
At that time the test was 1 million seconds, that is, more than 10 days can be played continuously.
For commercial streaming 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 educational client who originally played the HTTP stream with the player and needed to play different files, and the result was always a problem.
If the server side to convert different files to rtmp stream, the client can always play;
The customer after the rtmp scheme, after the CDN distribution, did not hear the client problems.
3) Low Latency:
The rtmp delay is large (delayed in 1-3 seconds) compared to the type of UDP private protocol yy.
RTMP is low latency compared to the latency of the HTTP stream (typically over 10 seconds).
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 we generally listen when others are speaking,
In fact, the 1-second delay does not matter, we also have to think (say some people's CPU processing speed is not so fast).
4) 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 accumulated delays;
Wait for the network condition is good, send to the client together.
The solution to this is thatwhen the client's buffer is large, it disconnects the heavy connection。

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, and it is estimated that the processing of the cache is caused by multi-process communication.
. 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.

4. Gop-cache

What is a GOP. is the time distance of two I frames in the video stream. What is the effect of the
GOP.
Flash (decoder) only gets the GOP to start decoding playback.
that is, the server generally gives an i-frame to flash first.
Unfortunately the problem comes, assuming that the GOP is 10 seconds, that is, every 10 seconds has a keyframe,
if the user starts playing in the 5th second, what happens.
The first scenario: wait for the next I-frame,
that is, wait 5 seconds before starting to give the client data.
This delay is very low, always in real-time flow.
The problem is: wait for this 5 seconds, will be black screen, the phenomenon is the player card there, nothing,
Some users may think that the dead, will refresh the page.
in short, some customers think that waiting for KeyFrames is an unforgivable error, and what is the relationship between delays.
I want to be able to start and play the video quickly, it's best to turn it on.


Second scenario: Start now, and
put what.
You must know, put the previous I-frame.
that is, the server needs to always cache a GOP,
so that the client comes up on the previous I-frame to play, you can quickly start. The
problem is that the delay is naturally large.


There are no good scenarios. The
has. There are at least two types: the
Encoder lowered the GOP, such as a GOP for 0.5 seconds, so that the delay was low and did not have to wait. The disadvantage of the
is that the encoder compression rate is reduced and the image quality is not that good.


5. Cumulative Delay

In addition to Gop-cache, there is a relationship, that is, cumulative delay.
The server can configure the length of the live queue, and the server will put the data in the live queue,
If more than this length is emptied to the last I frame:


Of course this cannot be configured too small,
For example, GOP is 1 seconds, queue_length is 1 seconds, this will cause 1 seconds of data will be emptied, will cause jumping.


There's a better way. Some.
Latency is basically equal to the client's buffer length because the latency is mostly due to low network bandwidth,
Server cache is sent to the client together, the phenomenon is that the client's buffer becomes larger,
For example, netstream.bufferlength=5 seconds, then there is at least 5 seconds of data in the buffer.


The best way to handle the cumulative delay is for the client to detect that the buffer has a lot of data and, if possible, to re-connect the server.
Of course, if the network has been bad, there is no way.

I. Comparison of distribution methods

Two main ways to distribute on the Internet: HLS and rtmp,
When to use who, it is entirely decided by the application scenario.
There are other means of distribution that are not part of the common and common approach of the Internet and are not compared:
. Udp:
such as YY real-time applications, video conferencing and so on, or RTSP.
This type of application is characterized by a particularly high real-time requirement, in milliseconds。
The TCP family protocol simply does not meet the requirements, so http/tcp are not reliable.
Such applications do not have a common scenario and must implement their own distribution (server side) and playback (client).
. P2p:
such as RTMFP or each of their own agreements.
This type of application is characterized byBandwidth Savings。
At present, the Pc/flash on the RTMFP more mature, Android on the start of the peer dispute standards vary,
You should not have heard about iOS on the peer.
. RTSP:
This is not the main application on the Internet, in other areas such as security, such as a wide range of applications.


In addition, there are several types of http:
. HTTP Progressive:
When an early streaming media server distributes HTTP files, it is distributed as normal HTTP files, which are called progressive downloads,
This means that if the file is large, such as 1 hours long 1GB size, it is not possible to start playing from the middle.
But this way is already dead, many HTTP server support HTTP file seek, is starting from the middle to play.
. HTTP Stream:
An HTTP stream that supports seek, such as on-demand distribution for each video site.
Or a little more complicated, such as having a large file cut after a few paragraphs and distributing it.
The current on-demand domestic mainstream distribution in Pc/flash is this way.
. HLS:
This is now the most adaptable way (except flash, which requires additional as library support),
The Vlc,android/ios native player on the PC supports playback of the URL in the HLS,HTML5 to write the HLS address.
In short, the mobile side is based on HLS.
. Hds:adobe own HLS, a lump of excrement.
. DASH: The HLS proposed by the family is not yet widely used.


Compare the following streaming media distribution methods used on the Internet:
. Hls:apple HLS, support on-demand and live streaming.
. http: http stream, each of its own defined HTTP streams, applied to domestic video-on-demand sites.
. RTMP: Live application, the real-time requirements, to the PC-based.


Second, RTMP

1. rtmp is essentially a streaming protocol, and the main advantages are:
. 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.
. 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:
The most stable mode of flash playback on a PC platform is rtmp,
If you do CDN or large and medium-sized cluster distribution, choosing a high-stability protocol must be necessary.
HTTP is also stable, but HTTP is stable on the protocol;
Stability is not just a service-side thing, in cluster distribution, server management, primary and standby switching, client support,
Rtmp still has an edge in the way PC is distributed.
. 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 a variety of devices, such as providing cloud services;
Or you want the Web to capture the camera directly, or you can switch between different encoders,
Then rtmp will be the best choice for the server input protocol.
. System Fault Tolerance:
There are many levels of fault tolerance, which can be specified when an RTMP cluster is implemented, and the switch does not affect the lower or the client when the error occurs.
In addition, the stream of rtmp is not identified, and the stream to other servers can 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.


2. The disadvantages of rtmp are:
. Protocol complexity:
The RTMP protocol is much more complex than HTTP, resulting in poor performance.
The test found two servers directly connected to the 100GBPS network, HTTP can run to 60Gbps, but rtmp can only run to 10Gbps,
CPU usage 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 a big line,
Apache/nginx/tomcat,n multiple HTTP server;
The RTMP protocol, though long overdue, has really been distributed on a large scale and has not done well,
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.


Third, HTTP

HTTP is talking about HTTP streams, such as on-demand streaming of major video sites.
HTTP is essentially a file distribution, and the main advantages are:
. Performance is High:
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. The
It is blocked by any port and does not cause HTTP streaming to be seen. (But rtmp can also wear walls, with rtmpt protocol).


The disadvantages of HTTP are:
. 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.


Four, HLS

HLS is an open standard for Adobe and is natively supported in ANDROID3.
The main advantages of HLS are:
. High performance: As with HTTP.
. Through the wall: like HTTP.
. Native support is good: support is perfect on iOS. Support on Android is poor. Pc/flash also now has various as plugins to support HLS.


The main disadvantages of HLS are:
. Poor real-time: basically HLS delay is more than 10 seconds.
. File fragmentation: Small file distribution is not very friendly if HLS is distributed, the stream is low, and the slices are small.
In particular, some storage-sensitive situations, such as the storage of the source station, embedded SD card.


Five, the application method

The recommended way is:
. Encoder output RTMP protocol.
. Streaming media system Access uses the RTMP protocol.
. Streaming media system for live distribution using RTMP.
. pc+ Live + real-time requirements High: use Flash to play rtmp.
. pc+ Live + No real-time requirements: Use rtmp or HLS.
. pc+ on Demand: Using HTTP or HLS.
. Apple ios/osx: Both use HLS (real-time requirements to parse rtmp yourself, or use an external library,
such as https://www.vitamio.org)
. Andorid: As with iOS, it's OK to develop support rtmp yourself.

===============================================================================

The similarities and differences between RTSP, RTMP, and HTTP

Common:

1:RTSP RTMP HTTP is applied at the application layer.

2: Theoretically RTSP rtmphttp can do live and on-demand, but generally do live with RTSP RTMP, do on-demand http. Video conferencing when the original SIP protocol, and now basically replaced by the RTMP protocol.

Difference:

1:http: Hypertext Transfer Protocol (FTP is a file Transfer Protocol).

HTTP: (Real Time streaming Protocol), live streaming protocol.

HTTP Full Name routing table maintenance Protocol (Routing Table Maintenance Protocol).

2:http all the data as a file. The HTTP protocol is not a streaming media protocol.

RTMP and RTSP protocols are streaming media protocols.

The 3:rtmp agreement is Adobe's private agreement, which is not fully disclosed, and the RTSP protocol and the HTTP protocol are common agreements and have specialized agencies for maintenance.

The 4:RTMP protocol generally transmits the FLV,F4V format stream, and the RTSP protocol generally transmits a stream in the Ts,mp4 format. HTTP does not have a specific stream.

5:RTSP transmission generally requires 2-3 channels, command and Data channel separation, HTTP and rtmp generally on a TCP channel to transmit commands and data.

RTSP, RTCP, RTP differences

1:RTSP Real-Time Streaming protocol

As an application-level protocol, RTSP provides an extensible framework that makes it possible to control and on-demand real-time streaming media data. In general, RTSP is a streaming media representation protocol that is primarily used to control data transmission with real-time characteristics, but it does not transmit data by itself, but must rely on some of the services provided by the underlying transport protocol. RTSP can provide streaming media such as play, pause, fast forward and other operations, it is responsible for defining the specific control message, operation method, status code, etc., also describes the interaction with RTP (RFC2326).

2:RTCP Control Protocol

The RTCP control protocol needs to be used in conjunction with the RTP data protocol, and when an application initiates an RTP session, it consumes two ports, respectively, for RTP and RTCP. RTP by itself does not provide a reliable guarantee for sequential transmission of packets, nor does it provide traffic control and congestion control, which is done by RTCP. Typically, the RTCP uses the same distribution mechanism as RTP to periodically send control information to all members of the session, and the application receives the data, obtains information about the session participants, and feedback such as network conditions, packet loss probabilities, and so on to the quality of service into control or diagnose network conditions.

The functions of the RTCP protocol are implemented by different RTCP datagrams, mainly in the following categories:

SR: Send-side report, the so-called sender is the application or terminal to emit RTP datagram, the sender can also be the receiving side. (server time is sent to client).

RR: The receiving side reports that the so-called receiver is the application or terminal that receives but does not send RTP datagrams. (The server receives a response sent by the client side).

SDEs: Source Description, the main function is as a member of the session on identity information carrier, such as user name, e-mail address, telephone number, and also has the ability to communicate session control information to the session members.

BYE: Notification departure, the primary function is to indicate that one or several sources are no longer valid, that is, the other members in the notification session will exit the session themselves.

App: defined by the application itself, it solves the extensibility problem of RTCP and provides a great deal of flexibility for the implementation of the Protocol.

3:RTP Data Protocol

RTP Data Protocol is responsible for the streaming media data packets and the real-time transmission of media streams, each RTP datagram by the head (header) and load (Payload) two parts, wherein the head of the first 12 bytes meaning is fixed, while the load can be audio or video data.

The place that RTP uses is PLAY, the server transmits data to the client with the UDP protocol, RTP is a 12-byte header (description information) in front of the transmitted data.

RTP Payload Package Design This paper's network transmission is based on the IP protocol, so the maximum transmission Unit (MTU) maximum of 1500 bytes, when using the IP/UDP/RTP protocol hierarchy, which includes at least 20 bytes of IP header, 8 bytes of UDP header, and 12 bytes of RTP header. This way, the header information takes at least 40 bytes, and the maximum size of the RTP payload is 1460 bytes. Taking H264 as an example, if a frame of data is greater than 1460, it needs to be fragmented and then unpacked to the receiving end and then assembled into one frame of data for decoding playback.