查看RTMP study notes的源代码 RTMP study notes 0

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

<u>Protocol Control Messages</u>
message stream ID 0: control stream
chunk stream ID 2: used in control stream
message type id
{| class="wikitable" style="width:100%"
! 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:
{| 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
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