The HTTP protocol is the abbreviation of Hyper Text Transfer Protocol (Hyper Text Transfer Protocol), which is a transfer protocol for transferring hypertext from a World Wide Web (WWW: World Wide Web) server to a local browser. HTTP is based on the TCP/IP communication protocol to transfer data (HTML files, image files, query results, etc.). All www files must comply with this standard. HTTP was originally designed to provide a way to publish and receive html pages. In 1960, American Ted Nelson conceived a method of processing text information by computer and called it hypertext, which became the development foundation of the standard architecture of HTTP hypertext transfer protocol.
RTSP (Real Time Streaming Protocol) is a real-time streaming protocol and an application layer protocol in the TCP/IP protocol system. As an application layer protocol, RTSP provides an extensible framework, and its significance lies in making it possible to control and on-demand real-time streaming media data. In general, RTSP is a streaming media presentation protocol, which is mainly used to control the transmission of data with real-time characteristics, but it does not transmit data itself, but must rely on some services provided by the underlying transmission protocol. RTSP can provide operations such as play, pause, fast forward, etc. for streaming media. It is responsible for defining specific control messages, operation methods, status codes, etc., and also describes the interaction with RTP (RFC2326).
RTMP protocol is the abbreviation of Real Time Message Protocol (Real Time Message Protocol). It is an application layer protocol proposed by Adobe to solve the multiplexing and packetizing of multimedia data transmission streams. )The problem. Features are as follows:
- Suitable for long-time playback: Because RTMP supports very well, it can play the RTMP stream continuously for a long time in flash. At that time, the test was 1 million seconds, that is, it can be played continuously for more than 10 days.
- For commercial streaming media applications, the stability of the client is of course a must, otherwise how can the end user play if they can't see it? I know of an education client who initially used the player to play http streams and needed to play different files, but there was always a problem. If the server side converts different files into RTMP streams, the client can continue to play; the After the client adopted the RTMP solution, it was distributed through the CDN, and I never heard that there was a problem with the client.
- Low latency: Compared with YY's UDP private protocol, RTMP has a large delay (1-3 seconds delay), and RTMP has a low delay compared to HTTP streaming delay (generally more than 10 seconds). For general live broadcast applications, RTMP delay is acceptable as long as it is not the kind of requirement for telephone conversations. In general video conferencing applications, RTMP delay is acceptable. The reason is that we are generally listening when others are talking. In fact, a 1-second delay does not matter. We also need to think about it. So fast).
- There is cumulative delay: The technology must know the weakness. One of the weaknesses of RTMP is the cumulative error, because RTMP is based on TCP and will not lose packets. Therefore, when the network status is poor, the server will cache the packets, resulting in accumulated delay; when the network status is good, they will be sent to the client together. The countermeasure for this is to disconnect and reconnect when the client's buffer is large.
The RTP data protocol is responsible for encapsulating streaming media data and realizing real-time transmission of media streams. Each RTP datagram consists of two parts: header and payload. The meaning of the first 12 bytes of the header is Fixed, and the payload can be audio or video data. The place where RTP is used is PLAY. The server transmits data to the client using the UDP protocol. RTP adds a 12-byte header (description information) in front of the transmitted data. RTP payload encapsulation design The network transmission in this paper is based on the IP protocol, so the maximum transmission unit (MTU) is up to 1500 bytes. When using the IP/UDP/RTP protocol hierarchy, this includes at least 20 bytes of IP header , an 8-byte UDP header, and a 12-byte RTP header. In this way, the header information must occupy at least 40 bytes, so the maximum size of the RTP payload is 1460 bytes. Taking H264 as an example, if a frame of data is larger than 1460, it needs to be split and packaged, and then unpacked at the receiving end, combined into a frame of data, and decoded and played.
The RTCP control protocol needs to be used together with the RTP data protocol. When an application starts an RTP session, it will occupy two ports at the same time, which are used for RTP and RTCP respectively. RTP itself does not provide reliable guarantees for in-order transmission of data packets, nor does it provide flow control and congestion control, which are all done by RTCP. Usually, RTCP uses the same distribution mechanism as RTP to periodically send control information to all members in the session. By receiving these data, the application obtains relevant information of session participants, as well as feedback information such as network status and packet loss probability. , so that the quality of service can be controlled or the network status can be diagnosed.
The functions of the RTCP protocol are implemented through different RTCP datagrams, which mainly include the following types:
- SR: Sender report, the so-called sender refers to the application or terminal that sends out the RTP datagram, and the sender can also be the receiver. (SERVER fixed time to send to CLIENT).
- RR: Receiver report, the so-called receiver refers to an application or terminal that only receives but does not send RTP datagrams. (SERVER receives the response sent by the client).
- SDES: source description, the main function is to serve as the carrier of the identification information of session members, such as user name, email address, phone number, etc., and also has the function of conveying session control information to session members.
- BYE: Notify to leave, the main function is to indicate that one or several sources are no longer valid, that is, to notify other members of the session that they will exit the session.
- APP: Defined by the application itself, it solves the scalability problem of RTCP and provides great flexibility for the implementer of the protocol.
simply put:
- HTTP: Hypertext Transfer Protocol (ftp is File Transfer Protocol).
- RTSP: (Real Time Streaming Protocol), real-time streaming protocol.
- RTMP: The full name is Routing Table Maintenance Protocol.
HTTP handles all data as files. The http protocol is not a streaming protocol. RTMP and RTSP protocols are streaming media protocols.
Here's a little more information about streaming media:
GOP-Cache
What is GOP? It is the temporal distance between two I-frames in the video stream.
What is the impact of GOP?
Flash (decoder) can start decoding and playing only after getting GOP.
That is to say, the server generally gives an I frame to Flash first.
Unfortunately, the problem comes. Suppose the GOP is 10 seconds, that is, there are key frames every 10 seconds.
What if the user starts playing at the 5th second?
The first solution: wait for the next I frame,
that is, wait another 5 seconds before starting to send data to the client.
This way the latency is very low and the stream is always real-time.
The problem is: during the 5 seconds of waiting, the screen will be black. The phenomenon is that the player is stuck there and there is nothing.
Some users may think that they are dead and refresh the page.
In conclusion, some clients will consider waiting for keyframes an unforgivable mistake, so what does the delay matter?
I just want to be able to start and play the video quickly, preferably open and play!
The second option: start putting it right away, what to
put it on?
You must know, put the previous I frame.
That is to say, the server needs to always cache a gop,
so that the client can start playing from the previous I frame and start quickly.
The problem is: the delay is naturally large.
Is there a good plan?
have! There are at least two types: the
encoder reduces the GOP, such as 0.5 seconds a GOP, so the delay is also very low, and there is no need to wait.
The downside is that the encoder compression ratio will be lower and the image quality will not be as good.