Adobe’s Real Time Messaging
Protocol
Chih-Hsiang Chou
Advisor: Prof Dr. Ho-Ting Wu
Department of Computer Science and Information Engineering,
National Taipei University of Technology
Taiwan, ROC.
Data:13/11/18
Outline
•
•
•
•
•
Introduction
RTMP Chunk Stream
RTMP Message Formats
RTMP Command Messages
References
2
Introduction
Adobe’s Real Time Messaging Protocol (RTMP), an
application-level protocol, provides a bidirectional
message multiplex service over a reliable stream
transport, such as TCP, intended to carry parallel
streams of video, audio, and data messages, with
associated timing information, between a pair of
communicating peers.
3
Introduction
Implementations typically assign different priorities
to different classes of messages, which can effect the
order in which messages are enqueued to the
underlying stream transport when transport capacity is
constrained.
4
RTMP Chunk Stream
RTMP chunk stream provides multiplexing and
packetizing services for a higher-level multimedia
stream protocol.
Used with a reliable transport protocol such as TCP,
RTMP Chunk Stream provides guaranteed timestampordered end-to-end delivery of all messages, across
multiple streams.
5
RTMP Chunk Stream
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.
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.
6
RTMP Chunk Stream
- Message Format
The format of a message that can be split into
chunks to support multiplexing depends on a higher
level protocol.
The message format SHOULD contain the following
fields which are necessary for creating the chunks.




Timestamp
Length
Type Id
Message Stream ID
7
RTMP Chunk Stream
- Handshake
An RTMP connection begins with a handshake. The
handshake is unlike the rest of the protocol; it consists
of three static-sized chunks rather than consisting of
variable-sized chunks with headers.
The client and the server each send the same three
chunks.
For exposition, these chunks will be designated C0,
C1, and C2 when sent by the client; S0, S1, and S2
when sent by the server.
8
RTMP Chunk Stream
- Handshake
 Handshake Sequence
The handshake begins with the client sending the C0
and C1 chunks.
The client MUST wait until S1 has been received
before sending C2.
The client MUST wait until S2 has been received
before sending any other data.
9
RTMP Chunk Stream
- Handshake
 Handshake Sequence
The server MUST wait until C0 has been received
before sending S0 and S1, and MAY wait until after C1
as well.
The server MUST wait until C1 has been received
before sending S2.
The server MUST wait until C2 has been received
before sending any other data.
10
RTMP Chunk Stream
- Handshake
 C0 and S0 Format
The C0 and S0 packets are a single octet, treated as a
single 8-bit integer field:
11
RTMP Chunk Stream
- Handshake
 C0 and S0 Format
Version (8 bits):
In C0, this field identifies the RTMP version requested by
the client.
In S0, this field identifies the RTMP version selected by
the server.
The version defined by this specification is 3. Values 0-2
are deprecated values used by earlier proprietary products;
4-31 are reserved for future implementations; and 32-255
are not allowed.
A server that does not recognize the client’s requested
version SHOULD respond with 3. The client MAY choose to
degrade to version 3, or to abandon the handshake.
12
RTMP Chunk Stream
- Handshake
 C1 and S1 Format
13
RTMP Chunk Stream
- Handshake
 C1 and S1 Format
Time (4 bytes):
This field contains a timestamp, which SHOULD be
used as the epoch for all future chunks sent from this
endpoint.
This may be 0, or some arbitrary value. To
synchronize multiple chunkstreams, the endpoint may
wish to send the current value of the other
chunkstream’s timestamp.
14
RTMP Chunk Stream
- Handshake
 C1 and S1 Format
Zero (4 bytes): This field MUST be all 0s.
Random data (1528 bytes):
This field can contain any arbitrary values. Since
each endpoint has to distinguish between the response
to the handshake it has initiated and the handshake
initiated by its peer, this data SHOULD send something
sufficiently random.
But there is no need for cryptographically-secure
randomness, or even dynamic values.
15
RTMP Chunk Stream
- Handshake
 C2 and S2 Format
16
RTMP Chunk Stream
- Handshake
 C2 and S2 Format
Time (4 bytes):
This field MUST contain the timestamp sent by the
peer in S1 (for C2) or C1 (for S2).
Time2 (4 bytes):
This field MUST contain the timestamp at which the
previous packet(s1 or c1) sent by the peer was read.
17
RTMP Chunk Stream
- Handshake
 C2 and S2 Format
Random echo (1528 bytes):
This field MUST contain the random data field sent
by the peer in S1 (for C2) or C1 (for S2).
Either peer can use the time and time2 fields
together with the current timestamp as a quick
estimate of the bandwidth and/or latency of the
connection.
18
RTMP Chunk Stream
- Handshake
 Handshake Diagram
19
RTMP Chunk Stream
- Chunking
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. At the
receiver end, the chunks are assembled into messages
based on the chunk stream ID.
The chunks are transmitted over the network. While
transmitting, each chunk must be sent in full before
the next chunk.
20
RTMP Chunk Stream
- Chunking
The chunk size is configurable. It can be set using a
Set Chunk Size control message.
Larger chunk sizes 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
peer.
21
RTMP Chunk Stream
- Chunking
 Chunk Format
Each chunk consists of a header and data. The header
itself has three parts:
22
RTMP Chunk Stream
- Chunking
 Chunk Format
-- Chunk Basic Header
The Chunk Basic Header encodes the chunk stream
ID and the chunk type.
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.
23
RTMP Chunk Stream
- Chunking
 Chunk Format
-- Chunk Basic Header
The protocol supports up to 65597 streams with IDs
3-65599. The IDs 0, 1, and 2 are reserved.
Value 0 indicates the 2 byte form and an ID in the
range of 64-319 (the second byte + 64).
Value 1 indicates the 3 byte form and an ID in the
range of 64-65599 ((the third byte)*256 + the second
byte + 64).
24
RTMP Chunk Stream
- Chunking
 Chunk Format
-- Chunk Basic Header
Values in the range of 3-63 represent the complete
stream ID. Chunk Stream ID with value 2 is reserved
for low-level protocol control messages and
commands.
25
RTMP Chunk Stream
- Chunking
 Chunk Format
-- Chunk Basic Header
26
RTMP Chunk Stream
- Chunking
 Chunk Format
-- Chunk Basic Header
27
RTMP Chunk Stream
- Chunking
 Chunk Format
-- Chunk Message Header
This field encodes information about the message
being sent.
There are four different formats for the chunk
message header, selected by the "fmt" field in the
chunk basic header.
 Type 0 - 4
28
RTMP Chunk Stream
- Chunking
 Chunk Message Header
-- Type 0
Type 0 chunk headers are 11 bytes long. This type
MUST be used at the start of a chunk stream.
29
RTMP Chunk Stream
- Chunking
 Chunk Message Header
-- Type 1
Type 1 chunk headers are 7 bytes long. The message
stream ID is not included; this chunk takes the same
stream ID as the preceding chunk.
30
RTMP Chunk Stream
- Chunking
 Chunk Message Header
-- Type 2
Type 2 chunk headers 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.
31
RTMP Chunk Stream
- Chunking
 Chunk Message Header
-- Type 3
Type 3 chunks have no message header. The stream
ID, message length and timestamp delta fields are not
present; chunks of this type take values from the
preceding chunk for the same Chunk Stream ID.
When a single message is split into chunks, all
chunks of a message except the first one SHOULD use
this type.
32
RTMP Chunk Stream
- Chunking
33
RTMP Chunk Stream
- Chunking
34
RTMP Chunk Stream
- Chunking
35
RTMP Chunk Stream
- Protocol Control Messages
RTMP Chunk Stream uses message type IDs 1, 2, 3, 5,
and 6 for protocol control messages. These messages
contain information needed by the RTMP Chunk
Stream protocol.
These protocol control messages MUST have
message stream ID 0 and be sent in chunk stream ID 2.
Protocol control messages take effect as soon as they
are received; their timestamps are ignored.
36
RTMP Chunk Stream
- Protocol Control Messages
Set Chunk Size (1)
Abort Message (2)
Acknowledgement (3)
Window Acknowledgement Size (5)
Set Peer Bandwidth (6)
37
RTMP Message Formats
RTMP was designed to work with the RTMP Chunk
Stream, it can send the messages using any other
transport protocol.
RTMP Chunk Stream and RTMP together are suitable
for a wide variety of audio-video applications, from
one-to-one and one-to-many live broadcasting to
video-on-demand services to interactive conferencing
applications.
38
RTMP Message Formats
- RTMP Message Format
The server and the client send RTMP messages over
the network to communicate with each other. The
messages could include audio, video, data, or any other
messages.
The RTMP message has two parts, a header and its
payload.
39
RTMP Message Formats
- RTMP Message Format
 Message Header
40
RTMP Message Formats
- RTMP Message Format
 Message Payload
The other part of the message is the payload, which
is the actual data contained in the message.
For example, it could be some audio samples or
compressed video data.
The payload format and interpretation are beyond
the scope of this document.
41
RTMP Message Formats
 User Control Messages (4)
RTMP uses message type ID 4 for User Control
messages.
These messages contain information used by the
RTMP streaming layer.
User Control messages SHOULD use message stream
ID 0 and, when sent over RTMP Chunk Stream, be sent
on chunk stream ID 2. User Control messages are
effective at the point they are received in the stream;
their timestamps are ignored.
42
RTMP Command Messages
The different types of messages that are exchanged
between the server and the client include audio
messages for sending the audio data, video messages
for sending video data, data messages for sending any
user data, shared object messages, and command
messages.
43
RTMP Command Messages
 Types of Messages
Command Message (AMF0:20, AMF3:17)
Data Message (AMF0:18, AMF3:15)
Shared Object Message (AMF0:19, AMF3:16)
Audio Message (8)
Video Message (9)
Aggregate Message (22)
44
RTMP Command Messages
 Types of Commands
The sender sends a command message that consists
of command name, transaction ID, and command
object that contains related parameters.
For example, the connect command contains ’app’
parameter, which tells the server application name the
client is connected to.
The receiver processes the command and sends back
the response with the same transaction ID. The
response string is either _result, _error.
45
RTMP Command Messages
 Types of Commands
The following class objects are used to send various
commands:
NetConnection An object that is a higher-level
representation of connection between the server and
the client.
NetStream An object that represents the channel
over which audio streams, video streams and other
related data are sent. We also send commands like
play , pause etc. which control the flow of the data.
46
RTMP Command Messages
- Types of Commands
 NetConnection Commands
-- connect
-- close
-- createStream
47
RTMP Command Messages
- Types of Commands
 NetConnection Commands
-- connect
The client sends the connect command to the server
to request connection to a server application instance.
48
RTMP Command Messages
- Types of Commands
 NetConnection Commands
-- createStream
The client sends this command to the server to
create a logical channel for message communication
The publishing of audio, video, and metadata is carried
out over stream channel created using the
createStream command
49
RTMP Command Messages
- Types of Commands
 NetStream Commands
-- play
-- play2
-- deleteStream
-- closeStream
-- receiveAudio/receiveVideo
-- publish
-- seek
-- pause
50
51
RTMP Command Messages
- Types of Commands
 NetStream Commands
-- play2
Unlike the play command, play2 can switch to a
different bit rate stream without changing the timeline
of the content played.
The server maintains multiple files for all supported
bitrates that the client can request in play2.
52
53
References
[1] H. Parmar and M. Thornburgh. “Adobe’s Real Time
Messaging Protocol”, December 21, 2012
54
Thanks for your listening
55