RTMP protocol

1、What is RTMP ?

　　1.1　RTMP is a protocol used by the Flash Player to deliver real time objects, video, and audio to clients using a binary TCP connection or polling HTTP tunnel.

　　1.2　The protocol is a container for data packets which may be AMF or raw audio/video like found in the flv.

　　1.3　A single connection is capable of multplexing many net streams using different channels. ( 一个连接具备传递不同的流通道，比如视频channel和音频channel )Within these channels packets are split up into fixed size body chunks.

　　1.4　RTMPT basically is a HTTP wrapper around the RTMP protocol that is sent using POST requests from the client to the server. Because of the non-persistent nature of HTTP connections, RTMPT requires the clients to poll for updates periodically in order to get notified about events that are generated by the server or other clients.( 需要客户端定期的去轮询请求服务器上的数据 ).

 

2、Handshake

　　2.1　Client ---> Server : Sends Handshake Request. This is not a protocol packet but a single byte(0x03) followed by 1536 bytes. This content does not seem to be vital for the protocol, but is not random either.

　　2.2　Server ---> Client : Sends a Handshake Response. This is not a RTMP packet but a single byte(0x03) followed by two 1536 byte chunks(so a total of 3072 raw bytes). The second chunk of bytes is the original client request bytes sent in handshake request. The first chunk can be anything. Use null bytes is doesn't seem to matter.

　　2.3　Client ---> Server : Send 1536 raw bytes which are the second 1536 chunk of server generated handshake. At this time , handshake is done and further packets are RTMP ones.

　　2.4　Client ---> Server : send the Connect RTMP packet.

　　2.5　Server ---> Client : Server responds.

　　...and so on...

3、RTMP Datatypes

0x01	Chunk Size	changes the chunk size for packets
0x02	Unknown (AbortMessage)	anyone know this one? (32bit stream_id payload)
0x03	Bytes Read	send every x bytes read by both sides
0x04	Ping	ping is a stream control message, has subtypes
0x05	Server BW	the servers downstream bw
0x06	Client BW	the clients upstream bw
0x07	Unknown	anyone know this one?
0x08	Audio Data	packet containing audio
0x09	Video Data	packet containing video data
0x0A - 0xE	Unknown	anyone know?
0x0F	Flex Stream	Stream with variable length
0x10	Flex Shared Object	Shared object with variable length
0x11	Flex Message	Shared message with variable length
0x12	Notify	an invoke which does not expect a reply
0x13	Shared Object	has subtypes
0x14	Invoke	like remoting call, used for stream actions too.
0x16	[FMS3] Set of one or more FLV tags, as documented on the flv page. Each tag will have an 11 byte header - [1 byte Type][3 bytes Size][3 bytes Timestamp][1 byte timestamp extention][3 bytes streamID], followed by the body, followed by a 4 byte footer containing the size of the body.	FLV data

 

4、RTMP Packet Structure

　　RTMP Packet consist of a fixed-length header and a variable length body that has a default of 128 bytes. The header can come in one of four sizes: 12, 8, 4, or 1 byte(s).

　　The two most significant bits of the first byte of the packet( which also counts as the first byte the header ) determine the length of the header. They can be extracted by ANDing the byte with the mask 0xC0. The possible header lengths are specified in the table below:

Bits	Header Length
00	12 bytes
01	8 bytes
10	4 bytes
11	1 byte

In a full 12 byte header is broken down as follows : 

　　1、The first byte has the header size and the object id. The first two bits are the size of the header and the following 6 bits are the object id(note: when in video/audio rtmp, this 6 bits seem to include the stream id). This limits a RTMPpackets to a maximum of 64 objects in one packet. This byte is always sent no matter the size of the header.

　　2、The next three bytes are the time stamp. This is a big-endian integer and it is sent whenever the header size is 4 bytes or larger.(note: when the time stamp is 0xffffff, than you must use 4 bytes after the header which will be the actual time stamp, making the data body length 4 bytes longer).

　　3、The next three bytes are the length of the object body. This is an integer and is big-endian. The length of the object is the size of the AMF in the RTMP packet without the RTMP headers, so you need to remove any RTMP headers before this number matches properly. These bytes are sent whenever the header size is 8 or more.

　　4、The next single byte is the content type. the content types are only included when the header is 8 bytes or longer.

　　5、The final 4 bytes of the header is a stream id. This is a 32 bit integer that is little-endian encoded. These bytes are only included when the header is a full 12 bytes. (As mentioned in Mick's Breakdown of RTMP linked below, it is possible that the stream id defines which NetStream/NetConnection object is the source or target of the message).

　　As mentioned above, in cases where the header is not a full 12 bytes any of the missing fields are assumed to be unchanged from the last header sent with this object ID.（综上所述，如果头文件不满足12个字节，就假定和最后一个头一样的结构.）For example, if a four-byte header is sent without a length field, and the last object that was sent for the current stream has treminated. (ie, there are zero bytes remaining in the last object's transmission), then it should be assumed that the length of the object that follows will be the same as the length of the object that was last transmitted. So if a packet is sent whose payload is 32 bytes, and then immediately afterwards another packet is transmitted with the same object ID, but without a length field, it is assumed that the length of this next packet is also 32 bytes.

5、Streaming

　　For basic publish cycle this is what happens :

　　Client --> Server : sends a CreateStream request(is it a single RTMP packet ?)

　　the createstream request is a single AFM0 function call (remote method invocation) whose high-level equivalent function signature would be “createstream(double ClientStream, NULL)” The ClientStream variable starts at 1 and is incremented by one for every stream that is created in a connection. It is NOT used by the server to route data for multimedia streams.