RTMP官方协议不必翻译

最新推荐文章于 2024-07-01 20:41:21 发布

伍意

最新推荐文章于 2024-07-01 20:41:21 发布

阅读量1.5k

点赞数

分类专栏： RTMP 音视频文章标签： RTMP

本文链接：https://blog.csdn.net/doitsjz/article/details/50807537

版权

音视频同时被 2 个专栏收录

14 篇文章 2 订阅

订阅专栏

RTMP

3 篇文章 0 订阅

订阅专栏

M. Thornburgh, Ed.

Adobe

December 21, 2012

Adobe’s Real Time Messaging Protocol

Abstract

This memo describes Adobe’s RealTime Messaging Protocol (RTMP), an application-level protocol designed formultiplexing and packetizing multimedia transport streams (such as audio,video, and interactive content) over a suitable transport protocol (such as TCP).

Table of Contents

1.	Introduction . .	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	3
	1.1. Terminology	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	3
2.	Contributors . .	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	3
3.	Definitions . .	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	3
4.	Byte Order, Alignment, and Time Format												.	.	.	.	.	.	.	.	.	.	.	.	5
5.	RTMP Chunk Stream . . . . . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	5
	5.1. Message Format . . . . . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	6
	5.2. Handshake . . . . . . . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	7
	5.2.1. Handshake Sequence . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	7
	5.2.2. C0 and S0 Format . . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	7
	5.2.3. C1 and S1 Format . . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	8
	5.2.4. C2 and S2 Format . . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	8
	5.2.5. Handshake Diagram . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	10
	5.3. Chunking . . . . . . . . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	11
	5.3.1. Chunk Format . . . . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	11
	5.3.1.1. Chunk Basic Header . . . .												.	.	.	.	.	.	.	.	.	.	.	.	12
	5.3.1.2. Chunk Message Header . . .												.	.	.	.	.	.	.	.	.	.	.	.	13
	5.3.1.2.1. Type 0 . . . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	14
	5.3.1.2.2. Type 1 . . . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	14
	5.3.1.2.3. Type 2 . . . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	15
	5.3.1.2.4. Type 3 . . . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	15
	5.3.1.2.5. Common Header Fields .												.	.	.	.	.	.	.	.	.	.	.	.	15
	5.3.1.3. Extended Timestamp . . . .												.	.	.	.	.	.	.	.	.	.	.	.	16
	5.3.2. Examples . . . . . . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	16
	5.3.2.1. Example 1 . . . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	16
	5.3.2.2. Example 2 . . . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	17
	5.4. Protocol Control Messages . . . .												.	.	.	.	.	.	.	.	.	.	.	.	18
	5.4.1. Set Chunk Size (1) . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	19
	5.4.2. Abort Message (2) . . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	19
	5.4.3. Acknowledgement (3) . . . . .												.	.	.	.	.	.	.	.	.	.	.	.	20

Parmar& Thornburgh [Page1]

5.4.4. Window Acknowledgement Size (5) . . .	.	.	.	.	.	.	.	.	20
5.4.5. Set Peer Bandwidth (6) . . . . . . . .	.	.	.	.	.	.	.	.	21
6. RTMP Message Formats . . . . . . . . . . . . .	.	.	.	.	.	.	.	.	21
6.1. RTMP Message Format . . . . . . . . . . .	.	.	.	.	.	.	.	.	22
6.1.1. Message Header . . . . . . . . . . . .	.	.	.	.	.	.	.	.	22
6.1.2. Message Payload . . . . . . . . . . .	.	.	.	.	.	.	.	.	22
6.2. User Control Messages (4) . . . . . . . .	.	.	.	.	.	.	.	.	23
7. RTMP Command Messages . . . . . . . . . . . .	.	.	.	.	.	.	.	.	23
7.1. Types of Messages . . . . . . . . . . . .	.	.	.	.	.	.	.	.	24
7.1.1. Command Message (20, 17) . . . . . . .	.	.	.	.	.	.	.	.	24
7.1.2. Data Message (18, 15) . . . . . . . .	.	.	.	.	.	.	.	.	24
7.1.3. Shared Object Message (19, 16) . . . .	.	.	.	.	.	.	.	.	24
7.1.4. Audio Message (8) . . . . . . . . . .	.	.	.	.	.	.	.	.	26
7.1.5. Video Message (9) . . . . . . . . . .	.	.	.	.	.	.	.	.	26
7.1.6. Aggregate Message (22) . . . . . . . .	.	.	.	.	.	.	.	.	26
7.1.7. User Control Message Events . . . . .	.	.	.	.	.	.	.	.	27
7.2. Types of Commands . . . . . . . . . . . .	.	.	.	.	.	.	.	.	28
7.2.1. NetConnection Commands . . . . . . . .	.	.	.	.	.	.	.	.	29
7.2.1.1. connect . . . . . . . . . . . . .	.	.	.	.	.	.	.	.	29
7.2.1.2. Call . . . . . . . . . . . . . . .	.	.	.	.	.	.	.	.	35
7.2.1.3. createStream . . . . . . . . . . .	.	.	.	.	.	.	.	.	36
7.2.2. NetStream Commands . . . . . . . . . .	.	.	.	.	.	.	.	.	37
7.2.2.1. play . . . . . . . . . . . . . . .	.	.	.	.	.	.	.	.	38
7.2.2.2. play2 . . . . . . . . . . . . . .	.	.	.	.	.	.	.	.	42
7.2.2.3. deleteStream . . . . . . . . . . .	.	.	.	.	.	.	.	.	43
7.2.2.4. receiveAudio . . . . . . . . . . .	.	.	.	.	.	.	.	.	44
7.2.2.5. receiveVideo . . . . . . . . . . .	.	.	.	.	.	.	.	.	45
7.2.2.6. publish . . . . . . . . . . . . .	.	.	.	.	.	.	.	.	45
7.2.2.7. seek . . . . . . . . . . . . . . .	.	.	.	.	.	.	.	.	46
7.2.2.8. pause . . . . . . . . . . . . . .	.	.	.	.	.	.	.	.	47
7.3. Message Exchange Examples . . . . . . . .	.	.	.	.	.	.	.	.	48
7.3.1. Publish Recorded Video . . . . . . . .	.	.	.	.	.	.	.	.	48
7.3.2. Broadcast a Shared Object Message . .	.	.	.	.	.	.	.	.	50
7.3.3. Publish Metadata from Recorded Stream	.	.	.	.	.	.	.	.	50
8. References . . . . . . . . . . . . . . . . . .	.	.	.	.	.	.	.	.	51
Authors’ Addresses . . . . . . . . . . . . . . . .	.	.	.	.	.	.	.	.	52

1. Introduction

Adobe’s Real Time Messaging Protocol(RTMP) provides a bidirectional message multiplex service over a reliablestream transport, such as TCP [RFC0793], intended to carry parallel streams ofvideo, audio,

and data messages, with associatedtiming information, between a pair of communicating peers. Implementations typically assign differentpriorities to different classes of messages, which can effect the order inwhich messages are enqueued to the underlying stream transport when transportcapacity is constrained.

Thismemo describes the syntax and operation of the Real Time

Messaging Protocol.

1.1. Terminology

The key words "MUST","MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED","NOT RECOMMENDED", "MAY", and "OPTIONAL" in thismemo are to be interpreted as described in [RFC2119].

2. Contributors

Rajesh Mallipeddi, formerly of AdobeSystems, was the original editor of this specification, and provided most ofits original text.

Mohit Srivastava of Adobe Systemscontributed to the development of this specification.

3. Definitions

Payload: The data contained in a packet, for exampleaudio samples or compressed video data. Thepayload format and interpretation are beyond the scope of this document.

Packet: A data packet consists of fixed header andpayload data.

Some underlying protocols may require an encapsulation ofthe

packet to be defined.

Port: The "abstraction that transport protocolsuse to distinguish among multiple destinations within a given host computer. TCP/IP protocols identify ports usingsmall positive integers." Thetransport selectors (TSEL) used by the OSI transport layer are equivalent toports.

Transportaddress: The combination of a networkaddress and port that identifies a transport-level endpoint, for example an IPaddress and a TCP port. Packets aretransmitted from a source transport address to a destination transport address.

Messagestream: A logical channel ofcommunication in which messages flow.

Messagestream ID: Each message has an IDassociated with it to identify the message stream in which it is flowing.

Chunk: A fragment of a message. The messages are broken into smaller partsand interleaved before they are sent over the network. The chunks ensure timestamp-ordered end-to-end delivery of allmessages, across multiple streams.

Chunkstream: A logical channel ofcommunication that allows flow of chunks in a particular direction. The chunk stream can travel

fromthe client to the server and reverse.

Chunkstream ID: Every chunk has an IDassociated with it to identify the chunk stream in which it is flowing.

Multiplexing: Process of making separate audio/video datainto one coherent audio/video stream, making it possible to transmit severalvideo and audio simultaneously.

DeMultiplexing: Reverse process of multiplexing, in whichinterleaved audio and video data are assembled to form the original audio andvideo data.

RemoteProcedure Call (RPC): A request thatallows a client or a server to call a subroutine or procedure at the peer end.

Metadata: A description about the data. The metadata of a movie includes the movietitle, duration, date of creation, and so on.

ApplicationInstance: The instance of theapplication at the server with which the clients connect by sending the connectrequest.

Action Message Format (AMF): A compact binary format that is used toserialize ActionScript object graphs. AMFhas two versions: AMF 0 [AMF0] and AMF 3 [AMF3].

4. Byte Order, Alignment, and Time Format

All integer fields are carried innetwork byte order, byte zero is the first byte shown, and bit zero is the mostsignificant bit in a word or field. Thisbyte order is commonly known as big-endian. Thetransmission order is described in detail in Internet Protocol [RFC0791]. Unless otherwise noted, numeric constants inthis

documentare in decimal (base 10).

Except as otherwise specified, all data in RTMP isbyte-aligned; for example, a 16-bit field may be at an odd byte offset. Where padding is indicated, padding bytesSHOULD have the value zero.

Timestamps in RTMP are given as aninteger number of milliseconds relative to an unspecified epoch. Typically, each stream will start with atimestamp of 0, but this is not required, as long as the two endpoints agree onthe epoch. Note that this means thatany synchronization across multiple streams (especially from separate hosts)requires some additional mechanism outside of RTMP.

Because timestamps are 32 bits long,they roll over every 49 days, 17 hours, 2 minutes and 47.296 seconds. Because streams are allowed to runcontinuously, potentially for years on end, an RTMP application SHOULD useserial number arithmetic [RFC1982] when processing timestamps, and SHOULD becapable of handling wraparound. Forexample, an application assumes that all adjacent timestamps are within 2^31 -1 milliseconds of each other, so 10000 comes after

4000000000,and 3000000000 comes before 4000000000.

Timestamp deltas are also specifiedas an unsigned integer number of milliseconds, relative to the previoustimestamp. Timestamp deltas may beeither 24 or 32 bits long.

5. RTMP Chunk Stream

This section specifies the Real TimeMessaging Protocol Chunk Stream (RTMP Chunk Stream). It provides multiplexing and packetizing services for ahigher-level multimedia stream protocol.

While RTMP Chunk Stream was designedto work with the Real Time Messaging Protocol (Section 6), it can handle anyprotocol that sends a stream of messages. Eachmessage contains timestamp and payload type identification. RTMP Chunk Stream and RTMP together are

suitable for a wide variety ofaudio-video applications, from one-to- one and one-to-many live broadcasting tovideo-on-demand services to interactive conferencing applications.

When used with a reliable transportprotocol such as TCP [RFC0793], RTMP Chunk Stream provides guaranteedtimestamp-ordered end-to-end delivery of all messages, across multiple streams. RTMP Chunk Stream does not provide anyprioritization or similar forms of control, but can be used by higher-level protocolsto provide such prioritization. For example, a live video server might chooseto drop video messages for a slow client to ensure that audio messages arereceived in a timely fashion, based on either the time to send or the time toacknowledge each message.

RTMP Chunk Stream includes its ownin-band protocol control messages, and also offers a mechanism for thehigher-level protocol to embed user control messages.

5.1. Message Format

The format of a message that can besplit into chunks to support multiplexing depends on a higher level protocol. The message format SHOULD however containthe following fields which are necessary for creating the chunks.

Timestamp: Timestamp of the message. This field can transport 4 bytes.

Length: Length of the message payload. If the message header cannot be elided, itshould be included in the length. Thisfield occupies 3 bytes in the chunk header.

TypeId: A range of type IDs are reserved forprotocol control messages. Thesemessages which propagate information are handled by both RTMP Chunk Streamprotocol and the higher-level protocol. All other type IDs are available foruse by the higher-level protocol, and treated as opaque values by RTMP ChunkStream. In fact, nothing in RTMPChunk Stream requires these values to be used as a type; all (non-protocol)messages could be of the same type, or the application could use this field todistinguish

simultaneous tracks rather thantypes. This field occupies 1 byte inthe chunk header.

MessageStream ID: The message stream ID canbe any arbitrary value.

Different message streams multiplexed onto the same chunkstream

are demultiplexed based on their message stream IDs. Beyond that,

as far as RTMP Chunk Stream is concerned, this is anopaque value.

This field occupies 4 bytes in the chunk header in littleendian

format.

5.2. Handshake

An RTMP connection begins with ahandshake. The handshake is unlikethe rest of the protocol; it consists of three static-sized chunks rather thanconsisting of variable-sized chunks with headers.

The client (the endpoint that hasinitiated the connection) and the server each send the same three chunks. For exposition, these chunks will be designatedC0, C1, and C2 when sent by the client; S0, S1,

andS2 when sent by the server.

5.2.1. Handshake Sequence

The handshake begins with the client sending the C0 and C1chunks. The client MUST wait until S1 has been received before sending C2.

The client MUST wait until S2 has been received beforesending any

other data.

The server MUST wait until C0 hasbeen received before sending S0 and S1, and MAY wait until after C1 as well. The server MUST wait until C1 has beenreceived before sending S2. Theserver MUST wait until

C2has been received before sending any other data.

5.2.2. C0 and S0 Format

The C0 and S0 packets are a singleoctet, treated as a single 8-bit integer field:

0 1 2 3 4 5 6 7

+-+-+-+-+-+-+-+-+

| version |

+-+-+-+-+-+-+-+-+

C0 and S0 bits

Followingare the fields in the C0/S0 packets:

Version (8bits): In C0, this field identifies theRTMP version requested by the client. InS0, this field identifies the RTMP version selected by the server. The version defined by this specificationis 3. Values 0-2 are deprecatedvalues used by earlier proprietary products; 4-31 are reserved for futureimplementations; and 32-255 are not allowed (to allow distinguishing RTMP fromtext-based protocols, which always start with a printable character). A server that does not recognize theclient’s requested version SHOULD respond with 3. The client MAY choose to degrade to version 3, or to abandon thehandshake.

5.2.3. C1 and S1 Format

The C1 and S1 packets are 1536octets long, consisting of the following fields:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 34 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| time (4 bytes) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| zero (4 bytes) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| random bytes |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| random bytes |

| (cont) |

| .... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C1 and S1 bits

Time (4bytes): This field contains a timestamp,which SHOULD be used as the epoch for all future chunks sent from thisendpoint. This may be 0, or some arbitrary value. To synchronize multiple chunkstreams, the endpoint may wish tosend the current value of the other chunkstream’s timestamp.

Zero(4 bytes): This field MUST be all 0s.

Randomdata (1528 bytes): This field cancontain any arbitrary values. Sinceeach endpoint has to distinguish between the response to the handshake it hasinitiated and the handshake initiated by its peer,this data SHOULD sendsomething sufficiently random. But thereis no need for cryptographically-secure randomness, or even dynamic values.

5.2.4. C2 and S2 Format

The C2 and S2 packets are 1536octets long, and nearly an echo of S1 and C1 (respectively), consisting of thefollowing fields:

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 34 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| time (4 bytes) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| time2 (4 bytes) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| random echo |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| random echo |

| (cont) |

| .... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

C2 and S2 bits

Time (4bytes): This field MUST contain thetimestamp sent by the peer in S1 (for C2) or C1 (for S2).

Time2 (4bytes): This field MUST contain thetimestamp at which the previous packet(s1 or c1) sent by the peer was read.

Randomecho (1528 bytes): This field MUSTcontain the random data field sent by the peer in S1 (for C2) or S2 (for C1). Either peer can use the time and time2fields together with the current timestamp as a quick estimate of the bandwidthand/or latency of the connection, but this is unlikely to be useful.

5.2.5. Handshake Diagram

+-------------+ +-------------+

| Client | TCP/IP Network | Server |

+-------------+ | +-------------+

| | |

Uninitialized | Uninitialized

| C0 | |

|------------------->| C0 |

| |-------------------->|

| C1 | |

|------------------->| S0 |

| |<--------------------|

| | S1 |

Version sent |<--------------------|

| S0 | |

|<-------------------| |

| S1 | |

|<-------------------| Version sent

| | C1 |

| |-------------------->|

| C2 | |

|------------------->| S2 |

| |<--------------------|

Ack sent | Ack Sent

| S2 | |

|<-------------------| |

| | C2 |

| |-------------------->|

Handshake Done | Handshake Done

| | |

Pictorial Representation of Handshake

The following describes the statesmentioned in the handshake diagram:

Uninitialized: The protocol version is sent during this stage. Both the client and server areuninitialized. The The client sendsthe protocol version in packet C0. Ifthe server supports the

version, it sends S0 and S1 inresponse. If not, the server respondsby taking the appropriate action. InRTMP, this action is terminating the connection.

VersionSent: Both client and server are in theVersion Sent state after the Uninitialized state. The client is waiting for the packet S1 and the server iswaiting for the packet C1. Onreceiving the awaited packets, the client sends the packet C2 and

the server sends the packet S2. The state then becomes Ack Sent. AckSent The client and the server wait forS2 and C2 respectively. Handshake Done: The client and the server exchange messages.

5.3. Chunking

After handshaking, the connectionmultiplexes one or more chunk streams. Each chunk stream carries messages of one type from one messagestream. Each chunk that is created has aunique ID associated with it called chunk stream ID. The chunks are

transmitted over the network. While transmitting, each chunk must besent in full before the next chunk. Atthe receiver end, the chunks are assembled into messages based on the chunkstream ID.

Chunking allows large messages atthe higher-level protocol to be broken into smaller messages, for example toprevent large low- priority messages (such as video) from blocking smallerhigh-priority messages (such as audio or control).

Chunking also allows small messagesto be sent with less overhead, as the chunk header contains a compressedrepresentation of information that would otherwise have to be included in themessage itself.

The chunk size is configurable. It can be set using a Set Chunk Sizecontrol message (Section 5.4.1). Largerchunk sizes reduce CPU

usage, but also commit to largerwrites that can delay other content on lower bandwidth connections. Smaller chunks are not good for high bitrate streaming. Chunk size ismaintained independently for each direction.

5.3.1. Chunk Format

Each chunk consists of a header anddata. The header itself has threeparts:

+--------------+----------------+--------------------+--------------+

+--------------+----------------+--------------------+--------------+

| |

|<------------------- Chunk Header----------------->|

Chunk Format

BasicHeader (1 to 3 bytes): This fieldencodes the chunk stream ID and the chunk type. Chunk type determines the format of the encoded message header. The length depends entirely on the chunkstream ID, which is a variable-length field.

MessageHeader (0, 3, 7, or 11 bytes): Thisfield encodes information about the message being sent (whether in whole or inpart). The length can be determined usingthe chunk type specified in the chunk header.

ExtendedTimestamp (0 or 4 bytes): This fieldis present in certain circumstances depending on the encoded timestamp ortimestamp delta field in the Chunk Message header. See Section 5.3.1.3 for more information.

Chunk Data(variable size): The payload of thischunk, up to the configured maximum chunk size.

5.3.1.1. Chunk Basic Header

TheChunk Basic Header encodes the chunk stream ID and the chunk type

(represented by fmt field in the figure below). Chunk type

determines the format of the encoded message header. Chunk Basic

Header field may be 1, 2, or 3 bytes, depending on thechunk stream

ID.

An implementation SHOULD use thesmallest representation that can hold the ID.

Theprotocol 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 ((thethird

byte)*256 + the second byte + 64). 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 andcommands.

The bits 0-5 (least significant) inthe chunk basic header represent the chunk stream ID.

Chunk stream IDs 2-63 can be encodedin the 1-byte version of this field.

0 1 2 3 4 5 6 7

+-+-+-+-+-+-+-+-+

|fmt| cs id |

+-+-+-+-+-+-+-+-+

Chunk basic header 1

Chunk stream IDs 64-319 can beencoded in the 2-byte form of the header. ID is computed as (the second byte + 64).

0		1
0 1 2 3	4 5 6 7 8 9	0 1 2 3 4 5

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|fmt| 0 | cs id - 64 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk basic header 2

Chunk stream IDs 64-65599 can beencoded in the 3-byte version of this field. ID is computed as ((the third byte)*256 + (the second byte) + 64).

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|fmt| 1 | cs id - 64 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk basic header 3

cs id (6bits): This field contains the chunkstream ID, for values from 2-63. Values0 and 1 are used to indicate the 2- or 3-byte versions of this field.

fmt(2 bits): This field identifies one offour format used by the

’chunk message header’. The ’chunk message header’ for each of

the chunk types is explained in the next section.

cs id - 64 (8 or 16 bits): This field contains the chunk stream IDminus 64. For example, ID 365 would berepresented by a 1 in cs id, and a 16-bit 301 here.

Chunk stream IDs with values 64-319could be represented by either the 2-byte or 3-byte form of the header.

5.3.1.2. Chunk Message Header

There are four different formats forthe chunk message header, selected by the "fmt" field in the chunkbasic header.

An implementation SHOULD use themost compact representation possible for each chunk message header.

5.3.1.2.1. Type 0

Type 0 chunk headers are 11 byteslong. This type MUST be used at thestart of a chunk stream, and whenever the stream timestamp goes backward (e.g.,because of a backward seek).

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| timestamp |messagelength |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| messagelength (cont) |message type id| msgstream id |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| messagestream id (cont) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Message Header - Type 0

timestamp(3 bytes): For a type-0 chunk, theabsolute timestamp of the message is sent here. If the timestamp is greater than or equal to 16777215(hexadecimal 0xFFFFFF), this field MUST be

16777215, indicating the presence ofthe Extended Timestamp field to encode the full 32 bit timestamp. Otherwise, this field SHOULD be the entiretimestamp.

5.3.1.2.2. Type 1

Type 1 chunk headers are 7 byteslong. The message stream ID is notincluded; this chunk takes the same stream ID as the preceding chunk. Streamswith variable-sized messages (for example, many video

formats) SHOULD use this format forthe first chunk of each new message after the first.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 34 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| timestamp delta |messagelength |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| messagelength (cont) |message type id|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Message Header - Type 1

5.3.1.2.3. Type 2

Type 2 chunk headers are 3 byteslong. Neither the stream ID nor themessage length is included; this chunk has the same stream ID and messagelength as the preceding chunk. Streamswith constant-sized messages (for example, some audio and data formats) SHOULDuse this format for the first chunk of each message after the first.

0			1			2
0 1	2 3 4	5 6 7	8 9 0 1	2 3 4 5	6 7 8	9 0 1 2 3

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| timestamp delta |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Message Header - Type 2

5.3.1.2.4. Type 3

Type 3 chunks have no messageheader. The stream ID, message lengthand timestamp delta fields are not present; chunks of this type take valuesfrom the preceding chunk for the same Chunk Stream ID. When a single message is split into chunks, all chunks of amessage except the first one SHOULD use this type. Refer to Example 2

(Section 5.3.2.2). A stream consisting of messages of exactlythe same size, stream ID and spacing in time SHOULD use this type for allchunks after a chunk of Type 2. Referto Example 1

(Section 5.3.2.1). If the delta between the first message andthe second message is same as the timestamp of the first message, then a chunkof Type 3 could immediately follow the chunk of Type 0 as there is no need fora chunk of Type 2 to register the delta. Ifa Type 3 chunk follows a Type 0 chunk, then the timestamp delta for this Type

3chunk is the same as the timestamp of the Type 0 chunk.

5.3.1.2.5. Common Header Fields

Descriptionof each field in the chunk message header:

timestampdelta (3 bytes): For a type-1 ortype-2 chunk, the difference between the previous chunk’s timestamp and thecurrent chunk’s timestamp is sent here. Ifthe delta is greater than or equal to 16777215 (hexadecimal 0xFFFFFF), thisfield MUST be

16777215, indicating the presence of the Extended Timestampfield to encode the full 32 bit delta. Otherwise,this field SHOULD be the actual delta.

messagelength (3 bytes): For a type-0 ortype-1 chunk, the length of the message is sent here. Note that this is generally not the same as the length of thechunk payload. The chunk payloadlength is the maximum chunk size for all but the last chunk, and the remainder(which may be the entire length, for small messages) for the last chunk.

messagetype id (1 byte): For a type-0 ortype-1 chunk, type of the message is sent here.

messagestream id (4 bytes): For a type-0chunk, the message stream ID is stored. Message stream ID is stored in little-endian format. Typically, all messages in the samechunk stream will come from the same message stream. While it is possible to multiplex separatemessage streams into the same chunk stream, this defeats the benefits of theheader compression. However, if onemessage stream is closed and another one subsequently opened, there is noreason an existing chunk stream cannot be reused by sending a new type-0 chunk.

5.3.1.3. Extended Timestamp

The Extended Timestamp field is usedto encode timestamps or timestamp deltas that are greater than 16777215(0xFFFFFF); that is, for timestamps or timestamp deltas that don’t fit in the24 bit fields of Type 0, 1, or 2 chunks. Thisfield encodes the complete

32-bit timestamp or timestamp delta. The presence of this field is indicated bysetting the timestamp field of a Type 0 chunk, or the timestamp delta field ofa Type 1 or 2 chunk, to 16777215 (0xFFFFFF). This field is present in Type 3chunks when the most recent Type 0,

1, or 2 chunk for the same chunkstream ID indicated the presence of an extended timestamp field.

5.3.2. Examples

5.3.2.1. Example 1

This example shows a simple streamof audio messages. This exampledemonstrates the redundancy of information.

+---------+-----------------+-----------------+-----------------+

+---------+-----------------+-----------------+-------+---------+

| Msg # 1 | 12345 | 8 | 1000| 32 |

+---------+-----------------+-----------------+-------+---------+

| Msg # 2 | 12345 | 8 | 1020| 32 |

+---------+-----------------+-----------------+-------+---------+

| Msg # 3 | 12345 | 8 | 1040| 32 |

+---------+-----------------+-----------------+-------+---------+

| Msg # 4 | 12345 | 8 | 1060| 32 |

+---------+-----------------+-----------------+-------+---------+

Sample audio messages to be made into chunks

The next table shows chunks producedin this stream. From message 3onward, data transmission is optimized. Thereis only 1 byte of overhead per message beyond this point.

+--------+---------+-----+------------+----------+------------+

+--------+---------+-----+------------+-----------+------------+

\|Chunk#1	\|	3	\|	0	\|	delta: 1000\|		32	\|	44	\|
\|	\|		\|		\|	length: 32,\|			\|		\|
\|	\|		\|		\|	type: 8,	\|		\|		\|
\|	\|		\|		\|	stream ID:	\|		\|		\|
\|	\|		\|		\|	12345 (11	\|		\|		\|
\|	\|		\|		\|	bytes)	\|		\|		\|
+--------+---------+-----+------------+-----------+------------+
\|Chunk#2 \|		3	\|	2	\| 20 (3		\|	32	\|	36	\|
\| \|			\|		\| bytes)		\|		\|		\|
+--------+---------+-----+----+-------+-----------+------------+
\|Chunk#3 \|		3	\|	3	\| none (0		\|	32	\|	33	\|
\| \|			\|		\| bytes)		\|		\|		\|
+--------+---------+-----+------------+-----------+------------+
\|Chunk#4 \|		3	\|	3	\| none (0		\|	32	\|	33	\|
\| \|			\|		\| bytes)		\|		\|		\|
+--------+---------+-----+------------+-----------+------------+

Formatof each of the chunks of audio messages

5.3.2.2. Example 2

This example illustrates a messagethat is too long to fit in a 128- byte chunk and is broken into several chunks.

+-----------+-------------------+-----------------+-----------------+

+-----------+-------------------+-----------------+-----------------+

| Msg # 1 | 12346 | 9 (video) | 1000 | 307 |

+-----------+-------------------+-----------------+-----------------+

Sample Message to be broken to chunks

Hereare the chunks that are produced:

+-------+------+-----+-------------+-----------+------------+

+-------+------+-----+-------------+-----------+------------+

|Chunk#1| 4 | 0 |delta: 1000 | 128 | 140 |

\|	\|		\|		\|	length: 307	\|		\|		\|
\|	\|		\|		\|	type: 9,	\|		\|		\|
\|	\|		\|		\|	stream ID:	\|		\|		\|
\|	\|		\|		\|	12346 (11	\|		\|		\|
\|	\|		\|		\|	bytes)	\|		\|		\|
+-------+------+-----+-------------+-----------+------------+
\|Chunk#2\|		4	\|	3	\| none (0		\|	128	\|	129	\|
\| \|			\|		\| bytes)		\|		\|		\|
+-------+------+-----+-------------+-----------+------------+
\|Chunk#3\|		4	\|	3	\| none (0		\|	51	\|	52	\|
\| \|			\|		\| bytes)		\|		\|		\|
+-------+------+-----+-------------+-----------+------------+

Format of each of the chunks

The header data of chunk 1 specifiesthat the overall message is 307 bytes.

Notice from the two examples, thatchunk type 3 can be used in two different ways. The first is to specify the continuation of a message. The second is to specify the beginning of anew message whose header can be derived from the existing state data.

5.4. Protocol Control Messages

RTMPChunk 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 MUSThave message stream ID 0 (known as the control stream) and be sent in chunkstream ID 2. Protocol controlmessages take effect as soon as they are received; their

timestampsare ignored.

5.4.1. Set Chunk Size (1)

Protocol control message 1, SetChunk Size, is used to notify the peer of a new maximum chunk size.

The maximum chunk size defaults to128 bytes, but the client or the server can change this value, and updates itspeer using this message. For example,suppose a client wants to send 131 bytes of audio data and the chunk size is128. In this case, the client cansend this message to the server to notify it that the chunk size is now 131bytes. The client can then send theaudio data in a single chunk.

The maximum chunk size SHOULD be atleast 128 bytes, and MUST be at least 1 byte. The maximum chunk size is maintained independently for each direction.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 34 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0| chunk size (31 bits) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Payload for the ‘Set Chunk Size’ protocol message

0:This bit MUST be zero.

chunk size(31 bits): This field holds the newmaximum chunk size, in bytes, which will be used for all of the sender’ssubsequent chunks until further notice. Validsizes are 1 to 2147483647 (0x7FFFFFFF) inclusive; however, all sizes greaterthan 16777215 (0xFFFFFF) are equivalent since no chunk is larger than onemessage, and no message is larger than 16777215 bytes.

5.4.2. Abort Message (2)

Protocol control message 2, AbortMessage, is used to notify the peer if it is waiting for chunks to complete amessage, then to discard

the partially received message overa chunk stream. The peer receives thechunk stream ID as this protocol message’s payload. An application may send this message when closing in order toindicate that further processing of the messages is not required.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 34 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| chunk stream id (32bits) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Payload for the ‘Abort Message’ protocol message

chunkstream ID (32 bits): This field holdsthe chunk stream ID, whose current message is to be discarded.

5.4.3. Acknowledgement (3)

The client or the server MUST sendan acknowledgment to the peer after receiving bytes equal to the window size. The window size is the maximum number ofbytes that the sender sends without receiving acknowledgment from the receiver. This message specifies the sequencenumber, 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) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Payload for the ‘Acknowledgement’protocol message sequence number (32 bits): Thisfield holds the number of bytes

received so far.

5.4.4. Window Acknowledgement Size (5)

The client or the server sends thismessage to inform the peer of the window size to use between sendingacknowledgments. The sender expectsacknowledgment from its peer after the sender sends window size bytes. The receiving peer MUST send anAcknowledgement

(Section 5.4.3) after receiving theindicated number of bytes since the last Acknowledgement was sent, or from thebeginning of the session if no Acknowledgement has yet been sent.

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Payload for the ‘Window Acknowledgement Size’ protocolmessage

5.4.5. Set Peer Bandwidth (6)

The client or the server sends thismessage to limit the output bandwidth of its peer. The peer receiving this message limits its output bandwidth bylimiting the amount of sent but unacknowledged data to the window sizeindicated in this message. The peerreceiving this message SHOULD respond with a Window Acknowledgement Sizemessage if the window size is different from the last one sent to the sender ofthis message.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 34 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Acknowledgement Window size |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Limit Type |

+-+-+-+-+-+-+-+-+

Payload for the ‘Set Peer Bandwidth’ protocol message

TheLimit Type is one of the following values:

0 -Hard: The peer SHOULD limit its outputbandwidth to the indicated window size.

1 -Soft: The peer SHOULD limit its outputbandwidth to the the window indicated in this message or the limit already ineffect, whichever is smaller.

2 -Dynamic: If the previous Limit Type wasHard, treat this message as though it was marked Hard, otherwise ignore thismessage.

6. RTMP Message Formats

The section specifies the format ofRTMP messages that are transferred between entities on a network using a lowerlevel transport layer, such as RTMP Chunk Stream.

While RTMP was designed to work withthe RTMP Chunk Stream, it can send the messages using any other transportprotocol. RTMP Chunk Stream and RTMPtogether are suitable for a wide variety of audio- video applications, fromone-to-one and one-to-many live broadcasting to video-on-demand services tointeractive conferencing applications.

6.1. RTMP Message Format

The server and the client send RTMPmessages over the network to communicate with each other. The messages could include audio, video,data, or any other messages.

TheRTMP message has two parts, a header and its payload.

6.1.1. Message Header

Themessage header contains the following:

MessageType: One byte field to represent themessage type. A range of type IDs(1-6) are reserved for protocol control messages.

Length: Three-byte field that represents the size ofthe payload in bytes. It is set inbig-endian format.

Timestamp: Four-byte field that contains a timestamp ofthe message.

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

MessageStream Id: Three-byte field thatidentifies the stream of the message. These bytes are set in big-endian format.

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

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

\| Message Type	\|	Payload length		\|
\| (1 byte)	\|	(3 bytes)		\|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\|		Timestamp		\|
\|		(4 bytes)		\|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\|	Stream ID		\|
\|	(3 bytes)		\|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message Header

6.1.2. Message Payload

The other part of the message is thepayload, which is the actual data contained in the message. For example, it could be some audiosamples or compressed video data. Thepayload format and interpretation are beyond the scope of this document.

6.2. User Control Messages (4)

RTMP uses message type ID 4 for UserControl messages. These messagescontain information used by the RTMP streaming layer. Protocol messages withIDs 1, 2, 3, 5, and 6 are used by the RTMP Chunk Stream protocol (Section 5.4).

User Control messages SHOULD usemessage stream ID 0 (known as the control stream) and, when sent over RTMPChunk Stream, be sent on chunk stream ID 2. UserControl messages are effective at the point they are received in the stream;their timestamps are ignored.

The client or the server sends thismessage to notify the peer about the user control events. This message carries Event type and Eventdata.

+------------------------------+-------------------------

| Event Type(16 bits) | Event Data

+------------------------------+-------------------------

Payload for the ‘User Control’ protocol message

The first 2 bytes of the messagedata are used to identify the Event type. Event type is followed by Event data.The size of Event Data field is variable. However, in cases where the message has to pass through the RTMPChunk Stream layer, the maximum chunk size

(Section 5.4.1) SHOULD be largeenough to allow these messages to fit in a single chunk.

EventTypes are and their Event Data formats are enumerated in

Section 7.1.7.

7. RTMP Command Messages

This section describes the different types of messages andcommands that are exchanged between the server and the client to communicatewith each other.

The different types of messages thatare exchanged between the server and the client include audio messages forsending the audio data, video messages for sending video data, data messagesfor sending any user data, shared object messages, and command messages. Shared object messages provide a generalpurpose way to manage distributed data among multiple clients and a server. Command messages carry the AMF encodedcommands between the client and the server. Aclient or

a server can request RemoteProcedure Calls (RPC) over streams that are communicated using the commandmessages to the peer.

7.1. Types of Messages

The server and the client sendmessages over the network to communicate with each other. The messages can be of any type whichincludes audio messages, video messages, command messages, shared objectmessages, data messages, and user control messages.

7.1.1. Command Message (20, 17)

Commandmessages carry the AMF-encoded commands between the client

and the server. These messages have been assigned message type value

of 20 for AMF0 encoding and message type value of 17 forAMF3

encoding. Thesemessages are sent to perform some operations like

connect, createStream, publish, play, pause on the peer. Command

messages like onstatus, result etc. are used to informthe sender

about the status of the requested commands. A command message

consists of command name, transaction ID, and commandobject that

contains related parameters. A client or a server can request Remote

Procedure Calls (RPC) over streams that are communicatedusing the

command messages to the peer.

7.1.2. Data Message (18, 15)

The client or the server sends thismessage to send Metadata or any user data to the peer. Metadata includes details about the data(audio, video etc.) likecreation time, duration, theme and so on. These messages have been assigned message type value of 18 for AMF0 andmessage type value of 15 for AMF3.

7.1.3. Shared Object Message (19, 16)

A shared object is a Flash object (acollection of name value pairs) that are in synchronization across multipleclients, instances, and so on. Themessage types 19 for AMF0 and 16 for AMF3 are reserved for shared objectevents. Each message can containmultiple events.

+------+------+-------+-----+-----+------+-----++-----+------+-----+

+------+------+-------+-----+-----+------+-----++-----+------+-----+

| |

|<- - - - - - - - - - - - - - - - - - - - - - - - - -- - - >|

| AMFShared Object Message body |

The shared object message format

Thefollowing event types are supported:

+---------------+--------------------------------------------------+

| Event | Description |

+---------------+--------------------------------------------------+

| Use(=1) |The client sends this event to inform the server |

| |about the creation of a named shared object. |

+---------------+--------------------------------------------------+

| Release(=2) |The client sends this event to the server when |

| |the shared object is deleted on the client side. |

+---------------+--------------------------------------------------+

| Request Change| The client sends this event to requestthat the |

| (=3) |change the value associated with a named |

| |parameter of the shared object. |

+---------------+--------------------------------------------------+

| Change (=4) |The server sends this event to notify all |

| |clients, except the client originating the |

| |request, of a change in the value of a named |

| |parameter. |

+---------------+--------------------------------------------------+

| Success (=5) |The server sends this event to the requesting |

| |client in response to RequestChange event if the |

| |request is accepted. |

+---------------+--------------------------------------------------+

| SendMessage |The client sends this event to the server to |

| (=6) |broadcast a message. On receiving this event, |

| |the server broadcasts a message to all the |

| |clients, including the sender. |

+---------------+--------------------------------------------------+

| Status (=7) |The server sends this event to notify clients |

| |about error conditions. |

+---------------+--------------------------------------------------+

| Clear (=8) |The server sends this event to the client to |

| |clear a shared object. The server also sends |

| |this event in response to Use event that the |

| |client sends on connect. |

+---------------+--------------------------------------------------+

| Remove (=9) |The server sends this event to have the client |

| |delete a slot. |

+---------------+--------------------------------------------------+

| Request Remove| The client sends this event to have theclient |

| (=10) |delete a slot. |

+---------------+--------------------------------------------------+

| Use Success |The server sends this event to the client on a |

| (=11) |successful connection. |

+---------------+--------------------------------------------------+

7.1.4. Audio Message (8)

The client or the server sends thismessage to send audio data to the peer. The message type value of 8 is reserved for audio messages.

7.1.5. Video Message (9)

The client or the server sends thismessage to send video data to the peer. The message type value of 9 is reserved for video messages.

7.1.6. Aggregate Message (22)

An aggregate message is a singlemessage that contains a series of RTMP sub-messages using the format describedin Section 6.1. Message type 22 isused for aggregate messages.

+---------+-------------------------+

| Header | Aggregate Message body |

+---------+-------------------------+

The Aggregate Message format

+--------+-------+---------+--------+-------+---------+ - -- -

+--------+-------+---------+--------+-------+---------+- - - -

The Aggregate Message body format

The message stream ID of theaggregate message overrides the message stream IDs of the sub-messages insidethe aggregate.

The difference between thetimestamps of the aggregate message and the first sub-message is the offsetused to renormalize the timestamps of the sub-messages to the stream timescale. The offset is added to each sub-message’stimestamp to arrive at the normalized stream time. The timestamp of the first sub-message SHOULDbe the same as the timestamp of the aggregate message, so the offset SHOULD bezero.

The back pointer contains the sizeof the previous message including its header. It is included to match the format of FLV file and is used for backwardseek.

Usingaggregate messages has several performance benefits:

o The chunk stream can send at most a singlecomplete message within a chunk. Therefore, increasing the chunk size and using the

aggregatemessage reduces the number of chunks sent.

o The sub-messages can be stored contiguously inmemory. It is more efficient whenmaking system calls to send the data on the

network.

7.1.7. User Control Message Events

The client or the server sends thismessage to notify the peer about the user control events. For information about the message format,see Section 6.2.

Thefollowing user control event types are supported:

+---------------+--------------------------------------------------+

| Event | Description |

+---------------+--------------------------------------------------+

|Stream Begin |The server sends this event to notify the client |

| (=0) | that a stream has become functional andcan 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 |

| | 4bytes of event data represent the ID of the |

| |stream on which playback has ended. |

+---------------+--------------------------------------------------+

| StreamDry | The server sends this event to notify theclient |

| (=2) | that there is no more data on thestream. 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. |

+---------------+--------------------------------------------------+

\|	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	\|

| SetBuffer | The client sends this event to inform theserver |

| |milliseconds. |

+---------------+--------------------------------------------------+

| StreamIs | The server sends this event to notifythe client |

| Recorded (=4) | that thestream is a recorded stream. The |

| | 4 bytes event data representthe 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 thelocal server time |

| | when the server dispatched thecommand. The |

| | client responds withPingResponse on receiving |

| | MsgPingRequest. |

+---------------+--------------------------------------------------+

| PingResponse | The client sends this event tothe server in |

| (=7) | response to the ping request. The event data is |

| | a 4-byte timestamp, which wasreceived with the |

| | PingRequest request. |

+---------------+--------------------------------------------------+

7.2. Types of Commands

The client and the server exchangecommands which are AMF encoded. The sender sends a command message thatconsists of command name, transaction ID, and command object that containsrelated 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 andsends back the response with the same transaction ID. The response string is either _result, _error,

or a method name, for example, verifyClient orcontactExternalServer.

A command string of _result or_error signals a response. Thetransaction ID indicates the outstanding command to which the responserefers. It is identical to the tag inIMAP and many other protocols. Themethod name in the command string indicates that the sender is trying to run amethod on the receiver end.

The following class objects are used to send variouscommands: NetConnection An object thatis a higher-level representation of

connection between the server and the client.

NetStream An object that represents the channel overwhich audio streams, video streams and other related data are sent. We also send commands like play , pauseetc. which control the flow of the data.

7.2.1. NetConnection Commands

The NetConnection manages a two-wayconnection between a client application and the server. In addition, it provides support for asynchronous remote methodcalls.

Thefollowing commands can be sent on the NetConnection :

o connect o call

o close

o createStream

7.2.1.1. connect

The client sends the connect commandto the server to request connection to a server application instance.

Thecommand structure from the client to the server is as follows:

+----------------+---------+---------------------------------------+

| Field Name | Type | Description |

+---------------+---------+---------------------------------------+

| Command Name |String | Name of the command. Set to"connect".|

+----------------+---------+---------------------------------------+

| Transaction ID | Number | Always set to 1. |

\| Command Object \| Object		\| Command information object which has	\|
\| \|		\| the name-value pairs.	\|
+----------------+---------+---------------------------------------+
\| Optional User	\| Object	\| Any optional information	\|
\| Arguments	\|	\|	\|
+----------------+---------+---------------------------------------+

+----------------+---------+---------------------------------------+

Following is the description of the name-value pairs used inCommand

Object of the connectcommand.

+-----------+--------+-----------------------------+----------------+

+-----------+--------+-----------------------------+----------------+

+-----------+--------+-----------------------------+----------------+

+-----------+--------+-----------------------------+----------------+

+-----------+--------+-----------------------------+----------------+

+-----------+--------+-----------------------------+----------------+

+-----------+--------+-----------------------------+----------------+

| | | the client supports. | _MP3 |

+-----------+--------+-----------------------------+----------------+

+-----------+--------+-----------------------------+----------------+

+-----------+--------+-----------------------------+----------------+

+-----------+--------+-----------------------------+----------------+

+-----------+--------+-----------------------------+----------------+

Flag values for the audioCodecs property:

+----------------------+----------------------------+--------------+

| Codec Flag | Usage | Value |

+----------------------+----------------------------+--------------+

| SUPPORT_SND_NONE | Raw sound, no compression | 0x0001 |

+----------------------+----------------------------+--------------+

| SUPPORT_SND_ADPCM | ADPCM compression | 0x0002 |

+----------------------+----------------------------+--------------+

| SUPPORT_SND_MP3 | mp3 compression | 0x0004 |

+----------------------+----------------------------+--------------+

| SUPPORT_SND_INTEL | Not used | 0x0008 |

+----------------------+----------------------------+--------------+

| SUPPORT_SND_UNUSED | Not used | 0x0010 |

+----------------------+----------------------------+--------------+

| SUPPORT_SND_NELLY8 | NellyMoser at 8-kHz | 0x0020 |

| | compression | |

+----------------------+----------------------------+--------------+

| SUPPORT_SND_NELLY | NellyMosercompression | 0x0040 |

| | (5, 11, 22, and 44kHz) | |

+----------------------+----------------------------+--------------+

| SUPPORT_SND_G711A | G711A soundcompression | 0x0080 |

| | (Flash Media Serveronly) | |

+----------------------+----------------------------+--------------+

| SUPPORT_SND_G711U | G711U soundcompression | 0x0100 |

| | (Flash Media Serveronly) | |

+----------------------+----------------------------+--------------+

| SUPPORT_SND_NELLY16 | NellyMouser at16-kHz | 0x0200 |

| | compression | |

+----------------------+----------------------------+--------------+

| SUPPORT_SND_AAC | Advanced audio coding | 0x0400 |

| | (AAC) codec | |

+----------------------+----------------------------+--------------+

| SUPPORT_SND_SPEEX | Speex Audio | 0x0800 |

\| SUPPORT_SND_ALL	\| All RTMP-supported audio	\|	0x0FFF	\|
\|	\| codecs	\|		\|
+----------------------+----------------------------+--------------+

+----------------------+----------------------------+--------------+

Flag values for the videoCodecs Property:

+----------------------+----------------------------+--------------+

| Codec Flag | Usage | Value |

+----------------------+----------------------------+--------------+

| SUPPORT_VID_UNUSED | Obsolete value | 0x0001 |

+----------------------+----------------------------+--------------+

| SUPPORT_VID_JPEG | Obsolete value | 0x0002 |

+----------------------+----------------------------+--------------+

| SUPPORT_VID_SORENSON |Sorenson Flash video | 0x0004 |

+----------------------+----------------------------+--------------+

| SUPPORT_VID_HOMEBREW | V1screen sharing | 0x0008 |

+----------------------+----------------------------+--------------+

| SUPPORT_VID_VP6 (On2)| On2video (Flash 8+) | 0x0010 |

+----------------------+----------------------------+--------------+

| SUPPORT_VID_VP6ALPHA | On2video with alpha | 0x0020 |

| (On2 with alpha | channel | |

| channel) | | |

+----------------------+----------------------------+--------------+

| SUPPORT_VID_HOMEBREWV|Screen sharing version 2 | 0x0040 |

| (screensharing v2) |(Flash 8+) | |

+----------------------+----------------------------+--------------+

| SUPPORT_VID_H264 | H264 video | 0x0080 |

+----------------------+----------------------------+--------------+

| SUPPORT_VID_ALL | All RTMP-supported video | 0x00FF |

| | codecs | |

+----------------------+----------------------------+--------------+

Flag values for the videoFunction property:

+----------------------+----------------------------+--------------+

| Function Flag | Usage | Value |

+----------------------+----------------------------+--------------+

| SUPPORT_VID_CLIENT |Indicates that the client | 1 |

| _SEEK | can perform frame-accurate | |

| | seeks. | |

+----------------------+----------------------------+--------------+

Values for the object encoding property:

+----------------------+----------------------------+--------------+

| EncodingType | Usage | Value |

+----------------------+----------------------------+--------------+

| AMF0 | AMF0 object encoding | 0 |

| | supported by Flash 6 and | |

| | later | |

+----------------------+----------------------------+--------------+

| AMF3 | AMF3 encoding from | 3 |

| | Flash 9 (AS3) | |

+----------------------+----------------------------+--------------+

The command structure from server to client is as follows:

+--------------+----------+----------------------------------------+

| Field Name | Type | Description |

+--------------+----------+----------------------------------------+

| Command Name | String | _result or _error;indicates whether |

| | | the response is result or error. |

Transaction

Number

Transaction

for

connect

responses

+--------------+----------+----------------------------------------+

Properties

Object

Name-value pairs that describe

the

properties(fmsver etc.) of the

connection.

+--------------+----------+----------------------------------------+

Information

Object

Name-value pairs that describe the

response from|the server. ’code’,

’level’, ’description’ are names of

few|

among such information.

+--------------+----------+----------------------------------------+

+--------------+			+-------------+
\| 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)

Message flow in the

connect command

Themessage flow during the execution of the command is:

1. Client sends the connect command to the serverto request to connect with the server application instance.

2. After receiving the connect command, theserver sends the protocol message ’Window Acknowledgement Size’ to the client.The server also connects to the application mentioned in the connect command.

3. The server sends the protocol message ’SetPeer Bandwidth’ to the client.

4. The client sends the protocol message ’WindowAcknowledgement Size’ to the server after processing the protocol message ’SetPeer Bandwidth’.

5. The server sends an another protocol messageof type User Control

Message(StreamBegin) to the client.

6. The server sends the result command messageinforming the client of the connection status (success/fail). The command specifies the transaction ID(always equal to 1 for the connect command). The message also specifies theproperties, such as Flash Media

Server version (string). In addition it specificies otherconnection response related information like level (string), code (string),description (string), objectencoding (number), etc.

7.2.1.2. Call

The call method of the NetConnectionobject runs remote procedure calls (RPC) at the receiving end. The called RPC name is passed as a parameterto the call command.

Thecommand structure from the sender to the receiver is as follows:

+--------------+----------+----------------------------------------+

|Field Name | Type | Description |

+--------------+----------+----------------------------------------+

| Procedure | String |Name of the remote procedure that is |

| Name | | called. |

+--------------+----------+----------------------------------------+

| Transaction | Number |If a response is expected we give a |

| | | transaction Id. Else wepass a value of|

| ID | | 0 |

+--------------+----------+----------------------------------------+

| Command | Object |If there exists any command info this |

| Object | | is set, else this is setto null type. |

+--------------+----------+----------------------------------------+

| Optional | Object | Any optional arguments to be provided |

| Arguments | | |

+--------------+----------+----------------------------------------+

The command structure of the response is as follows:

+--------------+----------+----------------------------------------+

| Field Name | Type | Description |

+--------------+----------+----------------------------------------+

| Command Name | String | Name of thecommand. |

| | | |

\| Transaction	\|	Number	\| ID of the command, to which the \|
\| ID	\|		\| response belongs.
+--------------+----------+----------------------------------------+
\| Command	\|	Object	\| If there exists any command info this \|
\| Object	\|		\| is set, else this is set to null type. \|
+--------------+----------+----------------------------------------+
\| Response	\| Object		\| Response from the method that was	\|
\|	\|		\| called.	\|
+------------------------------------------------------------------+

+--------------+----------+----------------------------------------+

7.2.1.3. createStream

The client sends this command to theserver to create a logical channel for message communication The publishing ofaudio, video, and metadata is carried out over stream channel created using thecreateStream command.

NetConnection is the defaultcommunication channel, which has a stream ID 0. Protocol and a few command messages, including createStream, use thedefault communication channel.

Thecommand structure from the client to the server is as follows:

+--------------+----------+----------------------------------------+

| Field Name | Type | Description |

+--------------+----------+----------------------------------------+

| Command Name | String | Name of the command.Set to |

| | |"createStream". |

+--------------+----------+----------------------------------------+

| Transaction | Number |Transaction ID of the command. |

| ID | | |

+--------------+----------+----------------------------------------+

| Command | Object |If there exists any command info this |

| Object | | is set, else this is setto null type. |

+--------------+----------+----------------------------------------+

The command structure from server to client is as follows:

+--------------+----------+----------------------------------------+

| Field Name | Type | Description |

\| Command Name \|		String	\| _result or _error; indicates whether	\|
\| \|			\| the response is result or error.	\|
+--------------+----------+----------------------------------------+
\| Transaction	\|	Number	\| ID of the command that response belongs\|
\| ID	\|		\| to. \|
+--------------+----------+----------------------------------------+
\| Command	\|	Object	\| If there exists any command info this \|
\| Object	\|		\| is set, else this is set to null type. \|
+--------------+----------+----------------------------------------+
\| Stream	\|	Number	\| The return value is either a stream ID \|
\| ID	\|		\| or an error information object. \|
+--------------+----------+----------------------------------------+

+--------------+----------+----------------------------------------+

7.2.2. NetStreamCommands

The NetStream defines the channelthrough which the streaming audio, video, and data messages can flow over theNetConnection that connects the client to the server. A NetConnection object can support multipleNetStreams for multiple data streams.

The following commands can be senton the NetStream by the client to the server:

o play

o play2

o deleteStream o closeStream

o receiveAudio o receiveVideo o publish

o seek

o pause

Theserver sends NetStream status updates to the client using the

"onStatus" command:

+--------------+----------+----------------------------------------+

| Field Name | Type | Description |

+--------------+----------+----------------------------------------+

| Command Name | String |The command name "onStatus". |

+--------------+----------+----------------------------------------+

| Transaction | Number | Transaction ID set to 0. |

| ID | | |

+--------------+----------+----------------------------------------+

| Command | Null | There is no command object for |

| Object | | onStatus messages. |

+--------------+----------+----------------------------------------+

| Info Object | Object | An AMF object having at leastthe |

| | | following three properties:"level" |

| | | (String): the level for this message, |

| | | one of "warning","status", or "error";|

| | | "code" (String): themessage code, for |

| | | example"NetStream.Play.Start"; and |

| | | "description" (String): ahuman- |

| | | readable description of themessage. |

| | | The Info object MAY containother |

| | | properties as appropriate to thecode. |

+--------------+----------+----------------------------------------+

Format of NetStream status message commands.

7.2.2.1. play

Theclient sends this command to the server to play a stream. A

playlist can also be created using this command multipletimes.

Ifyou want to create a dynamic playlist that switches among

different live or recordedstreams, call play more than once and pass

false for reset each time. Conversely, if you want to play the

specified stream immediately, clearing any other streamsthat are

queued for play, pass true for reset.

Thecommand structure from the client to the server is as follows:

+--------------+----------+-----------------------------------------+

| Field Name | Type | Description |

+--------------+----------+-----------------------------------------+

| Command Name | String |Name of the command. Set to "play". |

\| Transaction	\|	Number	\| Transaction ID set to 0.	\|
\| ID	\|		\|	\|
+--------------+----------+-----------------------------------------+
\| Command	\|	Null	\| Command information does not exist.	\|
\| Object	\|		\| Set to null type.	\|

+--------------+----------+-----------------------------------------+

\|	Stream	Name	\|	String	\|	Name of the stream to play.			\|
\|			\|		\|	To play video (FLV) files, specify		the	\|
\|			\|		\|	name of the stream without a file			\|
\|			\|		\|	extension (for example, "sample").		To	\|
\|			\|		\|	play back MP3 or ID3 tags, you must			\|
\|			\|		\|	precede the stream name with mp3:			\|
\|			\|		\|	(for example, "mp3:sample". To play			\|
\|			\|		\|	H.264/AAC files, you must precede the			\|
\|			\|		\|	stream name with mp4: and specify the			\|
\|			\|		\|	file	extension. For example, to play the\|
\|			\|		\|	file	sample.m4v,specify "mp4:sample.m4v"\|
\|			\|		\|		\|
+--------------+----------+-----------------------------------------+
\|	Start		\|	Number	\|	An optional parameter that specifies \|
\|			\|		\|	the start time in seconds. The default \|
\|			\|		\|	value is -2, which means the subscriber \|
\|			\|		\|	first tries to play the live stream \|
\|			\|		\|	specified in the Stream Name field. If a\|
\|			\|		\|	live stream of that name is not found,it\|
\|			\|		\|	plays the recorded stream of the same \|
\|			\|		\|	name. If there is no recorded stream \|
\|			\|		\|	with that name, the subscriber waits for\|
\|			\|		\|	a new live stream with that name and \|
\|			\|		\|	plays it when available. If you pass -1 \|
\|			\|		\|	in the Start field, only the live stream\|
\|			\|		\|	specified in the Stream Name field is \|
\|			\|		\|	played. If you pass 0 or a positive \|
\|			\|		\|	number in the Start field, a recorded \|
\|			\|		\|	stream specified in the Stream Name \|
\|			\|		\|	field is played beginning from the time \|
\|			\|		\|	specified in the Start field. If no \|
\|			\|		\|	recorded stream is found, the next item \|
\|			\|		\|	in the playlist is played. \|
+--------------+----------+-----------------------------------------+
\|	Duration		\|	Number	\|	An optional parameter that specifies the\|
\|			\|		\|	duration of playback in seconds. The \|
\|			\|		\|	default value is -1. The -1 value means \|
\|			\|		\|	a live stream is played until it is no \|
\|			\|		\|	longer available or a recorded stream is\|
\|			\|		\|	played until it ends. If you pass 0, it \|
\|			\|		\|	plays the single frame since the time \|
\|			\|		\|	specified in the Start field from the \|
\|			\|		\|	beginning of a recorded stream. It is \|
\|			\|		\|	assumed that the value specified in \|
\|			\|		\|	the Start field is equal to or greater \|
\|			\|		\|	than 0. If you pass a positive number, \|
\|			\|		\|	it plays a live stream for \|

+--------------+----------+-----------------------------------------+

\|	\|	\|	the time period specified in the	\|
\|	\|	\|	Duration field. After that it becomes	\|
\|	\|	\|	available or plays a recorded stream	\|
\|	\|	\|	for the time specified in the Duration	\|
\|	\|	\|	field. (If a stream ends before the	\|
\|	\|	\|	time specified in the Duration field,	\|
\|	\|	\|	playback ends when the stream ends.)	\|
\|	\|	\|	If you pass a negative number other	\|
\|	\|	\|	than -1 in the Duration field, it	\|
\|	\|	\|	interprets the value as if it were -1.	\|

+--------------+----------+-----------------------------------------+

| Reset |Boolean | An optional Boolean valueor number |

| | | that specifies whetherto flush any |

| | | previous playlist. |

+--------------+----------+-----------------------------------------+

+-------------+ +----------+

+------+------+ | +-----+----+

| Handshaking and Application |

| connect done |

| | |

---+---- |------CommandMessage(createStream) ----->|

Create| | |

Stream| | |

---+---- |<----------Command Message --------------|

| (_result- createStream response) |

| |

---+---- |------ CommandMessage (play) ----------->|

| | |

| |<------------ SetChunkSize--------------|

| | |

| |<----User Control (StreamIsRecorded) ----|

Play | | |

| |<----UserControl (StreamBegin) ----------|

| | |

| |<--Command Message(onStatus-play reset) --|

| | |

| |<--Command Message(onStatus-play start) --|

| | |

| |<-------------Audio Message---------------|

| | |

| |<-------------VideoMessage---------------|

| | | |

Keep receiving audio andvideo stream till finishes

Message flow in the play command

Themessage flow during the execution of the command is:

1. The client sends the play command afterreceiving result of the createStream command as success from the server.

2. On receiving the play command, the serversends a protocol message to set the chunk size.

3. The server sends another protocol message (usercontrol) specifying the event ’StreamIsRecorded’ and the stream ID in thatmessage. The message carries the eventtype in the first 2 bytes and the stream ID in the last 4 bytes.

4. The server sends another protocol message(user control) specifying the event ’StreamBegin’, to indicate beginning of thestreaming to the client.

5. The server sends an onStatus command messagesNetStream.Play.Start & NetStream.Play.Reset if the play command sent by theclient is successful. NetStream.Play.Resetis sent

by the server only if the playcommand sent by the client has set the reset flag. If the stream to be played is not found, theServer sends the onStatus message NetStream.Play.StreamNotFound.

After this, the server sends audioand video data, which the client plays.

7.2.2.2. play2

Unlike the play command, play2 canswitch to a different bit rate stream without changing the timeline of thecontent played. The server maintainsmultiple files for all supported bitrates that the client can request in play2.

Thecommand structure from the client to the server is as follows:

+--------------+----------+----------------------------------------+

| Field Name | Type | Description |

+--------------+----------+----------------------------------------+

| Command Name | String | Name of the command,set to "play2". |

+--------------+----------+----------------------------------------+

\| Transaction		\|	Number	\| Transaction ID set to 0.		\|
\| ID		\|		\|		\|
+--------------+----------+----------------------------------------+
\| Command		\|	Null	\| Command information does not exist.		\|
\| Object		\|		\| Set to null type.		\|
+--------------+----------+----------------------------------------+
\|	Parameters	\|	Object	\|	An AMF encoded object whose properties	\|
\|		\|		\|	are the public properties described	\|
\|		\|		\|	for the flash.net.NetStreamPlayOptions	\|
\|		\|		\|	ActionScript object.	\|
+--------------+----------+----------------------------------------+

The public properties for theNetStreamPlayOptions object are described in the ActionScript 3 LanguageReference [AS3].

The message flow for the command isshown in the following illustration.

+--------------+ +-------------+

+--------+-----+ | +------+------+

| Handshaking and Application |

| connect done |

| | |

---+---- |---- Command Message(createStream) --->|

Create | | |

Stream | | |

---+---- |<---- Command Message (_result) -------|

| |

---+---- |------ Command Message (play) -------->|

| | |

| |<------------ SetChunkSize ------------|

| | |

| |<---UserControl (StreamIsRecorded)----|

Play | | |

| |<-------UserControl (StreamBegin)-----|

| | |

| |<--Command Message(onStatus-playstart)-|

| | |

| |<---------- Audio Message -------------|

| | |

| |<---------- Video Message -------------|

| | |

| |

---+---- |-------- Command Message(play2) ------>|

| | |

| |<-------Audio Message (new rate) -----|

Play2 | | |

| |<-------Video Message (new rate) -----|

| | | |

| Keep receivingaudio and video stream till finishes

Message flow in the play2 command

7.2.2.3. deleteStream

NetStream sends the deleteStreamcommand when the NetStream object is getting destroyed.

Thecommand structure from the client to the server is as follows:

+--------------+----------+----------------------------------------+

| Field Name | Type | Description |

+--------------+----------+----------------------------------------+

| Command Name | String | Name of the command,set to |

| | |"deleteStream". |

+--------------+----------+----------------------------------------+

| Transaction | Number |Transaction ID set to 0. |

| ID | | |

+--------------+----------+----------------------------------------+

| Command | Null | Command information object doesnot |

| Object | | exist. Set to nulltype. |

+--------------+----------+----------------------------------------+

| Stream ID | Number |The ID of the stream that is destroyed |

| | | on the server. |

+--------------+----------+----------------------------------------+

Theserver does not send any response.

7.2.2.4. receiveAudio

NetStream sends the receiveAudiomessage to inform the server whether to send or not to send the audio to theclient.

Thecommand structure from the client to the server is as follows:

+--------------+----------+----------------------------------------+

| Field Name | Type | Description |

+--------------+----------+----------------------------------------+

\| Command Name \|		String	\| Name of the command, set to	\|
\| \|			\| "receiveAudio".	\|
+--------------+----------+----------------------------------------+
\| Transaction	\|	Number	\| Transaction ID set to 0.	\|
\| ID	\|		\|	\|
+--------------+----------+----------------------------------------+
\| Command	\|	Null	\| Command information object does not	\|
\| Object	\|		\| exist. Set to null type.	\|
+--------------+----------+----------------------------------------+
\| Bool Flag	\|	Boolean \| true or false to indicate whether to		\|
\|	\|	\| receive audio or not.		\|
+--------------+----------+----------------------------------------+

The server does not send anyresponse, if the receiveAudio command is sent with the bool flag set as false. If this flag is set to true, serverresponds with status messages NetStream.Seek.Notify and NetStream.Play.Start

7.2.2.5. receiveVideo

NetStream sends the receiveVideomessage to inform the server whether to send the video to the client or not.

Thecommand structure from the client to the server is as follows:

+--------------+----------+----------------------------------------+

| Field Name | Type | Description |

+--------------+----------+----------------------------------------+

\| Command Name \|		String	\| Name of the command, set to	\|
\| \|			\| "receiveVideo".	\|
+--------------+----------+----------------------------------------+
\| Transaction	\|	Number	\| Transaction ID set to 0.	\|
\| ID	\|		\|	\|
+--------------+----------+----------------------------------------+
\| Command	\|	Null	\| Command information object does not	\|
\| Object	\|		\| exist. Set to null type.	\|
+--------------+----------+----------------------------------------+
\| Bool Flag	\|	Boolean \| true or false to indicate whether to		\|
\|	\|	\| receive video or not.		\|
+--------------+----------+----------------------------------------+

The server does not send anyresponse, if the receiveVideo command is sent with the bool flag set as false. If this flag is set to true, serverresponds with status messages NetStream.Seek.Notify and NetStream.Play.Start

7.2.2.6. publish

The client sends the publish command to publish a namedstream to the server. Using this name,any client can play this stream and receive the published audio, video, anddata messages.

Thecommand structure from the client to the server is as follows:

+--------------+----------+----------------------------------------+

| Field Name | Type | Description |

+--------------+----------+----------------------------------------+

| Command Name | String | Name of the command,set to "publish". |

+--------------+----------+----------------------------------------+

\| Transaction		\|	Number	\| Transaction ID set to 0.					\|
\| ID		\|		\|					\|
+--------------+----------+----------------------------------------+
\| Command		\|	Null	\| Command information object does not					\|
\| Object		\|		\| exist. Set to null type.					\|
+--------------+----------+----------------------------------------+
\| Publishing		\|	String	\| Name with which the stream is					\|
\| Name		\|		\| published.					\|
+--------------+----------+----------------------------------------+
\|	Publishing	\|	String	\|	Type of publishing. Set to "live",				\|
\|	Type	\|		\|	"record", or "append".				\|
\|		\|		\|	record: The stream is published and				the\|
\|		\|		\|	data is recorded to a new file.The file\|
\|		\|		\|	is stored on the server in a \|
\|		\|		\|	subdirectory	within the directory that \|
\|		\|		\|	contains the	server application. If the\|
\|		\|		\|	file already	exists, it is overwritten.\|
\|		\|		\|	append: The stream is published and the\|
\|		\|		\|	data is appended to a file. If no file \|
\|		\|		\|	is found, it is		created.			\|
\|		\|		\|	live: Live data		is published	without		\|
\|		\|		\|	recording it in		a file.			\|
+--------------+----------+----------------------------------------+

The server responds with theonStatus command to mark the beginning of publish.

7.2.2.7. seek

The client sends the seek command toseek the offset (in milliseconds) within a media file or playlist.

Thecommand structure from the client to the server is as follows:

+--------------+----------+----------------------------------------+

| Field Name | Type | Description |

+--------------+----------+----------------------------------------+

| Command Name | String | Name of the command,set to "seek". |

+--------------+----------+----------------------------------------+

\| Transaction	\|	Number	\| Transaction ID set to 0.	\|
\| ID	\|		\|	\|
+--------------+----------+----------------------------------------+
\| Command	\|	Null	\| There is no command information object \|
\| Object	\|		\| for this command. Set to null type. \|
+--------------+----------+----------------------------------------+
\| milliSeconds \|		Number	\| Number of milliseconds to seek into	\|
\| \|			\| the playlist.	\|
+--------------+----------+----------------------------------------+

The server sends a status messageNetStream.Seek.Notify when seek is successful. In failure, it returns an _error message.

7.2.2.8. pause

The client sends the pause commandto tell the server to pause or start playing.

Thecommand structure from the client to the server is as follows:

+--------------+----------+----------------------------------------+

| Field Name | Type | Description |

+--------------+----------+----------------------------------------+

| Command Name | String | Name of the command,set to "pause". |

+--------------+----------+----------------------------------------+

| Transaction | Number |There is no transaction ID for this |

| ID | | command. Set to 0. |

+--------------+----------+----------------------------------------+

| Command | Null | Command information object doesnot |

| Object | | exist. Set to null type. |

+--------------+----------+----------------------------------------+

|Pause/Unpause | Boolean| true or false, to indicate pausing or |

| Flag | | resuming play |

+--------------+----------+----------------------------------------+

\|	milliSeconds	\|	Number	\|	Number of milliseconds at which the \|
\|		\|		\|	the stream is paused or play resumed. \|
\|		\|		\|	This is the current stream time at the \|
\|		\|		\|	Client when stream was paused. When the\|
\|		\|		\|	playback is resumed, the server will \|
\|		\|		\|	only send messages with timestamps \|
\|		\|		\|	greater than this value. \|
+--------------+----------+----------------------------------------+

The server sends a status messageNetStream.Pause.Notify when the stream is paused. NetStream.Unpause.Notify is sent when a stream inun-paused. In failure, it returns an_error message.

7.3. Message Exchange Examples

Hereare a few examples to explain message exchange using RTMP.

7.3.1. Publish Recorded Video

This example illustrates how apublisher can publish a stream and then stream the video to the server. Other clients can subscribe to thispublished stream and play the video.

+--------------------+ +-----------+

+----------+---------+ | +-----+-----+

| Handshaking Done |

| | |

---+---- |----- CommandMessage(connect) ----->|

| | |

| |<----- Window Acknowledge Size ------|

Connect | | |

| |<-------Set Peer BandWidth ----------|

| | |

| |------ Window Acknowledge Size ----->|

| | |

| |<------User Control(StreamBegin)-----|

| | |

---+----|<---------Command Message -----------|

| (_result-connect response) |

| |

---+---- |--- CommandMessage(createStream)--->|

Create | | |

Stream | | |

---+---- |<-------Command Message ------------|

| (_result- createStream response) |

| |

---+---- |---- CommandMessage(publish) ------>|

| | |

| |<------User Control(StreamBegin)-----|

| | |

| |-----Data Message (Metadata)-------->|

| | |

Publishing| |------------ Audio Data ------------>|

Content | | |

| |------------ SetChunkSize ---------->|

| | |

| |<----------Command Message ----------|

| | (_result- publish result) |

| | |

| |------------- Video Data ----------->|

| | | |

| Until thestream is complete |

| | |

Messageflow in publishing a video stream

7.3.2. Broadcast a Shared Object Message

This example illustrates themessages that are exchanged during the creation and changing of a sharedobject. It also illustrates theprocess of shared object message broadcasting.

+----------+ +----------+

+-----+----+ | +-----+----+

| Handshaking and Application |

| connect done |

| | |

Create and ---+---- |----Shared Object Event(Use)---->|

connect | | |

Shared Object | | |

---+---- |<---- Shared Object Event---------|

| (UseSuccess,Clear) |

| |

---+---- |------ Shared Object Event ------>|

Shared object | | (RequestChange) |

Set Property | | |

---+---- |<------ Shared Object Event ------|

| (Success) |

| |

---+---- |------- Shared Object Event ----->|

Shared object| | (SendMessage) |

Message | | |

Broadcast ---+----|<------- Shared Object Event -----|

\|	(SendMessage)	\|
	\|	\|
	\|	\|

Shared object message broadcast

7.3.3. Publish Metadata from Recorded Stream

This example describes the message exchange for publishingmetadata.

+------------------+ +---------+

| Publisher Client | | | FMS |

+---------+--------+ | +----+----+

| Handshakingand Application |

| connect done |

| | |

---+--- |---CommandMesssage(createStream) -->|

Create | | |

Stream | | |

---+---|<---------Command Message------------|

| (_result -command response) |

| |

---+--- |---- CommandMessage(publish) ------>|

Publishing | | |

metadata | |<------ UserControl(StreamBegin)-----|

from file | | |

| |-----Data Message (Metadata) ------->|

| |

Publishing metadata

8. References

[RFC0791] Postel, J., "Internet Protocol", STD5, RFC 791, September 1981.

[RFC0793] Postel, J., "Transmission ControlProtocol", STD 7, RFC 793, September 1981.

[RFC1982] Elz, R. and R. Bush, "Serial NumberArithmetic", RFC 1982, August 1996.

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

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

[AS3] Adobe Systems, Inc., "ActionScript3.0 Reference for the Adobe Flash Platform", 2011,<http://www.adobe.com/devnet/ actionscript/documentation.html>.

[AMF0] Adobe Systems, Inc., "Action MessageFormat -- AMF 0", December 2007,<http://opensource.adobe.com/wiki/download/attachments/1114283/amf0_spec_121207.pdf>.

[AMF3] Adobe Systems, Inc., "Action MessageFormat -- AMF 3", May 2008,<http://opensource.adobe.com/wiki/download/attachments/1114283/amf3_spec_05_05_08.pdf>.

Authors’ Addresses

Hardeep Singh Parmar (editor) AdobeSystems Incorporated

345Park Ave

San Jose, CA 95110-2704

Phone:+1 408 536 6000

Email: hparmar@adobe.com

URI: http://www.adobe.com/

Michael C. Thornburgh (editor) AdobeSystems Incorporated

345Park Ave

San Jose, CA 95110-2704

Phone:+1 408 536 6000

Email: mthornbu@adobe.com

URI: http://www.adobe.com/

伍意

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
RTMP官方协议不必翻译

Copyright Adobe Systems Incorporated H. Parmar, Ed.M. Thornburgh, Ed.AdobeDecember 21, 2012 Adobe’s Real Time Messaging Protocol
复制链接

扫一扫

专栏目录

\|	milliSeconds	\|	Number	\|	Number of milliseconds at which the \|
\|		\|		\|	the stream is paused or play resumed. \|
\|		\|		\|	This is the current stream time at the \|
\|		\|		\|	Client when stream was paused. When the\|
\|		\|		\|	playback is resumed, the server will \|
\|		\|		\|	only send messages with timestamps \|
\|		\|		\|	greater than this value. \|
+--------------+----------+----------------------------------------+