RTMP协议分为3部分，第一部分关于RTMPCS（RTMP Chunk Stream协议），第二部分叙述RTMPMF（RTMP message formats），第三部分描述RTMPCM（RTMP command messages）；
(一）RTMPCS(RTMP Chunk Stream）
简介：
这个手册描述Real Time Messaging Protocol Chunk Stream，这个应用级协议为了在一个合适的传输协议（例如tcp）上复用和打包多媒体传输流（如音频，视频和交互内容）。【注意：这里描述的是RTMPCS，是RTMP的底层协议，很多文章把RTMPCS和RTMP混为一谈】
目录：
1.介绍
The document specifies the Real Time Messaging Protocol Chunk Stream(RTMP Chunk Stream). It provides multiplexing and packetizing services for a higher-level multimedia stream protocol.
这个文档说明Real Time Messaging Protocol Chunk Stream。RTMPCS为更高层次的多媒体协议提供了复用和打包的服务。
While RTMP Chunk Stream was designed to work with the Real Time Messaging Protocol [RTMP], it can handle any protocol that sends a stream of messages.
虽然RTMPCS是为Real Time Messaging Protocol而设计，但是它可以处理任何通过消息来传输流的协议。
Each message contains timestamp and payload type identification. RTMP Chunk Stream and RTMP together are suitable for a wide variety of audio-video applications, from one-to-one and oneto-many live broadcasting to video-on-demand services to interactive conferencing applications.
每个消息包含时间戳和负载类型标识。RTMPCS和RTMP组合在一起适合于多种音视频应用，包括：在交互式会议中的1对1,1对多，按需视频服务。
When used with a reliable transport protocol such as [TCP], RTMP Chunk Stream provides guaranteed timestamp-ordered end-to-end delivery of all messages, across multiple streams.
当RTMPCS底层使用可靠传输协议（例如TCP）时，它可以提供按时排序、端到端的媒体消息传输。
RTMP Chunk Stream does not provide any prioritization or similar forms of control, but can be used by higher-level protocols to provide such prioritization.
RTMPCS不提供优先级或者类似的控制，优先级控制可以由更高层次的协议来提供。
For example, a live video server might choose to drop video messages for a slow client to ensure that audio messages are received in a timely fashion, based on either the time to send or the time to acknowledge each message.
例如：如果有一个慢的客户端，一个视频直播服务器可以选择丢弃其视频消息，以保证音频消息按时收到，【后面这段不明白什么意思】。
RTMP Chunk Stream includes its own in-band protocol control messages, and also offers a mechanism for the higher-level protocol to embed user control messages.
RTMPCS有自己的“进带协议控制消息”（SetChunkSize...），并且提供给更高层次的协议嵌入“用户控制消息”。
2.定义
Payload:
The data contained in a packet, for example audio samples or
compressed video data. The payload format and interpretation are
beyond the scope of this document.
负载：
一个包中包含的音频或者压缩视频数据。负载格式及说明不在本文档范围内。
Packet:
A data packet consists of fixed header and payload data. Some
underlying protocols may require an encapsulation of the packet to
be defined.
包：
一个数据包包含固定的头部及负载数据。一些底层的协议可能要去对一个包进行封装。
Port:
The "abstraction that transport protocols use to distinguish among
multiple destinations within a given host computer. TCP/IP
protocols identify ports using small positive integers." The
transport selectors (TSEL) used by the OSI transport layer are
equivalent to ports.
端口：
Transport address:
The combination of a network address and port that identifies a
transport-level endpoint, for example an IP address and a TCP port.
Packets are transmitted from a source transport address to a
destination transport address.
传输地址：网络地址及端口的组合，定义了一个传输层端点，例如一个ip地址和tcp端口。
Message stream:
A logical channel of communication that allows the flow of
messages.
消息流：
一个逻辑的通信通道，可以传输消息流。
Message stream ID:
Each message has an ID associated with it to identify the message
stream in which it is flowing.
消息流ID：
每个消息有一个ID来关联到对应的消息流。
Chunk:
A fragment of a message. The messages are broken into smaller parts
and interleaved before they are sent over the network. The chunks
ensure timestamp-ordered end-to-end delivery of all messages,
across multiple streams.
分块：
一个消息片段，消息分割成多个小部分后发送到网络上，分块保证按时顺序的端到端消息传递。
Chunk stream:
A logical channel of communication that allows flow of chunks in a
particular direction. The chunk stream can travel from the client
to the server and reverse.
块流：
Chunk stream ID:
Every chunk has an ID associated with it to identify the chunk
stream in which it is flowing.
块流ID：
每个块有一个ID关联到对应的流。
3.字节序，对其，时间格式
All integer fields are carried in network byte order, byte zero is
the first byte shown, and bit zero is the most significant bit in a
word or field. This byte order is commonly known as big-endian.
The transmission order is described in detail in [STD5]. Unless
otherwise noted, numeric constants in this document are in decimal
(base 10).
所有的数字域采用网络字节序（也就是大端格式）。
Except as otherwise specified, all data in RTMP Chunk Stream is bytealigned;
for example, a 16-bit field may be at an odd byte offset.
Where padding is indicated, padding bytes SHOULD have the value zero.
除非另外指定，否则所有的RTMPCS是字节对齐的，例如：一个16-bit的域可以在一个奇数的字节偏移位置上【按字节对齐】，如果有padding，那么padding的值是0。
Timestamps in RTMP Chunk Stream are given as an integer number of
milliseconds, relative to an unspecified epoch. Typically, each Chunk
Stream will start with a timestamp of 0, but this is not required, as
long as the two endpoints agree on the epoch. Note that this means
that any synchronization across multiple chunk streams (especially
from separate hosts) requires some additional mechanism outside of
RTMP Chunk Stream.
时间戳在RTMPCS中是以毫秒为单位，这个时间戳相对于一个未知的开始时间。一般上，每个块流从的时间戳从0开始，但是这不是必须的，只要两个端点协商好开始时间即可。注意，这意味着多个chunk-stream是的同步需要额外的机制来保证，这种机制不在RTMPCS的讨论范围。
Timestamps MUST be monotonically increasing, and SHOULD be linear in
time, to allow applications to handle synchronization, bandwidth
measurement, jitter detection, and flow control.
时间戳必须要单调递增的，并且SHOULD线性【这不一定能达到，视频数据时间戳没那么线性】。上面这两个要求，使得应用可以进行同步，带宽测量，抖动检测和流控的处理。
Because timestamps are generally only 32 bits long, they will roll
over after fewer than 50 days. Because streams are allowed to run
continuously, potentially for years on end, an RTMP Chunk Stream
application MUST use modular arithmetic for subtractions and
comparisons, and SHOULD be capable of handling this wraparound
heuristically. Any reasonable method is acceptable, as long as both
endpoints agree. An application could assume, for example, that all
adjacent timestamps are within 2^31 milliseconds of each other, so
10000 comes after 4000000000, while 3000000000 comes before
因为时间戳一般上只有32位长度，大概50天时间戳就需要回滚到0。因为流是可以持续运行的，一个RTMPCS的应用层必须要处理这种情况。只要通信双方协商一致，任何方法都可以被采纳【也就是RTMPCS不管这些，外面自己处理这个时间戳回环的问题】。例如一个应用需要假设任何相邻的时间戳：所以10000在400000000之后，而300000000在400000000之前【只是简单描述回环的概念，没什么】。
Timestamp deltas are also specified as an unsigned integer number of
milliseconds, relative to the previous timestamp. Timestamp deltas
may be either 24 or 32 bits long.
时间增量也是一个以毫秒为单位的无符号整形数，它是相对于前一个时间戳的增量。时间增量可以是24或者32位长度。
4.消息格式
The format of a message that can be split into chunks to support
multiplexing, depends on higher level protocol. The message format
SHOULD however contain the following fields which are necessary for
creating the chunks.
一个消息是否可以被分割为chunks，取决于更高层的协议。高层协议的消息格式需要包含如下一些必要的信息，才能分割并创建为chunks：
a.Timestamp:
Timestamp of the message. This field can transport 4 bytes.
时间戳信息：
消息的时间，这个域可以传输4个字节。
b.Length:
Length of the message payload. If the message header cannot be
elided, it should be included in the length. This field occupies 3
bytes in the chunk header.
长度信息：
消息负载的长度，如果一个消息头不能被删除，那么它也需要算在负载里面，并且长度要算上消息头。
这个字段在chunk header中占据3个字节。
c.Type Id:
A range of type IDs are reserved for protocol control messages.
These messages which propagate information are handled by both RTMP
Chunk Stream protocol and the higher-level protocol. All other type
IDs are available for use by the higher-level protocol, and treated
as opaque values by RTMP Chunk Stream. In fact, nothing in RTMP
Chunk Stream requires these values to be used as a type; all (nonprotocol)
messages could be of the same type, or the application
could use this field to distinguish simultaneous tracks rather than
types. This field occupies 1 byte in the chunk header.
类型id信息：
类型id的一部分被RTMPCS预留做协议控制消息使用了，所以这部分上层不能使用。
这些协议控制消息被RTMPCS及更高层次的协议处理。
所有其他的类型id则可以被更高层的协议使用，并且对RTMPCS来说透明的。实际上，RTMPCS完全不用这些与自己协议无关的类型id；应用可以对所有的消息使用相同的类型，或者使用不同的类型来区分不同的track，这个field占据一个字节。
d.Message Stream ID:
The message stream ID can be any arbitrary value. Different message
streams multiplexed onto the same chunk stream are demultiplexed
based on their message stream IDs. Beyond that, as far as RTMP
Chunk Stream is concerned, this is an opaque value. This field
occupies 4 bytes in the chunk header in little endian format.
消息流id信息：
消息流id可以是任何一个绝对值。不同的消息流通过不同的消息流id复用到一个chunk stream中。但是，对于RTMPCS来说，这个值是透明的，这个值在chunk header中占4个字节，是小端格式【也就是说，RTMPCS需要上层提供这个值，但是它不关心具体内容，由上层协议处理】
总结来说，能被RTMPCS处理的上层协议数据必须包含：线性递增的时间戳、负载长度信息、类型信息【一部分被RTMPCS预留了不能用】、消息流ID信息【用于上层在chunk stream中复用多个流】
5.握手协议
【这个比较简单，就是C0C1C2和S0S1S2的交互】
6.Chunking【分片】
After handshaking, the connection multiplexes one or more chunk
streams. Each chunk stream carries messages of one type from one
message stream. Each chunk that is created has a unique ID associated
with it called chunk stream ID. The chunks are transmitted over the
network. While transmitting, each chunk must be sent in full before
the next chunk. At the receiver end, the chunks are assembled into
messages based on the chunk stream ID.
在握手完成后，这个连接复用一个或者多个chunk stream【通过chunk stream id 区分】。
每个chunk stream传递一个消息流的一种消息类型【怎么理解这句话？】。每个chunk创建时都有一个唯一的ID，称为chunk stream id.之后，分片在通过网络传输，传输中，每个chunk必须等待前一个传输完成。在接收端，chunks通过chunk stream id字段将chunk汇聚到消息中，形成完整的消息。
Chunking allows large messages at the higher-level protocol to be
broken down into smaller messages,for example, to prevent large lowpriority
messages from blocking smaller high-priority messages.
分片使得大的消息可以被分割为小消息，这有些好处，例如：可以防止大的低优先级消息阻塞小的高优先级消息。
Chunking also allows small messages to be sent with less overhead, as
the chunk header contains a compressed representation of information
that would otherwise have to be included in the message itself.
分片使得小的消息减少系统开销，因为chunk header中包含的信息，本来就在消息本身也需要包含【大概就是说消息本身也要包含时间戳，类型id等信息，所以chunk不会增加冗余的数据的意思】
The chunk size is configurable. It can be set using a control
message(Set Chunk Size) as described in section 7.1. The maximum
chunk size can be 65536 bytes and minimum 128 bytes. Larger values
reduce CPU usage, but also commit to larger writes that can delay
other content on lower bandwidth connections. Smaller chunks are not
good for high-bit rate streaming. Chunk size is maintained
independently for each direction.
chunk的大小是可配置的。它可以使用控制消息（Set Chunk Size）来设置。最大的chunk size是65536字节，最小128字节。chunk size越大，CPU使用率越低，但是也会导其他内容写入延迟。小的chunks不利于高码率的数据流。chunk size在两端是独立的【也就是说，通信两端的chunk size可以是不同的】
【注：Set Chunk Size这个命令设置的是对端的Chunk Size，而不是自己这端的】
6.1 Chunk Format【chunk格式】
Each chunk consists of a header and data. The header itself is broken
down into three parts:
+-----------------+-------------------------+----------------------------+-----------------+
| Basic header|Chunk Msg Header|Extended Time Stamp| Chunk Data |
+-----------------+-------------------------+----------------------------+-----------------+
Figure 5 Chunk Format.
每个chunk包含一个头部和数据，头部分为3部分
Basic header、chunk msg header、extended timestamp。
Chunk basic header: 1 to 3 bytes
This field encodes the chunk stream ID and the chunk type. Chunk
type determines the format of the encoded message header. The
length depends entirely on the chunk stream ID, which is a
variable-length field.
chunk 基础头：1到3个字节
这个字段包含了chunk stream id和chunk type【也称为fmt】。chunk type决定后面的msg header的格式。基础头到底几个字节，是由整个chunk stream id决定的，基础头是一个可变长的域。
Chunk msg header: 0, 3, 7, or 11 bytes
This field encodes information about the message being sent
(whether in whole or in part). The length can be determined using
the chunk type specified in the chunk basic header.
chunk msg header:0,3,7或者11字节
这个字段包含了消息的信息【就是前面提到的4个信息：时间戳，类型，长度，消息id】。这个字段的长度通过chunk basic header中的chunk type来确定。
Extended timestamp: 0 or 4 bytes
This field MUST be sent when the normal timsestamp is set to
0xffffff, it MUST NOT be sent if the normal timestamp is set to
anything else. So for values less than 0xffffff the normal
timestamp field SHOULD be used in which case the extended timestamp MUST NOT be present. For values greater than or equal to 0xffffff
the normal timestamp field MUST NOT be used and MUST be set to
0xffffff and the extended timestamp MUST be sent.
扩展时间戳：0到4字节
这个字段只有在普通时间戳值为0xffffff时被设置，否则为0字节。
6.1.1. Chunk Basic Header
The Chunk Basic Header encodes the chunk stream ID and the chunk
type(represented by fmt field in the figure below). Chunk type
determines the format of the encoded message header. Chunk Basic
Header field may be 1, 2, or 3 bytes, depending on the chunk stream
ID.
chunk basic header包含chunk stream ID【这个id是chunk stream 层的，高层协议不知道这个的】，chunk type决定了后面的msg header的格式，chunk basic header可以是1,2,3字节长度，通过chunk stream id来确定，后面chunk stream id使用csid来指代。
An implementation SHOULD use the smallest representation that can
hold the ID.
具体实现，需要尽量使用小的csid值【就是说这个值可以到65535，但是我们最好用3、4这种小值就够用了，一般上也很少那么多个消息流复用到一个chunk stream上】
The protocol supports up to 65597 streams with IDs 3–65599. The IDs
0, 1, and 2 are reserved. Value 0 indicates the ID in the range of
64–319 (the second byte + 64). Value 1 indicates the ID in the range
of 64–65599 ((the third byte)256 + the second byte + 64). Value 2
indicates its low-level protocol message. There are no additional
bytes for stream IDs. Values in the range of 3–63 represent the
complete stream ID. There are no additional bytes used to represent
it.
协议支持65597个流，csid从3-65599。而0,1,2的csid是被预留的。
0表示csid的范围是64-319【这时basic header占2个字节，csid=后面一个字节+64】。
1表示csid的范围是65-65599【这时值为第三字节256+第二字节+64】。
2表示csid是特殊用途的，用过协议控制消息使用的【这里称为底层协议消息】，【这时msg header中的stream id为0？因为这个本身是RTMPCS自己用的，那按道理就没有上层提供的任何信息】。
第一种格式：
Chunk stream IDs 2-63 can be encoded in the 1-byte version of this
field.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|fmt| cs id |
+-+-+-+-+-+-+-+-+
Figure 6 Chunk basic header 1
1字节：当csid从2-63都使用这种格式。
第二种格式：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|fmt| 0 | cs id - 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 Chunk basic header 2
当csid从64-319时，使用这种格式。
第三种格式：
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|fmt| 1 | cs id - 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 Chunk basic header 3
csid从64-65599使用这种格式【第二种格式和第三种格式有重叠部分，那就尽量用第二种格式的意思吧】【还有第三种格式应该很少用，因为csid一般不会这么大吧】
cs id: 6 bits
This field contains the chunk stream ID, for values from 2-63.
Values 0 and 1 are used to indicate the 2- or 3-byte versions of
this field.
fmt: 2 bits
This field identifies one of four format used by the ‘chunk message
header’.The ‘chunk message header’ for each of the chunk types is
explained in the next section.
cs id - 64: 8 or 16 bits
This field contains the chunk stream ID minus 64. For example, ID
365 would be represented by a 1 in cs id, and a 16-bit 301 here.
Chunk stream IDs with values 64-319 could be represented by both 2-
byte version and 3-byte version of this field.
6.1.2. Chunk Message Header
There are four different formats for the chunk message header,
selected by the "fmt" field in the chunk basic header.
An implementation SHOULD use the most compact representation possible
for each chunk message header.
有4种chunk msg header格式。通过chunk basic header的fmt字段选择。
6.1.2.1. Type 0
Chunks of Type 0 are 11 bytes long. This type MUST be used at the
start of a chunk stream, and whenever the stream timestamp goes
backward (e.g., because of a backward seek).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |message length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message length (cont) |message type id| msg stream id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message stream id (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 Chunk Message Header – Type 0
timestamp: 3 bytes
For a type-0 chunk, the absolute timestamp of the message is sent
here. If the timestamp is greater than or equal to 16777215
(hexadecimal 0x00ffffff), this value MUST be 16777215, and the
‘extended timestamp header’ MUST be present. Otherwise, this value
SHOULD be the entire timestamp.
11字节长度，一个chunk stream的开始必须使用这种类型，不管时间戳是否因为向后seek而...
timestamp：3字节；
6.1.2.2. Type 1
Chunks of Type 1 are 7 bytes long. The message stream ID is not
included; this chunk takes the same stream ID as the preceding chunk.
Streams with variable-sized messages (for example, many video
formats) SHOULD use this format for the first chunk of each new
message after the first.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp delta |message length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| message length (cont) |message type id|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10 Chunk Message Header – Type 1
type1占7字节长度。message stream ID没有包含；这个chunk的stream ID和前面的chunk一样。
【但是时间戳有一个差值】【这里例举的视频应用例子没看太明白什么意思】。
6.1.2.3. Type 2
Chunks of Type 2 are 3 bytes long. Neither the stream ID nor the
message length is included; this chunk has the same stream ID and
message length as the preceding chunk. Streams with constant-sized
messages (for example, some audio and data formats) SHOULD use this
format for the first chunk of each message after the first.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp delta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11 Chunk Message Header – Type 2
type2 占3字节，stream Id和message length都没有，只有timestamp delta，stream id和message length和前面的一样。固定长度的消息（比如音频和数据格式）使用这个格式。
6.1.2.4. Type 3
Chunks of Type 3 have no header. Stream ID, message length and
timestamp delta are not present; chunks of this type take values from
the preceding chunk. When a single message is split into chunks, all
chunks of a message except the first one, SHOULD use this type. Refer
to example 2 in section 6.2.2. Stream consisting of messages of
exactly the same size, stream ID and spacing in time SHOULD use this
type for all chunks after chunk of Type 2. Refer to example 1 in
section 6.2.1. If the delta between the first message and the second
message is same as the time stamp of first message, then chunk of
type 3 would immediately follow the chunk of type 0 as there is no
need for a chunk of type 2 to register the delta. If Type 3 chunk
follows a Type 0 chunk, then timestamp delta for this Type 3 chunk is
the same as the timestamp of Type 0 chunk.
type3没有任何头，stream id，message length和时间戳delta信息。这些值都喝前面的chunk一致。
a.当1个消息split为多个chunks时，除了第一个chunk是type0外，其他的使用type 3。
b.如果stream连续的消息size，stream id，间隔时间一样，那么格式是type 0， type 2， type 3， type 3 ...。
c.如果第一个消息和第二个消息的delta和第一个消息的timestamp一样【这好像只有音频中可能吧】，那么格式就是 type0, type3,type3...，不需要像b中一样多一个type2注册delta时间。如果type 3 chunk跟随着type 0 chunk，那么type3 chunk的timestamp delta和type0的timestamp相同【当然应该限制在多个消息的情况，而不是一个消息拆分为多个chunk时】
Description of each field in the chunk message header.
chunk msg header各个字段的描述：
timestamp delta: 3 bytes
For a type-1 or type-2 chunk, the difference between the previous
chunk's timestamp and the current chunk's timestamp is sent here.
If the delta is greater than or equal to 16777215 (hexadecimal
0x00ffffff), this value MUST be 16777215, and the ‘extended
timestamp header’ MUST be present. Otherwise, this value SHOULD be
the entire delta.
timestamp delta：3字节
type1和type2 chunk中描述和前一个chunk的timestamp delta
message length: 3 bytes
For a type-0 or type-1 chunk, the length of the message is sent
here.
Note that this is generally not the same as the length of the chunk
payload. The chunk payload length is the maximum chunk size for all
but the last chunk, and the remainder (which may be the entire
length, for small messages) for the last chunk.
message length：3字节
type0和type1中使用。
message type id: 1 byte
For a type-0 or type-1 chunk, type of the message is sent here.
message stream id: 4 bytes
For a type-0 chunk, the message stream ID is stored. Message stream
ID is stored in little-endian format. Typically, all messages in
the same chunk stream will come from the same message stream. While
it is possible to multiplex separate message streams into the same
chunk stream, this defeats all of the header compression. However,
if one message stream is closed and another one subsequently
opened, there is no reason an existing chunk stream cannot be
reused by sending a new type-0 chunk.
type0的chunk中存在，小端格式。一般上，所有的chunk stream都从一个相同的message stream中得到的。但是也可能多个message streams复用到一个chunk stream中。【后面有点不明白什么意思】
6.1.3. Extended Timestamp
This field is transmitted only when the normal time stamp in the
chunk message header is set to 0x00ffffff. If normal time stamp is
set to any value less than 0x00ffffff, this field MUST NOT be
present. This field MUST NOT be present if the timestamp field is not
present. Type 3 chunks MUST NOT have this field.
This field if transmitted is located immediately after the chunk
message header and before the chunk data.
+-------------+----------------+-------------------+--------------+
| Basic header|Chunk Msg Header|Extended Time Stamp| Chunk Data |
+-------------+----------------+-------------------+--------------+
Figure 12 Chunk Format.
扩展时间戳【不太需要解释很多吧】
6.2. Examples
Example 1 shows a simple stream of audio messages. This example
demonstrates the redundancy of information.
这个例子展示了一个音频消息流，它减少了信息冗余：
The next table shows chunks produced in this stream. From message 3
onward, data transmission is optimized. There is only 1 byte of
overhead per message beyond this point.
下面的表展示了由这个流产生的chunks，从message 3开始，数据传输被优化了，只有1字节的冗余
【这里还需要type2，注册timestamp delta】
6.2.2. Example 2
Example 2 illustrates a message that is too long to fit in a 128-
chunk and is broken into several chunks.
例子2描述一个消息大于128长度，被拆分为多个chunks的情形
The header data of chunk 1 specifies that the overall message is 307
bytes.
Notice from the two examples, that chunk type 3 can be used in two
different ways. The first is to specify the continuation of a
message. The second is to specify the beginning of a new message
whose header can be derived from the existing state data.
第一个type0 的chunk 中length指明消息长度是307，注意在这个例子中，chunk type 3可以用在两种用途中，第一中是用在这个chunk的message header和前面的chunk一样的情况下，另外一种用在一个消息拆分为多个消息时。
- Protocol Control Messages：协议控制消息
RTMP Chunk Stream supports some protocol control messages. These
messages contain information required by RTMP Chunk Stream protocol
and will not be propagated to the higher protocol layers. Currently
there are two protocol messages used in RTMP Chunk Stream. One
protocol message is used for setting the chunk size and the other is
used to abort a message due to non-availability of remaining chunks
Protocol control messages SHOULD have message stream ID 0(called as
control stream) and chunk stream ID 2, and are sent with highest
priority.
RTMPCS支持一些协议控制消息，这些消息只在RTMPCS协议中使用，不需要传递给上层协议。当前有两个协议消息在RTMPCS中使用；一个是设置chunk size，另一个是丢弃消息【以后再看这个丢弃的意思是什么】。协议控制消息必须使用stream ID是0（也被称为控制流），并且CSID为2，并且使用最高优先级发送。
Each protocol control message type has a fixed-size payload, and is
always sent in a single chunk.
每个协议控制消息有固定长度的payload，并且只在一个chunk中发送。
7.1. Set Chunk Size
Protocol control message 1, Set Chunk Size, is used to notify the
peer about the new maximum chunk size.
A default value can be set for the chunk size, but the client or the
server can change this value and update it to the peer. For example,
suppose a client wants to send 131 bytes of audio data and the chunk
size is 128. In this case, the client can send this protocol message
to the server to notify that the chunk size is set to 131 bytes. The
client can then send the audio data in a single chunk.
The maximum chunk size can be 65536 bytes. The chunk size is
maintained independently for each direction.
set chunk size是用来通知对方新的chunk size。
默认是128.