RTMP Message Formats (RTMP消息格式)

RTMP Message Formats (RTMP消息格式)

Real Time Messaging Protocol (RTMP) Message Formats

 

Copyright Notice

Copyright (c) 2009 Adobe Systems Incorporated. All rights reserved.

 

Abstract

This memo describes the Real Time Messaging Protocol, an application level protocol designed for multiplexing 

and packetizing multimedia transport streams (such as audio, video, and interactive content)over a suitable 

transport protocol, such as RTMP chunking stream protocol.RTMP Message Formats

1. Introduction

The document specifies the Real Time Messaging Protocol, which specifies the format of the messages that are

 transferred between entities on a network using a lower level transport layer. While RTMP was designed to work

 with the Real Time Messaging Chunk Stream Protocol, 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.

 

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

document are to be interpreted as described in [BCP14], [RFC2119].

 

2. Definitions

Message stream:

A logical channel of communication in which messages flow.

Message stream ID:

Each message has an ID associated with it to identify the message

stream in which it is flowing.

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.

Packet:

A data packet consists of the fixed header and the payload data.

Some underlying protocols may require an encapsulation of the

packet to be defined.

 

3. Byte Order, Alignment, and Time Format

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).

 

Except as otherwise specified, all data in RTMP is byte-aligned, for

example, a 16-bit field may be at an odd byte offset. Where padding

is indicated, padding bytes SHOULD have the value zero.

 

Timestamps in RTMP are given as an integer number of milliseconds,

relative to an unspecified epoch. Typically, each message stream will

start with a message having timestamp 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 streams (especially from

separate hosts) requires some additional mechanism outside of RTMP.

 

Timestamps MUST be monotonically increasing, and SHOULD be linear in

time, to allow applications to handle synchronization, bandwidth

measurement, jitter detection, and flow control.

 

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 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 4000000000.

 

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.

 

4. RTMP Message Format(RTMP消息格式)

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.

服务端和客户端通过发送RTMP消息来通信。

这种消息可以包括音频，视频或其它消息。

 

The RTMP message has two parts, a header and its payload.

RTMP消息分成两个部分，头和它的负载。

 

4.1. Message Header(消息头)

The message header contains the following:

消息头包含如下：

 

Message Type(消息类型):

One byte field to represent the message type. A range of type IDs

(1-7) are reserved for protocol control messages.

消息类型用一个字节的字段来表示。

ID1-7保留给协议控制消息。

 

Length(长度):

Three-byte field that represents the size of the payload in bytes.

It is set in big-endian format.

负载的字节长度用三个字节的字段来表示。

 

Timestamp(时间戳):

Four-byte field that contains a timestamp of the message.

The 4 bytes are packed in the big-endian order.

消息的时间戳用四字节的字段来表示。

 

Message Stream Id(消息流ID):

Three-byte field that identifies the stream of the message. These

bytes are set in big-endian format.

消息流ID用三个字节的字段来表示。

Figure 1 Message header

 

4.2. Message Payload(消息负载)

The other part which is the payload is the actual data that is

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.

消息的另一部分负载是实际数据。

例如，它可以包含音频样本或压缩后的视频数据。

负载的格式和说明超过了本文档的说明。

 

5. Protocol Control Messages(协议控制消息)

RTMP reserves message type IDs 1-7 for protocol control messages.

These messages contain information needed by the RTMP Chunk Stream

protocol or RTMP itself. Protocol messages with IDs 1 & 2 are

reserved for usage with RTMP Chunk Stream protocol. Protocol messages

with IDs 3-6 are reserved for usage of RTMP. Protocol message with ID

7 is used between edge server and origin server.

RTMP保留了消息类型ID1-7用于协议控制消息。

这些消息包含的信息用于RTMP数据块流协议或RTMP本身。

ID号为1或2的协议消息用于RTMP数据块流协议。

ID号为3-6的协议消息用于RTMP。

ID号为7的协议消息用于边源服务器和源服务器。

 

Protocol control messages MUST have message stream ID 0 (called as

control stream) and chunk stream ID 2, and are sent with highest priority.

协议控制消息的消息流ID号为0(称为控制流)且数据流ID号为2，且

以最高优先级发送。

 

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.

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.

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.

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.

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.

 

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.

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.

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.

 

6. References

6.1. Normative References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement

Levels", BCP 14, RFC 2119, March 1997.

[2] Crocker, D. and Overell, P. (Editors), "Augmented BNF for

Syntax Specifications: ABNF", RFC 2234, Internet Mail

Consortium and Demon Internet Ltd., November 1997.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2234] Crocker, D. and Overell, P. (Editors), "Augmented BNF for

Syntax Specifications: ABNF", RFC 2234, Internet Mail

Consortium and Demon Internet Ltd., November 1997.

6.2. Informative References

[3] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP

and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-

1583.

[Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in

TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp.

1573-1583.

Address:

Adobe Systems Incorporated

345 Park Avenue

San Jose, CA 95110-2704