Real-time message transmission protocol (rtmp)

Original article: http://blog.csdn.net/defonds/article/details/17403225

This article explains rtmp in Wikipedia. For more information about rtmp official specifications, see rtmp specifications. For more information about the Chinese version of rtmp official specifications, see the rtmp specifications officially published by Adobe. The original Wikipedia text is as follows:

The real-time message transmission protocol (rtmp) was initially developed by Macromedia for the transmission of audio, video, and data streams between flash players and servers on the Internet. After Adobe purchased Macromedia, it announced part of this agreement for public use.

The rtmp protocol has multiple variants:
1. Work on the TCP protocol and use the plaintext protocol with the default port number 1935.
2. rtmps uses the rtmp protocol For TLS/SSL connection.
3. rtmpe uses Adobe's own security mechanism to encrypt rtmp. Although its implementation details are private, they use industry-standard encryption primitives. The rtmpe design is flawed and does not provide actual security.
4. rtmpt is encapsulated inside the HTTP request to traverse the firewall protocol. Rtmpt is often used to set up TCP port 80 and 443 requests to bypass traffic filtering by many companies. Encapsulated sessions may carry pure rtmp, rtmps, or rtmpe packets.

Although the rtmp Protocol is intended to play flash videos, it is often used in other applications, such as Adobe livecycle data service.

 

Basic operations
Rtmp (except rtmfp) is a TCP-based, persistent connection protocol that provides low-latency communication. In order to smoothly transmit streams and transmit as much information as possible, rtmp streams are segmented, and the client and server can negotiate the segment length, although sometimes the segment length remains unchanged: the default segment length of audio data is 64 bytes, and the default segment length of video data and most other data types is 128 bytes. Segments from different streams are isolated and merged into a single connected segment. For long data blocks, rtmp carries a single-word segment header in each segment, so the overhead is very small. However, in fact applications, different segments do not overlap. Crossover and merging are completed at the data packet layer. rtmp packets are crossed through different active channels, this method is used to ensure that each channel meets its own bandwidth, latency, and other service quality requirements. In this model, cross rtmp packets are considered to be inseparable and do not overlap at the segmentation level.
Rtmp defines some virtual channels through which rtmp packets can be sent and received, and these channels operate independently of each other. For example, there may be a channel for processing RPC requests and responses, a channel for video stream data, a channel for audio stream data, and an out-of-band control information (segment length negotiation, and so on. In a typical rtmp session, several channels may be active simultaneously at any given time. When the rtmp data is encoded, a packet header is generated. The header defines other items, the ID to be sent to the channel, the timestamp (if needed) generated by this package, and the load of this package. The packet header is followed by the actual load of the package. The packet content is divided according to the length of the negotiated segment before being sent to the connection. The header itself does not segment, and the length of the header is not included in the length of the first segment of the package. In other words, the subject of segmentation is only the rtmp package load (audio data ).
At a higher level, rtmp compresses MP3 or AAC audio and flv1 video Multimedia Streams and uses the AMF (Action Message format) protocol for remote method calling (rpcs ). All the required RPC services are asynchronous. They use a single client/server request/Response Model and therefore do not require real-time communication.
Encryption
Rtmp sessions can be encrypted using either of the following two methods:
Use industry-standard TLS/SSL mechanisms. The underlying rtmp session is simply encapsulated in a common TLS/SSL session.
Rtmpe is used to encapsulate rtmp sessions in a lightweight encryption layer.
It is generally believed that TLS/SSL handshakes at the beginning of a session are very computation intensive. Adobe developed rtmpe as a lightweight alternative, providing a practical choice for high-traffic websites that provide encryption services. Adobe notifies rtmpe as a Secure Content Delivery method to avoid simulating client operations. This statement is incorrect. Rtmpe only uses the Diffie-Hellman mechanism and does not provide authentication from either party, which is prone to man-in-the-middle attacks during Session Initialization.
HTTP Tunnel
In the rtmp tunnel (rtmpt), rtmp data is sealed and exchanged over HTTP, from the client (in this case, the client is Media Player) (HTTP default port number ).
Because of the HTTP header, the rtmpt information is greater than the equivalent non-channel rtmp information. In scenarios where the non-channel rtmp is not available, for example, when the client is in a way that prevents non-HTTP and non-HTTPS network traffic, rtmpt can be conveniently used.
This protocol uses the Post URL to send commands and the post body to send AMF messages. Example:

[Plain]View plaincopyprint?

1. Post, open, and 1 HTTP/1.1

 

Used To open a connection.

 

Standard document
Adobe publicly declares the rtmp specification released in June 15, 2009. The specification ignores the key details of the implementation of the Protocol. It is difficult to integrate the rtmp Protocol into our program according to the released specifications. Too many necessary details are ignored, we can only learn and implement the application of this Protocol (such as librtmp), and determine the few details based on the test TCP/IP packet capture.
Adobe's license for the use of this Protocol requires the implementation of the rtmp server to meet this specification.
The standards released by Adobe lack the following details:

• There is no description of the rtmp handshake. If the handshake is incorrect, the server cannot transmit H.264/AAc content. If the handshake is incorrect, flash player will silently fail to receive H.264 content. However, all the client implementations work normally, because the rtmp server is more tolerant in this regard (including FMS ).
• The sent block is sent only in the maximum block size. Blocks larger than the maximum block size will still be sent. This block carries the entire block size header, but when the maximum block size is exceeded, A header of type 4 is sent, followed by the next part of the split.
• The description of stream management information is missing (31 and 32 ). The system sends these packages from time to time.

Data packet format

A data packet is sent by a TCP connection established between the client and the server. A data packet contains a header and an individual. The connection and control commands are encoded using AMF (Action Message format. The header is divided into the basic header (the separated block is displayed in the figure) and the block message header. The basic header is the unique unchanged part of the data packet. It is often composed of a composite byte. Two Valid bits represent the block type (in the standard format), and the rest constitute the stream ID. Based on the value of the former, some header fields can be ignored. These fields are derived from the previous data packet based on the subsequent values, the basic header can be expanded using two additional bytes (in the figure, there are three bytes in total ). The block message header contains meta-data information, such as the message size (in bytes), timestamp, and message type. The last value is a separate byte, which defines the package as an audio package, a video package, a command, and a "low-level" rtmp package such as an rtmp Ping.

In the following example, when a flash client executes the following code:

[JavaScript]View plaincopyprint?

1. VaR stream: netstream = new netstream (connectionobject );

This will generate the following blocks:

HEX Code	ASCII
0300 0b 68 00 00 191400 00 00 00 02 00 0C 63 72 65 61 74 65 53 74 72 65 61 6D 00 40 00 00 00 00 05	... @ I... C r e a t e t r e a m .@........

This package starts with a basic header of one byte. Two Valid bits (b00000011) define the block header Type 0, and the rest (b00000011) define the block Stream ID as 3. There are four possible values for the header type. Their meanings are as follows:

• B00 = 12-byte header (complete header ).
• B01 = 8 bytes-image type B00. Does not contain the Message ID (the last four bytes ).
• B10 = 4 bytes-contains the basic header and timestamp (3 bytes ).
• B11 = 1 byte-only contains the basic header.

The last type (B11) is often used to aggregate information. In the preceding example, the second message starts with the ID 0xc3 (b111_11, this means that all the message header fields must be transmitted with the stream ID 3 (exactly the messages on it ). The six lowest valid BITs constitute the stream ID. The value range is 3 to 65599. Some values have special meanings. For example, 1 represents an extended ID format, and two bytes will follow. The value 2 is used for underlying messages, such as ping and setting the client bandwidth.
The subsequent rtmp header bytes (including the values in the preceding data packet example) are described as follows:

• Byte #1 (0x03) = block header type.
• Byte #2-4 (0x000b68) = timestamp.
• Byte #5-7 (0x000019) = package length-in this example, It is 0x000019 = 25 bytes.
• Byte #8 (0x14) = Message Type ID-0x14 (20) defines an amf0 encoded command message.
• Byte #9-12 (0x00000000) = message stream ID. This is sorted by small ends (strange ).

The Message Type ID byte defines whether the current package contains audio/video data, a remote object or a command. Some possible values are as follows:

• 0x01 = set the package size message.
• 0x04 = ping the message.
• 0x05 = server bandwidth.
• 0x06 = client bandwidth.
• 0x08 = audio package.
• 0x09 = video package.
• 0x11 = An amf3 command.
• 0x12 = call (onmetadata will be sent in this way ).
• 0x14 = An amf0 command.

Followed by the header. 0x02 indicates a string of 0x63 0x72... 0x6d ("createstream" command ). 0x00 represents the transaction with the ID of 2.0. The last byte is 0x05 (null), indicating no parameter.
Invoke message structure (0x14, 0x11)
The preceding message types, such as ping and setting the client/server bandwidth, are considered as the underlying rtmp protocol messages. They do not use the AMF encoding format. In other words, the command message, whether it is amf0 (Message Type of 0x14) or amf3 (0x11), uses this format:

[Plain]View plaincopyprint?

1. (String) <command name>
2. (Number) <transaction ID>
3. (Mixed) <argument> ex. null, String, object: {key1: value1, key2: value2 ...}

The transaction ID is used for commands with replies. This value can be a string in the preceding example or one or more objects, each consisting of one key-value pair. The key of a key-value pair is often encoded as a string value, the value of a key-value pair can be any AMF numeric type, including complex types, such as arrays.
Ping message structure (0x04)
The Ping message is not AMF encoded. They start with a stream ID, carry a complete (Type 0) header, and have a message of Type 0x04. The header is followed by six Bytes:

• #0-1-ping type.
• #2-3-the second parameter (meaningful for a specific Ping type ).
• #4-5-the third parameter (Same ).

The first two bytes of the message body define the ping type. There are six possible values.

• Type 0-clear stream: it is sent when the connection has been established but there is no more data.
• Type 1-clear cache.
• Type 3-Client Cache Time. The third parameter holds this value in milliseconds.
• Type 4-reset the stream.
• Type 6-ping the client from the slave server. The second parameter is the current time.
• Type 7-pong replied by the client. The second parameter is the time when the client receives Ping.

Pong is the name of Ping reply, which uses the values described above.
Serverbw/clientbw message structure (0x05, 0x06)
This is associated with messages related to client upstream and server downstream bit rates. The message body consists of four bytes, indicating the bandwidth value. It may have an extended byte to set the limit type. There are three possible values: hard, soft, or dynamic (soft or hard ).
Set block size (0x01)
This value can be received in four bytes of the message body. The default value is 128 bytes. This message occurs only when you want to change the default value.
Protocol
Handshake
After a TCP connection is established, the rtmp connection will be established after the handshake of the three packets between the two ends (this is also referenced as a block in the official document ). In the official specification, it is described here as the client sends the package C0-2, the server sends the package S0-2, not to be confused with the rtmp package, the rtmp package will only interact after the handshake is complete. These packages have their own structure. C1 contains a field for setting "epoch" timestamp, but this field can be set to 0. as implemented by a third party, this package can be simplified. The client initializes the connection by sending a C0 package with a constant value of 0x03 representing the current Protocol version. It can directly follow C1 without waiting to receive S0. It has 1536 bytes, the first four bytes represent timestamp, and others are random (it can be set to 0 in a third-party implementation ). C2 and S2 are the echo of S1 and C1 respectively. After receiving them, the handshake is deemed to end.

Connection
In this regard, the client and server will negotiate the connection by interacting with AMF-encoded messages. These key-value pairs that contain the variables required to establish a connection. An example of a message from a client is as follows:

[Plain]View plaincopyprint?

1. (Invoke) "Connect"
2. (Transaction ID) 1.0
3. (Object1) {app: "sample", flashver: "Mac 10, 2, 153,2", swfurl: NULL,
4. Tcurl: "rtmpt: // 127.0.0.1/sample", fpad: false,
5. Capabilities: 9947.75, audiocodecs: 3191, videocodecs: 252,
6. Videofunction: 1, pageurl: NULL, objectencoding: 3.0}

The concept of an "app" is used by FMS and other cities and counties to define a container for audio/video and other content. The specific implementation is to define a folder under the service root directory, it contains media files to be streamed. The first variable contains the app name "sample", which is the name provided by the wowza server for testing. The flashver string is the same as the value returned by the getversion () method of action-script. Audiocodec and videocodec use double encoding. Their meanings can be found in the original specification. The value of videofunction is true, which is obviously the support_vid_client_seek variable. It is particularly interesting that objectencoding defines whether the rest of the communication uses the extended amf3 format. Because the current default version is 3, The Flash client must be explicitly notified to use amf0 using the action-script code. The server replies with serverbw, A clientbw and a setpacketsize message sequence, and finally follows an invoke and uses an instance message.

[Plain]View plaincopyprint?

1. (Invoke) "_ result"
2. (Transaction ID) 1.0
3. (Object1) {fmsver: "FMS/31.0, 5, 5, 1.0", capabilities:, mode}
4. (Object2) {level: "status", Code: "netconnection. Connect. Success ",
5. Description: "connection succeeded ",
6. Data: (array) {version "},
7. Clientid: 1728724019, objectencoding: 3.0}

Some of the above values are continuously loaded to a common action-script object, which is then passed to the netconnection event listener. Clientid creates a number for the session enabled for this connection. The object encoding must match the previously set value.
Play video
To start a video stream, the client sends a "createstream" call followed by a ping message, followed by a "play" call with the file name as the parameter. The server then replies with a series of "onstatus" commands and rtmp messages with video data.

After the connection is established, the media is sent by the rtmp message encapsulated in the flv tag content to audio and video of Type 8 and type 9.

 

HTTP tunnel (rtmpt)
This section describes the HTTP tunnel version of rtmp. It interacts with port 80 and transmits AMF data in the http post request and response. The connection sequence is as follows:

[Plain]View plaincopyprint?

1. Post/fc-ident2 HTTP/1.1
2. Content-Type: Application/X-FCS \ r \ n
4. HTTP/1.0 404 not found
6. Post, open, and 1 HTTP/1.1
7. Content-Type: Application/X-FCS \ r \ n
9. HTTP/1.1 200 OK
10. Content-Type: Application/X-FCS \ r \ n
11. 1728724019

The first request has a path/fcs/ident2, and the correct returned result is 404 failure to find the error. The client then sends a/Open/1 request, and the server returns a 200 OK message with a random number representing the session ID appended. In the preceding example, 1728724019 is returned in the response body.

[Plain]View plaincopyprint?

1. Post/idle/1728724019/0 HTTP/1.1
2. HTTP/1.1 200 OK
3. 0x01

From then on,/idle/<session ID>/<sequence #> polls the request. The session ID is generated by the server and returned, sequence is a number that increases progressively after 1. The correct response is an integer with an internal time indication in the message body, 200 OK. AMF data is sent by/send/<session ID>/<sequence #>.
Software Implementation
Client Software
The most widely used rtmp client software is Adobe Flash Player, which supports playback of audio and video streams from rtmp servers (when installed as a web browser plug-in ).
Only part of the open-source Media Player xbmc, which supports rtmp client software, provides initial support for playing rtmp (excluding rtmpe) streams.
The open-source command line tool rtmpdump is used to play back or save the entire rtmp stream (including Adobe rtmpe for encryption) to the disk. Rtmpdump can run on Linux, Android, Solaris, MacOSX, and most other UNIX-derived operating systems, or Microsoft Windows. Initially, all 32-bit Windows systems, including Windows 98, starting from Version 2.2, are supported, this software can only be installed on Windows XP or a later version of Windows (although the earlier version remains fully functional ).
A fork of rtmpdump, which does not contain the rtmpdump code that Adobe claims violates DMCA in the United States and is released as flvstreamer. Its development was a direct response from Adobe's resistance to rtmpdump in 2008. Flvstreamer can save audio streams or video streams from any rtmp server to the disk as long as rtmpe is not enabled for the stream. Flvstreamer runs on Windows XP or a later version of Windows, but does not support earlier versions of Windows.
In October 2009, The mplayer website restarted rtmpdump R & D in countries outside the United States. The existing version greatly improves functions and uses the C language for rewriting, which greatly exploits the advantages of C. In particular, the main functions are built into a library (librtmp), which can be easily used by other programs. Rtmpdump developers also provide librtmp support for other open-source projects (such as mplayer, FFMPEG, xbmc, curl, and VLC. These projects have full rtmp support for librtmp.
The open-source gnash, an alternative to Macromedia Flash Player on the Linux platform, is designed to support rtmp streaming for Linux.
Server Software
Some servers that fully execute rtmp include:

• Adobe FMS.
• Adobe lifecycle data service.
• Amazon S3 and Amazon cloudfront can use rtmp streams.
• Haxevideo is a multi-stream FLV Streaming Media Server fully developed by the haxe language.
• The Helix Universal Server of RealNetworks supports live and on-demand rtmp, rtmpt, and rtmps streams.
• Red5 Media Server is a Java open-source project that provides a powerful video stream and multi-user solution for Adobe Flash Player and other client technologies.
• Erlyvideo has a wide range of features: not only file streaming, but also can use rtmp for MPEG-TS or ShoutCast for flash client re-streaming.
• The unreal Media Server supports live streaming of rtmp streams in real time and cache.
• Wowza Media Server.
• Weborb Integration Server (Communication and cloud edition, providing rtmp/rtmpt/rtmps message and Media Streaming support for. NET and Java Enterprise Edition ).
• Freeswitch rtmp streaming media mod_rtmp is available and allows interconnection with other VoIP protocols (SIP, H.323.
• FFmpeg
• Nginx with rtmp Module
• Xsplit Broadcaster

Exploration and R & D

• Crtmpserver explorers reverse engineer the rtmfp protocol. It is still a semi-finished product.
• Blue5-a project intended to create an open-source version of rtmpe and rtmfp.
• Kbmmw is an Enterprise Edition multi-level development tool that supports rtmp in Delphi/C ++ builder.

For more information, see

• Rtmpdump
• Protected streaming info about rtmps and rtmpe
• Real Time media flow protocol (rtmfp), based on UDP
• Video on Demand (VOD)

References

• Http://help.adobe.com/en_US/flashlite/dev/4/WSa2ec538c80d45833-4e519ada123e088b6aa-8000.html
• Using RPC services in flex Data Services 2
• Http://livedocs.adobe.com/flashmediaserver/3.0/docs/help.html? Content1_01_overview_basics_13.html
• Http://blogs.adobe.com/flashmedia/2010/02/understanding_ado
• Http://trac.red5.org/wiki/Documentation/Tutorials/Ping
• "Updates: 2009-11-01"
• "Linux funding"
• Erlyvideo website

External link

• Adobe Developer page-rtmp-official specifications
• Osflash-rtmp OS

Original article: http://en.wikipedia.org/wiki/real_time_messaging_protocol.

Real-time message transmission protocol (rtmp)