RTMP協(xié)議分為3部分，第一部分關(guān)于RTMPCS（RTMP Chunk Stream協(xié)議），第二部分?jǐn)⑹鯮TMPMF（RTMP message formats），第三部分描述RTMPCM（RTMP command messages）盼樟；
(一）RTMPCS(RTMP Chunk Stream）
簡(jiǎn)介：
這個(gè)手冊(cè)描述Real Time Messaging Protocol Chunk Stream迷郑，這個(gè)應(yīng)用級(jí)協(xié)議為了在一個(gè)合適的傳輸協(xié)議（例如tcp）上復(fù)用和打包多媒體傳輸流（如音頻指煎，視頻和交互內(nèi)容）训唱」艉纾【注意：這里描述的是RTMPCS，是RTMP的底層協(xié)議拔创，很多文章把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.
這個(gè)文檔說(shuō)明Real Time Messaging Protocol Chunk Stream利诺。RTMPCS為更高層次的多媒體協(xié)議提供了復(fù)用和打包的服務(wù)。
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而設(shè)計(jì)剩燥，但是它可以處理任何通過(guò)消息來(lái)傳輸流的協(xié)議慢逾。
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.
每個(gè)消息包含時(shí)間戳和負(fù)載類(lèi)型標(biāo)識(shí)。RTMPCS和RTMP組合在一起適合于多種音視頻應(yīng)用灭红，包括：在交互式會(huì)議中的1對(duì)1,1對(duì)多侣滩，按需視頻服務(wù)。
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.
當(dāng)RTMPCS底層使用可靠傳輸協(xié)議（例如TCP）時(shí)变擒，它可以提供按時(shí)排序胜卤、端到端的媒體消息傳輸。
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不提供優(yōu)先級(jí)或者類(lèi)似的控制赁项，優(yōu)先級(jí)控制可以由更高層次的協(xié)議來(lái)提供葛躏。
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.
例如：如果有一個(gè)慢的客戶(hù)端，一個(gè)視頻直播服務(wù)器可以選擇丟棄其視頻消息悠菜，以保證音頻消息按時(shí)收到舰攒，【后面這段不明白什么意思】。
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有自己的“進(jìn)帶協(xié)議控制消息”（SetChunkSize...）悔醋，并且提供給更高層次的協(xié)議嵌入“用戶(hù)控制消息”摩窃。
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.
負(fù)載：
一個(gè)包中包含的音頻或者壓縮視頻數(shù)據(jù)。負(fù)載格式及說(shuō)明不在本文檔范圍內(nèi)芬骄。
Packet:
A data packet consists of fixed header and payload data. Some
underlying protocols may require an encapsulation of the packet to
be defined.
包：
一個(gè)數(shù)據(jù)包包含固定的頭部及負(fù)載數(shù)據(jù)猾愿。一些底層的協(xié)議可能要去對(duì)一個(gè)包進(jìn)行封裝。
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.
傳輸?shù)刂罚壕W(wǎng)絡(luò)地址及端口的組合账阻，定義了一個(gè)傳輸層端點(diǎn)蒂秘，例如一個(gè)ip地址和tcp端口。
Message stream:
A logical channel of communication that allows the flow of
messages.
消息流：
一個(gè)邏輯的通信通道淘太，可以傳輸消息流姻僧。
Message stream ID:
Each message has an ID associated with it to identify the message
stream in which it is flowing.
消息流ID：
每個(gè)消息有一個(gè)ID來(lái)關(guān)聯(lián)到對(duì)應(yīng)的消息流。
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.
分塊：
一個(gè)消息片段蒲牧，消息分割成多個(gè)小部分后發(fā)送到網(wǎng)絡(luò)上撇贺，分塊保證按時(shí)順序的端到端消息傳遞。
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：
每個(gè)塊有一個(gè)ID關(guān)聯(lián)到對(duì)應(yīng)的流冰抢。
3.字節(jié)序松嘶，對(duì)其，時(shí)間格式
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).
所有的數(shù)字域采用網(wǎng)絡(luò)字節(jié)序（也就是大端格式）挎扰。
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是字節(jié)對(duì)齊的缓升，例如：一個(gè)16-bit的域可以在一個(gè)奇數(shù)的字節(jié)偏移位置上【按字節(jié)對(duì)齊】，如果有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.
時(shí)間戳在RTMPCS中是以毫秒為單位，這個(gè)時(shí)間戳相對(duì)于一個(gè)未知的開(kāi)始時(shí)間橙弱。一般上歧寺，每個(gè)塊流從的時(shí)間戳從0開(kāi)始，但是這不是必須的棘脐，只要兩個(gè)端點(diǎn)協(xié)商好開(kāi)始時(shí)間即可斜筐。注意，這意味著多個(gè)chunk-stream是的同步需要額外的機(jī)制來(lái)保證蛀缝，這種機(jī)制不在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.
時(shí)間戳必須要單調(diào)遞增的，并且SHOULD線(xiàn)性【這不一定能達(dá)到屈梁，視頻數(shù)據(jù)時(shí)間戳沒(méi)那么線(xiàn)性】嗤练。上面這兩個(gè)要求，使得應(yīng)用可以進(jìn)行同步在讶，帶寬測(cè)量煞抬，抖動(dòng)檢測(cè)和流控的處理。
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
因?yàn)闀r(shí)間戳一般上只有32位長(zhǎng)度构哺，大概50天時(shí)間戳就需要回滾到0革答。因?yàn)榱魇强梢猿掷m(xù)運(yùn)行的，一個(gè)RTMPCS的應(yīng)用層必須要處理這種情況曙强。只要通信雙方協(xié)商一致残拐，任何方法都可以被采納【也就是RTMPCS不管這些，外面自己處理這個(gè)時(shí)間戳回環(huán)的問(wèn)題】碟嘴。例如一個(gè)應(yīng)用需要假設(shè)任何相鄰的時(shí)間戳：所以10000在400000000之后溪食，而300000000在400000000之前【只是簡(jiǎn)單描述回環(huán)的概念，沒(méi)什么】臀防。
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.
時(shí)間增量也是一個(gè)以毫秒為單位的無(wú)符號(hào)整形數(shù)眠菇，它是相對(duì)于前一個(gè)時(shí)間戳的增量边败。時(shí)間增量可以是24或者32位長(zhǎng)度袱衷。
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.
一個(gè)消息是否可以被分割為chunks，取決于更高層的協(xié)議笑窜。高層協(xié)議的消息格式需要包含如下一些必要的信息致燥，才能分割并創(chuàng)建為chunks：
a.Timestamp:
Timestamp of the message. This field can transport 4 bytes.
時(shí)間戳信息：
消息的時(shí)間，這個(gè)域可以傳輸4個(gè)字節(jié)排截。
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.
長(zhǎng)度信息：
消息負(fù)載的長(zhǎng)度嫌蚤，如果一個(gè)消息頭不能被刪除辐益，那么它也需要算在負(fù)載里面，并且長(zhǎng)度要算上消息頭脱吱。
這個(gè)字段在chunk header中占據(jù)3個(gè)字節(jié)智政。
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.
類(lèi)型id信息：
類(lèi)型id的一部分被RTMPCS預(yù)留做協(xié)議控制消息使用了，所以這部分上層不能使用箱蝠。
這些協(xié)議控制消息被RTMPCS及更高層次的協(xié)議處理续捂。
所有其他的類(lèi)型id則可以被更高層的協(xié)議使用，并且對(duì)RTMPCS來(lái)說(shuō)透明的宦搬。實(shí)際上牙瓢，RTMPCS完全不用這些與自己協(xié)議無(wú)關(guān)的類(lèi)型id；應(yīng)用可以對(duì)所有的消息使用相同的類(lèi)型间校，或者使用不同的類(lèi)型來(lái)區(qū)分不同的track矾克，這個(gè)field占據(jù)一個(gè)字節(jié)。
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可以是任何一個(gè)絕對(duì)值憔足。不同的消息流通過(guò)不同的消息流id復(fù)用到一個(gè)chunk stream中胁附。但是，對(duì)于RTMPCS來(lái)說(shuō)滓彰，這個(gè)值是透明的汉嗽，這個(gè)值在chunk header中占4個(gè)字節(jié)，是小端格式【也就是說(shuō)找蜜，RTMPCS需要上層提供這個(gè)值饼暑，但是它不關(guān)心具體內(nèi)容，由上層協(xié)議處理】
總結(jié)來(lái)說(shuō)洗做，能被RTMPCS處理的上層協(xié)議數(shù)據(jù)必須包含：線(xiàn)性遞增的時(shí)間戳弓叛、負(fù)載長(zhǎng)度信息、類(lèi)型信息【一部分被RTMPCS預(yù)留了不能用】诚纸、消息流ID信息【用于上層在chunk stream中復(fù)用多個(gè)流】
5.握手協(xié)議
【這個(gè)比較簡(jiǎn)單撰筷，就是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.
在握手完成后，這個(gè)連接復(fù)用一個(gè)或者多個(gè)chunk stream【通過(guò)chunk stream id 區(qū)分】畦徘。
每個(gè)chunk stream傳遞一個(gè)消息流的一種消息類(lèi)型【怎么理解這句話(huà)毕籽？】。每個(gè)chunk創(chuàng)建時(shí)都有一個(gè)唯一的ID井辆，稱(chēng)為chunk stream id.之后关筒，分片在通過(guò)網(wǎng)絡(luò)傳輸，傳輸中杯缺，每個(gè)chunk必須等待前一個(gè)傳輸完成蒸播。在接收端，chunks通過(guò)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.
分片使得大的消息可以被分割為小消息胀屿，這有些好處，例如：可以防止大的低優(yōu)先級(jí)消息阻塞小的高優(yōu)先級(jí)消息包雀。
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.
分片使得小的消息減少系統(tǒng)開(kāi)銷(xiāo)宿崭，因?yàn)閏hunk header中包含的信息，本來(lái)就在消息本身也需要包含【大概就是說(shuō)消息本身也要包含時(shí)間戳才写，類(lèi)型id等信息劳曹，所以chunk不會(huì)增加冗余的數(shù)據(jù)的意思】
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）來(lái)設(shè)置琅摩。最大的chunk size是65536字節(jié)铁孵，最小128字節(jié)。chunk size越大房资，CPU使用率越低蜕劝，但是也會(huì)導(dǎo)其他內(nèi)容寫(xiě)入延遲。小的chunks不利于高碼率的數(shù)據(jù)流轰异。chunk size在兩端是獨(dú)立的【也就是說(shuō)岖沛，通信兩端的chunk size可以是不同的】
【注：Set Chunk Size這個(gè)命令設(shè)置的是對(duì)端的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.
每個(gè)chunk包含一個(gè)頭部和數(shù)據(jù)搭独，頭部分為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 基礎(chǔ)頭：1到3個(gè)字節(jié)
這個(gè)字段包含了chunk stream id和chunk type【也稱(chēng)為fmt】唉俗。chunk type決定后面的msg header的格式∨渫郑基礎(chǔ)頭到底幾個(gè)字節(jié)虫溜，是由整個(gè)chunk stream id決定的，基礎(chǔ)頭是一個(gè)可變長(zhǎng)的域股缸。
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字節(jié)
這個(gè)字段包含了消息的信息【就是前面提到的4個(gè)信息：時(shí)間戳衡楞，類(lèi)型，長(zhǎng)度敦姻，消息id】瘾境。這個(gè)字段的長(zhǎng)度通過(guò)chunk basic header中的chunk type來(lái)確定。
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.
擴(kuò)展時(shí)間戳：0到4字節(jié)
這個(gè)字段只有在普通時(shí)間戳值為0xffffff時(shí)被設(shè)置镰惦，否則為0字節(jié)迷守。
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【這個(gè)id是chunk stream 層的，高層協(xié)議不知道這個(gè)的】陨献，chunk type決定了后面的msg header的格式盒犹，chunk basic header可以是1,2,3字節(jié)長(zhǎng)度，通過(guò)chunk stream id來(lái)確定眨业，后面chunk stream id使用csid來(lái)指代急膀。
An implementation SHOULD use the smallest representation that can
hold the ID.
具體實(shí)現(xiàn)，需要盡量使用小的csid值【就是說(shuō)這個(gè)值可以到65535龄捡，但是我們最好用3卓嫂、4這種小值就夠用了，一般上也很少那么多個(gè)消息流復(fù)用到一個(gè)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.
協(xié)議支持65597個(gè)流聘殖，csid從3-65599晨雳。而0,1,2的csid是被預(yù)留的。
0表示csid的范圍是64-319【這時(shí)basic header占2個(gè)字節(jié)奸腺，csid=后面一個(gè)字節(jié)+64】餐禁。
1表示csid的范圍是65-65599【這時(shí)值為第三字節(jié)256+第二字節(jié)+64】。
2表示csid是特殊用途的突照，用過(guò)協(xié)議控制消息使用的【這里稱(chēng)為底層協(xié)議消息】帮非，【這時(shí)msg header中的stream id為0？因?yàn)檫@個(gè)本身是RTMPCS自己用的讹蘑，那按道理就沒(méi)有上層提供的任何信息】末盔。
第一種格式：
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字節(jié)：當(dāng)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
當(dāng)csid從64-319時(shí)座慰，使用這種格式陨舱。
第三種格式：
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使用這種格式【第二種格式和第三種格式有重疊部分，那就盡量用第二種格式的意思吧】【還有第三種格式應(yīng)該很少用版仔，因?yàn)閏sid一般不會(huì)這么大吧】
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格式游盲。通過(guò)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字節(jié)長(zhǎng)度蛮粮，一個(gè)chunk stream的開(kāi)始必須使用這種類(lèi)型背桐，不管時(shí)間戳是否因?yàn)橄蚝髎eek而...
timestamp：3字節(jié)；
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字節(jié)長(zhǎng)度蝉揍。message stream ID沒(méi)有包含链峭；這個(gè)chunk的stream ID和前面的chunk一樣。
【但是時(shí)間戳有一個(gè)差值】【這里例舉的視頻應(yīng)用例子沒(méi)看太明白什么意思】又沾。
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字節(jié)弊仪，stream Id和message length都沒(méi)有，只有timestamp delta杖刷，stream id和message length和前面的一樣励饵。固定長(zhǎng)度的消息（比如音頻和數(shù)據(jù)格式）使用這個(gè)格式。
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沒(méi)有任何頭滑燃，stream id役听，message length和時(shí)間戳delta信息。這些值都喝前面的chunk一致。
a.當(dāng)1個(gè)消息split為多個(gè)chunks時(shí)典予，除了第一個(gè)chunk是type0外甜滨，其他的使用type 3。
b.如果stream連續(xù)的消息size瘤袖，stream id衣摩，間隔時(shí)間一樣，那么格式是type 0捂敌， type 2艾扮， type 3， type 3 ...占婉。
c.如果第一個(gè)消息和第二個(gè)消息的delta和第一個(gè)消息的timestamp一樣【這好像只有音頻中可能吧】泡嘴，那么格式就是 type0, type3,type3...，不需要像b中一樣多一個(gè)type2注冊(cè)delta時(shí)間逆济。如果type 3 chunk跟隨著type 0 chunk酌予，那么type3 chunk的timestamp delta和type0的timestamp相同【當(dāng)然應(yīng)該限制在多個(gè)消息的情況，而不是一個(gè)消息拆分為多個(gè)chunk時(shí)】
Description of each field in the chunk message header.
chunk msg header各個(gè)字段的描述：
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字節(jié)
type1和type2 chunk中描述和前一個(gè)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字節(jié)
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都從一個(gè)相同的message stream中得到的莱褒。但是也可能多個(gè)message streams復(fù)用到一個(gè)chunk stream中∠雅【后面有點(diǎn)不明白什么意思】
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.
擴(kuò)展時(shí)間戳【不太需要解釋很多吧】
6.2. Examples
Example 1 shows a simple stream of audio messages. This example
demonstrates the redundancy of information.
這個(gè)例子展示了一個(gè)音頻消息流广凸，它減少了信息冗余：
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.
下面的表展示了由這個(gè)流產(chǎn)生的chunks，從message 3開(kāi)始蛛枚，數(shù)據(jù)傳輸被優(yōu)化了谅海，只有1字節(jié)的冗余
【這里還需要type2，注冊(cè)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描述一個(gè)消息大于128長(zhǎng)度蹦浦，被拆分為多個(gè)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.
第一個(gè)type0 的chunk 中l(wèi)ength指明消息長(zhǎng)度是307扭吁，注意在這個(gè)例子中，chunk type 3可以用在兩種用途中盲镶，第一中是用在這個(gè)chunk的message header和前面的chunk一樣的情況下侥袜，另外一種用在一個(gè)消息拆分為多個(gè)消息時(shí)。
- Protocol Control Messages：協(xié)議控制消息
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支持一些協(xié)議控制消息溉贿，這些消息只在RTMPCS協(xié)議中使用枫吧，不需要傳遞給上層協(xié)議。當(dāng)前有兩個(gè)協(xié)議消息在RTMPCS中使用宇色；一個(gè)是設(shè)置chunk size九杂，另一個(gè)是丟棄消息【以后再看這個(gè)丟棄的意思是什么】颁湖。協(xié)議控制消息必須使用stream ID是0（也被稱(chēng)為控制流），并且CSID為2例隆，并且使用最高優(yōu)先級(jí)發(fā)送甥捺。
Each protocol control message type has a fixed-size payload, and is
always sent in a single chunk.
每個(gè)協(xié)議控制消息有固定長(zhǎng)度的payload，并且只在一個(gè)chunk中發(fā)送裳擎。
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是用來(lái)通知對(duì)方新的chunk size涎永。
默認(rèn)是128.
