This paper is participating in theNetwork protocols must be known and must be known”Essay campaign
directory
RTMP
I. General introduction
Two, structure composition
1. The structure of the Message
2. The structure of the Chunk
Matters needing attention:
Audio Chunk
Video the Chunk
3. Relationship between Message and Chunk
4. The Message type
3. Establish a handshake
4. Save the file
V. Comparison with other agreements
RTMP
I. General introduction
RTMP(Real Time Messaging Protocol) is an open Protocol developed by Adobe for audio, video, and data transmission between Flash players and servers. The RTMP protocol works on top of TCP and uses port 1935 by default.
How it works: RTMP messages are divided into N chunks and transmitted over TCP.
Why is RTMP based on TCP, which has a way of dividing messages into smaller chunks?
Analyze the reasons:
-
TCP divides TCP packets to ensure data continuity and retransmission at the network transport layer.
-
RTMP divides chunk message blocks to achieve low latency at the network application layer, preventing large data blocks (such as video data) from blocking small data blocks (such as audio data or control information).
Two, structure composition
1. The structure of the Message
The structure of the RTMP Message Header is shown as follows:
Parameter analysis:
Message Type (1 byte) : indicates the Type of the Message. This parameter is important because different programs need to handle different messages.
Payload Length (3 bytes) : the Payload length (big-endian format).
Timestamp (4 bytes), the Timestamp (big-endian format) is reversed when the maximum value is exceeded.
Stream ID (3 bytes) message flow ID (big-endian format), which is used to distinguish messages from different streams.
Message Payload, real data.
2. The structure of the Chunk
Data sent and received by RTMP is called Message. The so-called Message is nothing more than audio and video data and signaling. When sending and receiving data, Message is split into chunks and sent. Chunk consists of Chunk Header and Chuk Data.
2.1 the Chunk header:
The structure of the RTMP Chunk Header is as follows:
2.2 the Basic header:
RTMP Chunk Basic Header (RTMP Chunk Basic Header), usually one byte in size, as shown in the following figure:
An RTMP Chunk packet consists of a fixed-length header and a Chunk default-size body (128 bytes by default). The header can be any of the following four lengths: 12, 8, 4, or 1 byte(s).
The first two bits of the first byte are important because they determine the length of the packet header, which can be “and” evaluated with the mask 0xC0.
Format =0, Chunk Header length = 12 bytes. This block must be present at the beginning of a Chunk stream and when the timestamp is returned, for example, onMetaData, the absolute timestamp at the beginning of a stream, and the control message.
At this point, the structure of the base header and the block header (Basic Header + Chunk Msg Header) is shown below:
Format =1, Chunk Header length = 8 bytes. For Chunk streams of variable size messages, this format should be used for the first block of each message after the first message.
At this point, the structure of the base header and the block header (Basic Header + Chunk Msg Header) is shown below:
Format =2, Chunk Header length = 4 bytes. For Chunk streams of fixed size messages, this format should be used for the first Chunk of each message after the first message.
At this point, the structure of the base header and the block header (Basic Header + Chunk Msg Header) is shown below:
Format =3, Chunk Header length = 1 bytes. When a message is divided into multiple blocks, all blocks except the first one should use this type.
At this point, the structure of the base header and the block header (Basic Header + Chunk Msg Header) is shown below:
Matters needing attention:
1) The length of timestamp is 3 bytes. When timestamp is set to 0x00FFFFFF, the chunk header will add an Extended Time Stamp field. Otherwise Extended Time Stamp will not appear.
2) How do multiple chunks belong to the same Message?
First, it is distinguished by Chunk Stream ID. The same Chunk Stream ID belongs to the same Message.
Second, because TCP is ordered, different chunks of the same Message arrive one after another.
Audio Chunk
Taking FLV AAC as an example, the protocol layer structure is shown as follows:
The structure of FLV AudioTagHeader is shown as follows:
Video the Chunk
Taking FLV AVC as an example, the protocol layer structure is shown as follows:
The structure of FLV Video header is shown as follows:
The structure of FLV VideoTagBody is shown as follows:
3. Relationship between Message and Chunk
3.1 Message Structure:
3.2 Message Splitting Chunk Instances:
4. The Message type
Message messages are classified into three types: protocol control messages, data messages, and command messages.
A. Protocol control message
Message Type ID = 1 to 6, used for intra-protocol control.
B. Data messages
Message Type ID = 8 9 18(15) where
8: Audio Audio data
9: Video Data
18(15): corresponding to AMF0(AMF3), Metadata includes audio and video coding and video width and height information.
C. Command Message (20, 17)
This type of message mainly has NetConnection and NetStream two classes, two classes have multiple functions respectively, the call of the message, can be understood as a remote function call.
Here’s the last one, just to make it more graphic:
3. Establish a handshake
1. Failed to connect (two attempts)
2. Successful connection (handshake)
2.1 Handshake Process:
2.1.1 Simple Handshake Mode
2.1.2 Complex Handshake Mode
Let’s take a look at the process using the wireshark:
2.2 push flow
2.3 pull flow
4. Save the file
In the FLV file format, you can determine whether the file is FLV based on the first three bytes of the file, including F (46), L (4c), and V (56).
V. Comparison with other agreements
In fact, there are other streaming media protocols similar to RTMP, HLS and HTTP-FLV. The following figure makes a simple comparison of the three.
About the author: Hello everyone, I am Data-Mining (Liuzhen007), an audio and video technology enthusiast. I have worked for traditional broadcasting giants and audio and video Internet companies before and after. I have rich experience in audio and video live broadcast and vod, and have a very deep understanding of WebRTC, FFmpeg and Electron. Public account: play audio and video. Also CSDN blog expert, Huawei cloud community cloud sharing expert, signed the author, welcome to pay attention to me to share more dry goods!