RTMP Message Formats June 2009
Adobe Systems Inc. [Page 6]
with IDs 3-6 are reserved for usage of RTMP. Protocol message with ID
7 is used between edge server and origin server.
Protocol control messages MUST have message stream ID 0 (called as
control stream) and chunk stream ID 2, and are sent with highest
priority.
Each protocol control message type has a fixed-size payload.
5.1. Set Chunk Size (1)
Protocol control message 1, Set Chunk Size, is used to notify the
peer a new maximum chunk size to use.
The value of the chunk size is carried as 4-byte message payload. A
default value exists for chunk size, but if the sender wants to
change this value it notifies the peer about it through this
protocol message. For example, a client wants to send 131 bytes of
data and the chunk size is at its default value of 128. So every
message from the client gets split into two chunks. The client can
choose to change the chunk size to 131 so that every message get
split into two chunks. The client MUST send this protocol message to
the server to notify that the chunk size is set to 131 bytes.
The maximum chunk size can be 65536 bytes. Chunk size is maintained
independently for server to client communication and client to server
communication.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk size (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Pay load for the protocol message ‘Set Chunk Size’
chunk size: 32 bits
This field holds the new chunk size, which will be used for all
future chunks sent by this chunk stream.
5.2. Abort Message (2)
Protocol control message 2, Abort Message, is used to notify the peer
if it is waiting for chunks to complete a message, then to discard
the partially received message over a chunk stream and abort
processing of that message. The peer receives the chunk stream ID of
the message to be discarded as payload of this protocol message. This
message is sent when the sender has sent part of a message, but wants
to tell the receiver that the rest of the message will not be sent. RTMP Message Formats June 2009
Adobe Systems Inc. [Page 7]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk stream id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Pay load for the protocol message ‘Abort Message’.
chunk stream ID: 32 bits
This field holds the chunk stream ID, whose message is to be
discarded.
5.3. Acknowledgement (3)
The client or the server sends the acknowledgment to the peer after
receiving bytes equal to the window size. The window size is the
maximum number of bytes that the sender sends without receiving
acknowledgment from the receiver. The server sends the window size to
the client after application connects. This message specifies the
sequence number, which is the number of the bytes received so far.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence number (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Pay load for the protocol message ‘Acknowledgement’.
sequence number: 32 bits
This field holds the number of bytes received so far.
5.4. User Control Message (4)
The client or the server sends this message to notify the peer about
the user control events. This message carries Event type and Event
data.
+------------------------------+-------------------------
| Event Type ( 2- bytes ) | Event Data
+------------------------------+-------------------------
Figure 5 Pay load for the ‘User Control Message’.
The first 2 bytes of the message data are used to identify the Event
type. Event type is followed by Event data. Size of Event data field
is variable.
RTMP Message Formats June 2009
Adobe Systems Inc. [Page 8]
5.5. Window Acknowledgement Size (5)
The client or the server sends this message to inform the peer which
window size to use when sending acknowledgment. For example, a server
expects acknowledgment from the client every time the server sends
bytes equivalent to the window size. The server updates the client
about its window size after successful processing of a connect
request from the client.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgement Window size (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Pay load for ‘Window Acknowledgement Size’.
5.6. Set Peer Bandwidth (6)
The client or the server sends this message to update the output
bandwidth of the peer. The output bandwidth value is the same as the
window size for the peer. The peer sends ‘Window Acknowledgement
Size’ back if its present window size is different from the one
received in the message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgement Window size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Limit type |
+-+-+-+-+-+-+-+-+
Figure 7 Pay load for ‘Set Peer Bandwidth’
The sender can mark this message hard (0), soft (1), or dynamic (2)
using the Limit type field. In a hard (0) request, the peer must send
the data in the provided bandwidth. In a soft (1) request, the
bandwidth is at the discretion of the peer and the sender can limit
the bandwidth. In a dynamic (2) request, the bandwidth can be hard or
soft.
3.7. User Control message
The client or the server sends this message to notify the peer about
the user control events. For information about the message format,
refer to the User Control Messages section in the RTMP Message
Foramts draft.
The following user control event types are supported: RTMP Commands Messages June 2009
Adobe Systems Inc. [Page 10]
+---------------+--------------------------------------------------+
| Event | Description |
+---------------+--------------------------------------------------+
|Stream Begin | The server sends this event to notify the client |
| (=0) | that a stream has become functional and can be |
| | used for communication. By default, this event |
| | is sent on ID 0 after the application connect |
| | command is successfully received from the |
| | client. The event data is 4-byte and represents |
| | the stream ID of the stream that became |
| | functional. |
+---------------+--------------------------------------------------+
| Stream EOF | The server sends this event to notify the client |
| (=1) | that the playback of data is over as requested |
| | on this stream. No more data is sent without |
| | issuing additional commands. The client discards |
| | the messages received for the stream. The |
| | 4 bytes of event data represent the ID of the |
| | stream on which playback has ended. |
+---------------+--------------------------------------------------+
| StreamDry | The server sends this event to notify the client |
| (=2) | that there is no more data on the stream. If the |
| | server does not detect any message for a time |
| | period, it can notify the subscribed clients |
| | that the stream is dry. The 4 bytes of event |
| | data represent the stream ID of the dry stream. |
+---------------+--------------------------------------------------+
| SetBuffer | The client sends this event to inform the server |
| Length (=3) | of the buffer size (in milliseconds) that is |
| | used to buffer any data coming over a stream. |
| | This event is sent before the server starts |
| | processing the stream. The first 4 bytes of the |
| | event data represent the stream ID and the next |
| | 4 bytes represent the buffer length, in |
| | milliseconds. |
+---------------+--------------------------------------------------+
| StreamIs | The server sends this event to notify the client |
| Recorded (=4) | that the stream is a recorded stream. The |
| | 4 bytes event data represent the stream ID of |
| | the recorded stream. |
+---------------+--------------------------------------------------+
| PingRequest | The server sends this event to test whether the |
| (=6) | client is reachable. Event data is a 4-byte |
| | timestamp, representing the local server time |
| | when the server dispatched the command. The |
| | client responds with kMsgPingResponse on |
| | receiving kMsgPingRequest. | RTMP Commands Messages June 2009
Adobe Systems Inc. [Page 11]
+---------------+--------------------------------------------------+
| PingResponse | The client sends this event to the server in |
| (=7) | response to the ping request. The event data is |
| | a 4-byte timestamp, which was received with the |
| | kMsgPingRequest request. |
+-----------------+--------------------------------------------------------+
+------------------------------------------------------------------+
| |
| +--------------+ +-------------+ |
| | Client | | | Server | |
| +------+-------+ | +------+------+ |
| | Handshaking done | |
| | | | |
| | | | |
| | | | |
| | | | |
| |----------- Command Message(connect) ------->| |
| | | |
| |<------- Window Acknowledgement Size --------| |
| | | |
| |<----------- Set Peer Bandwidth -------------| |
| | | |
| |-------- Window Acknowledgement Size ------->| |
| | | |
| |<------ User Control Message(StreamBegin) ---| |
| | | |
| |<------------ Command Message ---------------| |
| | (_result- connect response) | |
| | | |
| |
+------------------------------------------------------------------+
浙公网安备 33010602011771号