“RTMP study notes”的版本间的差异
free6d1823（讨论 | 贡献） |
free6d1823（讨论 | 贡献） |
||
| 第80行： | 第80行： | ||
|- | |- | ||
|| 6 ||Set Peer Bandwidth || Acknowledgement Window size+Limit Type ||32+8 || sends this message to limit the output | || 6 ||Set Peer Bandwidth || Acknowledgement Window size+Limit Type ||32+8 || sends this message to limit the output | ||
| + | |- | ||
| + | || 4 ||User Control Message || Event Type+Event Data ||16+variable || contain information used by the RTMP streaming layer | ||
|} | |} | ||
| + | |||
| + | Message Type: | ||
| + | {| class="wikitable" style="width:25%" | ||
| + | ! ID !! Name !! Description | ||
| + | |- | ||
| + | ||17(AMF3),20(AMF0)|| Command Message || These messages are sent to perform some operations like | ||
| + | connect, createStream, publish, play, pause on the peer. Command | ||
| + | messages like onstatus, result etc. are used to inform the sender | ||
| + | about the status of the requested commands. | ||
| + | |- | ||
| + | || 18(AMF0),15(AMF3)|| Data Message || metadata or user data | ||
| + | |- | ||
| + | || 19(AMF0),16(AMF3)|| Share Object Message || Flash object: Shared object Name+Current version+Flags+Event Type+Event data length+Event data | ||
| + | |- | ||
| + | || 8|| Audio Message || audio data | ||
| + | |- | ||
| + | || 9|| Video Message || video data | ||
| + | |- | ||
| + | || 22|| Aggregate Message || contains a series of RTMP sub-message | ||
| + | |||
| + | |||
| + | |} | ||
| + | |||
| + | |||
*Limit type | *Limit type | ||
0 - Hard: The peer SHOULD limit its output bandwidth to the indicated window size. | 0 - Hard: The peer SHOULD limit its output bandwidth to the indicated window size. | ||
1 - Soft: The peer SHOULD limit its output bandwidth to the the window indicated in this message or the limit already in effect, whichever is smaller. | 1 - Soft: The peer SHOULD limit its output bandwidth to the the window indicated in this message or the limit already in effect, whichever is smaller. | ||
2 - Dynamic: If the previous Limit Type was Hard, treat this message as though it was marked Hard, otherwise ignore this message. | 2 - Dynamic: If the previous Limit Type was Hard, treat this message as though it was marked Hard, otherwise ignore this message. | ||
| + | |||
| + | *RTMP Message Format | ||
| + | Message Header: big-endian format | ||
| + | Message Type[1] | ||
| + | Payload length[3] | ||
| + | Timestamp[4] | ||
| + | Stream ID [3] | ||
| + | |||
| + | Message payload: actual data | ||
2020年4月5日 (日) 18:48的版本
Ref: https://www.adobe.com/devnet/rtmp.html
Handshaking Sequence
uninitialized ----
C0 -->
C1 -->
<-- S0 必须在 C0或C1 之后
<-- S1 必须在 C0或C1 之后
version sent -----
C2 -->
C2 必须在 S1之后
Ack sent -----
<-- s2 必须在C1之后
Handshake Done ----
data -->
data必须在S2之后
<-- data 必须在c2 之后
C0-> RTMP version 8 bits (=3)
<- S0 RTMP version 8 bit (=3)
C1,S1 1536 bytes
time[4]: stream 的参考基准时间 zero[4]:0 random bytes[1528] 乱数token
C2,S2 1536 bytes
time[4]: C2: S1 的时间; S2: C1 的时间 time2[4]: 读取S1/C1的时间 random bytes[1528]: C1/S1的乱数token
Chunk:
| Basic Header | Message Header | Extended Timestamp | Chunk Data |
+--------------+----------------+--------------------+--------------+
Basic Header: 1~3 bytes, Chunk Stream ID + chunk type
Message Header:0,3,7, or 11 bytes,message的type
Extended Timestamp: 0 or 4 bytes
Chunk header = Basic Header + Message Header + Extended Timestamp
Chunk data: variable size.
Chunk Stream ID: 3~65599,
0n = 64+n (64~319) 1mn = 64+m + n*256 (64~65599) n (n !=0,1,2 one byte) (3~63) 2 is reserved for level control
chunk type 高2位:format of Message header
Type 0: 11 byte 用于stream 开头 timestamp[3]: 发送时间, 0xffffff 使用Extended Timestamp [32bits] message length[3] message type id[1] message stream id[4] Type 1: 7 bytes timestamp delta[3] message length[3] message type id[1] Type 2: 3 bytes ID 与长度跟前个chunk 同 timestamp delta[3] Type 3: no message header. timestamp , ID 与长度跟前个chunk 同
message type id
1,2,3,5,6 for protocol control message 8: audio 9: video
Protocol Control Messages
message stream ID 0: control stream
chunk stream ID 2: used in control stream
message type id
| ID | Name | Fields | size | Meaning |
|---|---|---|---|---|
| 1 | Set Chunk Size | maximum chunk size | 32 bits | Set maximum chunk size (1~0x7FFFFFFF) |
| 2 | Abort Message | chunk stream ID | 32 bits | chunk stream ID message to be discard |
| 3 | Acknowledgement | sequnce number | 32 bits | This field holds the number of bytes
received so far. |
| 5 | Window Acknowledgement Size | window size | 32 bits | inform the peer of the
window size to use between sending acknowledgments |
| 6 | Set Peer Bandwidth | Acknowledgement Window size+Limit Type | 32+8 | sends this message to limit the output |
| 4 | User Control Message | Event Type+Event Data | 16+variable | contain information used by the RTMP streaming layer |
Message Type:
| ID | Name | Description |
|---|---|---|
| 17(AMF3),20(AMF0) | Command Message | These messages are sent to perform some operations like
connect, createStream, publish, play, pause on the peer. Command
|
| 18(AMF0),15(AMF3) | Data Message | metadata or user data |
| 19(AMF0),16(AMF3) | Share Object Message | Flash object: Shared object Name+Current version+Flags+Event Type+Event data length+Event data |
| 8 | Audio Message | audio data |
| 9 | Video Message | video data |
| 22 | Aggregate Message | contains a series of RTMP sub-message
|
- Limit type
0 - Hard: The peer SHOULD limit its output bandwidth to the indicated window size.
1 - Soft: The peer SHOULD limit its output bandwidth to the the window indicated in this message or the limit already in effect, whichever is smaller.
2 - Dynamic: If the previous Limit Type was Hard, treat this message as though it was marked Hard, otherwise ignore this message.
- RTMP Message Format
Message Header: big-endian format
Message Type[1] Payload length[3] Timestamp[4] Stream ID [3]
Message payload: actual data
