RTMP（real time messaging protocol）协定

本文为 Adobe rtmp 标准 1.0 的中文介绍，其中内容大部分都是翻译自 rtmp 官网文档 rtmp_specification_1.0.pdf

具体文章目录参见文章内侧边栏

<!–more–>

介绍

Adobe 的实时音讯传输协定（RTMP）通过牢靠的流传输（如 TCP [RFC0793]）提供双向音讯多路传输服务，用于在端到端之间传输带有时序信息的视频，音频和数据音讯的并行流。穿过多层流，RTMP 音讯块流不提供任何管制的优先级别和类似模式，然而能够用于高层协定提供这样的优先级，例如：一段实时视频服务会抉择抛弃给迟缓的客户的视频信息确保音频信息能够及时被接管。RTMP 音讯块流 蕴含它本人的入队协定管制音讯，也提供一个高层协定机制用于嵌入用户的管制音讯。

定义

无效负载：Payload

蕴含在包中的数据，就像音频样本或者压缩的视频数据。

包：Packet

一个数据包由固定的包头和无效负载数据组成，一些底层协定或者须要包的封装来被定义。

端口：Port

在 TCP/IP 协定中定义的用正整数示意的端口号用于在传输中提取以辨别指标主机的不同利用，用于 OSI 传输层的传输抉择（TSEL）就是端口。

传输地址：Transport address

网络地址和端口的组合辨认一个传输层终端端口，例如一个 IP 地址和 TCP 端口，数据包从一个源传输层地址传送到指标段的传输层地址。

音讯流：Message stream

一个通信的逻辑通道，容许音讯流通。

音讯流 ID：Message stream ID

每一个音讯领有一个调配的 ID 辨认追随的音讯流。

音讯块：Chunk

音讯的片段，音讯被分成小的局部，在他们在网络中发送之前穿插存储。音讯块确保定制工夫戳的端到端全音讯传送，穿过多层流。

音讯块流：Chunk stream

一个通信的逻辑通道，容许音讯块在一个特定的方向上流通，音讯块流能够从客户端传送到服务器，也能够相同。

音讯块流 ID：Chunk stream ID

每一个音讯块有一个调配的 ID 用于辨认更随的音讯块流。

复合技术：Multiplexing

把离开的音视频数据组合成一条音视频流的过程，使同时传送许多音视频数据成为可能。

逆复合技术：DeMultiplexing

复合的反向过程，穿插存取组装的音频视频数据，使他们成为最后的音视频数据

近程过程调用：Remote Procedure Call (RPC)

容许客户端或服务器在对等端调用子例程或过程的申请。

Action Message Format (AMF)

一种紧凑的二进制格局，用于序列化 ActionScript object graphs。能够透过 AMF overHTTP 的形式将 flash 端材料编码后传回 server，server 端的 remoting adaptor 接管到材料后则会译码回正确的 native 对象，交给正确的程序处理。

字节程序，对齐和工夫格局

所有的整数字段都被引入到了字节程序当中，字节 0 是第一个显示进去的，也是一个词和一个字段中最重要的。这种程序就是通常所说的“大端”。如果没有非凡阐明，在本文档中数字常量都是用十进制示意。

除另有规定外，RTMP中的所有数据都是字节对齐的。例如，一个 16 位字段可能处于奇数字节偏移处。在指定填充的中央，填充字节应该是 0。

RTMP中的工夫戳绝对于未指定的期间是以整数毫秒为单位给出的。通常，每个流将以工夫戳 0 开始，但这不是必须的，只有两个终端在工夫点上达成统一。请留神，这意味着跨多个流（尤其是来自不同主机）的任何同步都须要一些 RTMP 外的其余机制。

工夫戳必须始终在线性的减少，容许利用程序处理异步传输，带宽度量，检测，和流控制。

因为工夫戳长度为 32 位，因而它们每隔 49 天，17 小时，2 分钟，47.296 秒滚动一次。因为流能够间断运行，可能继续数年，RTMP应用程序应该在解决工夫戳时应用序列号算法 [RFC1982]，并且应该可能解决回绕。例如，假设所有相邻的工夫戳都在2^31 - 1 毫秒之间，所以 10000 会在 4000000000 之后，而 3000000000 会在 4000000000 之前。

工夫戳增量 delta 也被指定为绝对于先前工夫戳的无符号整数毫秒数。工夫戳增量 delta 能够是 24 位或 32 位。

RTMP 块流

本节介绍实时音讯传送协定块流（RTMP 块流 ）。它为更高级别的多媒体流协定提供复用和打包服务。尽管RTMP Chunk Stream 旨在与实时音讯传送协定配合应用，但它能够解决发送音讯流的任何协定。每条音讯都蕴含工夫戳和无效负载类型标识。RTMP Chunk Stream和 RTMP 一起实用于各种音频 – 视频利用，从一对一和一对多实时播送到视频点播服务，再到交互式会议利用。

当与牢靠的传输协定（如 TCP [RFC0793]）一起应用时，RTMP 块流 提供了保障所有音讯在多个流中按工夫排序的端到端传送。RTMP 块流 不提供任何优先级或相似的管制模式，但能够由更高级别的协定提供这种优先级。

音讯格局

能够拆分成块以反对复用的音讯格局取决于更高级别的协定。然而，音讯格局应该蕴含下列创立块所必须的字段。

工夫戳：

音讯的工夫戳，这个字段能够传输 4 个字节。

长度：

音讯的无效负载的长度，如果音讯头不能被省略，它应该蕴含在长度中，这个字段在音讯块包头中占有 3 个字节。

类型 ID：

协定管制音讯的类型字段的范畴是被保留的，这些流传信息的音讯由 RTMP 音讯块 和高层协定解决，所有其余的类型 ID 可被高层协定应用，对 RTMP 音讯块 来说当做不通明的值，实际上，RTMP Chunk Stream中的任何内容都不须要将这些值用作类型; 所有（非协定）音讯能够是雷同类型的，或者应用程序能够应用类型 id 来辨别同步形迹而不是类型。该字段占用块头中的 1 个字节。

音讯流 ID:

音讯流 ID 能够是任意的值。复合到雷同块流上的不同音讯流能够基于它们的音讯流 ID 进行逆复合操作。除此之外，就 RTMP 块流而言，这是一个不通明的值。该字段以小尾数格局占用块头中的 4 个字节。

握手

RTMP连贯始于握手。rtmp握手与其余协定的握手不同; 它由三个雷同大小的块组成，而不是由可变大小的块组成。

客户端（连贯已初始化的终端）和服务器都发送雷同的三个块。为了阐明，由客户端发送的 3 个块别离为C0, C1, C2，由服务端发送的 3 个块别离为S0, S1, S2。

握手的程序

握手以客户端发送 C0 和C1音讯块位开始，客户端必须等到 S1 达到在发送 C2。客户端必须等到S2 接管到才能够发送其余的数据；服务端必须等到 C0 达到才发送 S0 和S1，在 C1 之后也会期待。服务端必须等到 C1 达到才发送 S2，服务端必须等到C2 达到后才发送其余数据。

C0 和 S0 格局

C0和 S0 都是单个 8 位字节，能够看成一个 8 位整形字段。

8 比特版本：在 C0 中，这个字段辨认客户端需要的 RTMP 的版本，在 S0 中，这个字段辨认服务器端抉择的 RTMP 的版本，被定义的是版本 3，0 到 2 是早前的版本应用的，4 到 31 保留用于将来应用，32 到 255 还没有被容许。不能辨别客户的申请的版本的服务应该以 3 返回，客户端能够抉择降级到版本 3，或放弃握手。

C1 和 S1 格局

C1和 S1 包长度为 1536 个 8 位字节，蕴含以下字段：

time（4 个字节）：这个字段蕴含工夫戳，被当做后续音讯块从终端发送的工夫点，兴许是 0，或者一些任意的值。为了同步多路音讯块流，终端或者心愿发送其余音讯块流的工夫戳的以后值。

zero（4 各个字节）：这个字段必须全 0。

random data（1528 个字节）：这个字段能够蕴含任何任意的值，因为每个终端必须辨别本人初始化的握手的返回数据和对方初始化的握手的返回数据，这个数据应该发送一些随机数。然而没有必要用密码保护随机数和动静值。

C2 和 S2 格局

C2和 S2 包长度为 1536 个 8 位字节，别离相似于 S1 和C1的原样返回，由一下几个字段组成：

time（4 个字节）：

这个字段必须蕴含由对端发送的S1（对应C2）或者C1（对应S2）的工夫戳.

time2（4 个字节）：

这个字段必须蕴含先前的由对端发送的数据包（S1或者C1）被读取的工夫戳。

random echo（1528 个字节）：

这个字段必须蕴含在对端发送的 S1（对应C2）或S2（对应C1）数据包中的随机数据字段。任何一方都能够应用time 和time2字段与以后工夫戳一起疾速估算连贯的带宽和 / 或提早，但这不太可能有用。

握手过程图

上面的表格形容了握手过程的几个阶段

音讯分块

握手后，连贯复用一个或多个音讯块流。每个块流从一个音讯流携带一种类型的音讯。每个创立的块都有一个与其关联的惟一 ID，称为块流 ID。这些块通过网络传输。发送时，每个块必须在下一个块之前全副发送。在接收端，依据块流 ID 将块组合成音讯。

分块容许将较高级别协定中的大的型音讯合成为较小的音讯，例如避免较大的低优先级音讯（例如视频）阻塞较小的高优先级音讯（如音频或管制）。

分块还容许以较少的开销发送小音讯，因为分块头蕴含信息的压缩示意信息，这些压缩音讯原本应该蕴含在音讯自身的。

块大小是可配置的。它能够应用 Set Chunk Size 管制音讯进行设置。

音讯块格局

每一个音讯块有头部和数据组成，头部本身能够被宰割成三个局部：

音讯块根本头（1 到 3 个字节）：这个字段编码了音讯块流的 ID 和音讯块的类型，音讯块类型决定了音讯包头的编码格局，长度齐全取决于可变长的音讯块流 ID。

音讯块音讯头（0,3,7 或 11 字节）：这个字段编码正在传送的音讯的信息，长度能够利用在音讯块头中具体的音讯块类型来决定。

扩大工夫戳（0 或 4 字节）：此字段在某些状况下是存在的，取决于音讯块音讯头中的编码工夫戳或工夫戳增量字段。

音讯块块数据（可变大小）：该块的无效负载，直至配置的最大块大小。

音讯块根本头

音讯块根本头对音讯块流的 ID 和音讯块的类型进行编码（在上面的图表中用 fmt 示意），音讯块类型决定了编码的音讯头的格局，音讯块根本头字段能够是 1,2 或者 3 个字节长，取决于音讯块流 ID。

该协定反对多达 65597 个 ID 为 3 -65599 的流。ID0,1 和 2 被保留。值 0 批示 2 字节模式和 64-319 范畴内的 ID（the second byte + 64）。值 1 示意 3 字节模式，ID 在 64-65599（(the third byte) * 256 + the second byte + 64）范畴内。在 3 -63 范畴内的值示意残缺的流 ID。块 ID 为 2 的流 ID 保留，用于低级别的协定管制音讯和命令。

在音讯块根本头中 0 - 5 比特 (最不重要的) 代表了音讯块流 ID。

音讯块流 ID 2-63 能够被编码成这个字段的单字节的版本号。

块流 ID 64-319 能够以 2 字节的模式被编码。ID 计算为（第二个字节 + 64）。

能够在此字段的 3 字节版本中对块流 ID 64-65599 进行编码。ID 计算为（（第三字节）* 256 +（第二字节）+64）。

cs id（6 比特）：这个字段蕴含了音讯块流 ID，值从 2 到 63，值 0 和 1 用于代表这个字段的 2 个或者 3 个字节的版本号。

fmt（2 比特）：这个字段标识音讯块音讯头应用的四种格局之一。见下一大节

cs id -64（8 或者 16 个比特）：

这个字段蕴含了音讯块流 ID 减 64，例如 ID 365 在 cs id 段用 1 示意，在 16 比特的 cs id -64 段用 301 示意。

值为 64 到 319 的音讯块流 ID 能够被 2 字节或者 3 字节的版本号来示意。

音讯块音讯头

在音讯块音讯头中有四种不同的格局，由音讯块根本头的 fmt 字段抉择。应该应用最简洁的表达方式示意每一个音讯块音讯头。

类型 0

类型 0 的音讯块有 11 个字节长，这个类型必须在音讯块流开始时和音讯流的工夫戳回溯时应用

工夫戳（3 个字节）：对于类型 0 的块，音讯的相对工夫戳发送到此处。如果工夫戳大于或等于 16777215（十六进制0xFFFFFF），则该字段必须是 16777215，示意存在扩大工夫戳字段以编码残缺的 32 位工夫戳。否则，这个字段应该是整个工夫戳。

类型 1

类型 1 的音讯块有 7 个字节长，音讯流 ID 没有被蕴含，这个音讯块失去和先前音讯块同样的流 ID，带有可变长的音讯的流（例如许多视频格式）在类型 0 音讯块后应该应用这种格局作为每一个音讯的第一个音讯块。

类型 2

类型 2 块头长度为 3 个字节。流 ID 和音讯长度都不蕴含在内; 该块与后面的块具备雷同的流 ID 和音讯长度。具备固定大小音讯的流（例如，某些音频和数据格式）应该在第一个音讯之后应用这种格局作为每个音讯的第一个块。

类型 3

类型 3 的音讯块没有头，流 ID，音讯长度和工夫戳 delta，这个类型的音讯块在之前的音讯块中取值，当繁多的音讯被决裂成音讯块，所有的音讯块除了第一个，其余都应该应用这种类型，流由同样大小的音讯组成。

公共头字段

块音讯头中每个字段的形容：

扩大工夫戳

Extended Timestamp字段用于编码大于 16777215（0xFFFFFF）的工夫戳或工夫戳增量; 也就是说，对于工夫戳或工夫戳增量，它们不适宜类型 0,1 或 2 块的 24 位字段。该字段对残缺的 32 位工夫戳或工夫戳增量进行编码。这个字段用于示意将类型 0 块的工夫戳字段或类型 1 或 2 块的工夫戳增量字段设置为 16777215（0xFFFFFF）。当雷同块流 ID 的最新类型 0,1 或 2 的块批示存在扩大工夫戳字段时，该字段呈现在类型 3 的块中。

示例

共有 2 个示例

示例 1

本例给出了一个简略的音频音讯流，这个例子示范了信息的冗余。

下表显示了在此流中生成的块。从音讯 3 开始，数据传输失去优化。除此之外，每音讯只有 1 字节的开销。

示例 2

本例阐明一个很长的音讯被宰割成很多音讯块。

这里是宰割进去的音讯块

音讯块 1 的包头数据具体介绍了 307 个字节的音讯的全副。

留神这两个例子，类型 3 音讯块能够用作两种不同的形式，第一种是示意一条音讯的连续，第二种是示意一条新音讯的开始，这个新音讯能够从曾经存在的数据中衍生进去。

协定管制音讯

RTMP块流应用音讯类型 ID 1,2,3,5 和 6 作为协定管制音讯。这些音讯蕴含 RTMP Chunk Stream 协定所需的信息。

这些协定管制音讯务必具备音讯流 ID 0（称为控制流）并且以块流 ID 2 发送。协定管制音讯一旦被接管就会立刻失效，同时工夫戳被疏忽。

设置音讯块大小

协定管制音讯 1：设置音讯块大小。用来告诉对方新的最大的音讯块大小。

音讯块的大小能够被设置成一个默认的值，128 字节，然而客户端或者服务端能够扭转这个值，并且发送音讯告诉对方更新。例如：假如一个客户端想要发送 131 字节的音频数据，音讯块的大小为 128 字节，在这种状况下，客户端能够发送这个协定管制音讯给服务端以告诉音讯块的大小被设置成了 131 字节，那么客户端就能够用一个音讯块发送音频数据。

最大块大小应该不能小于 128 个字节，并且必须不能小于 1 个字节。每个方向的最大块大小都是独立保护的。

0：这一位必须为 0。

chunk size 块大小（31 位）：该字段保留新的最大块大小（以字节为单位），这将用于发件人的所有后续块，直至另行通知。无效大小为 1 到 2147483647（0x7FFFFFFF）（含）; 然而，大于 16777215（0xFFFFFF）的所有大小都是等效的，因为没有块大于一条音讯，并且没有音讯大于 16777215 字节。

中断音讯

协定管制音讯 2：停止音讯。用于告诉对方是否正在期待块实现音讯，而后抛弃局部接管到的音讯。对方接管块流 ID 作为该协定音讯的有效载荷。应用程序可能会在敞开时发送此音讯，以批示不须要进一步解决音讯。

chunk stream ID 块流 ID（32 位）：该字段保留块流 ID，对应的以后音讯将被抛弃。

Acknowledgement

客户端或服务器在收到等于窗口大小的字节后，必须向对端发送 Acknowledgement 确认。窗口大小是发送方未收到接管方确认而发送的最大字节数。该音讯指定了序列号，它是到以后为止收到的字节数。

sequence number 序列号（32 位）：字段示意到以后为止收到的字节数。

Window Acknowledgement Size

客户端或服务器发送此音讯以告诉对方在发送Acknowledgement 确认之间应用的窗口大小。发送人心愿在发送窗口大小字节后失去对方的确认。

设置对等带宽

客户端或服务器发送此音讯来限度另一方的输入带宽。收到此音讯的另一方通过将已发送但未确认的数据量限度为此音讯中批示的窗口大小这种形式用来限度其输入带宽。如果窗口大小与发送给此音讯发送者的最初一个窗口大小不同，那么接管此音讯的另一方应该应用 "Window Acknowledgement Size" 音讯进行响应。

限度类型 Limit Type 是以下值之一：

• 0 – Hard：对方应该限度其输入带宽到指定的窗口大小。
• 1 – Soft：对方应该限度其输入带宽到本音讯中批示的窗口或曾经失效的限度，以较小者为准。
• 2 – Dynamic：如果以前的限度类型是 Hard，请将此音讯视为 Hard 类型音讯，否则能够间接漠视。

RTMP 音讯格局

本局部次要介绍 RTMP 音讯的格局，在网络实体之间应用较低级传输层（如RTMP 块流）传输这些音讯。

尽管 RTMP 旨在与 RTMP 块流 一起应用，但它能够应用任何其余传输协定发送音讯。RTMP Chunk Stream和 RTMP 一起实用于各种音视频利用，从一对一和一对多实时播送到视频点播服务，再到交互式会议利用。

RTMP 音讯格局

服务器和客户端通过网络发送 RTMP 音讯以互相通信。音讯可能包含音频，视频，数据或任何其余音讯。

RTMP音讯有两局部，头部和无效负载。

音讯头

音讯头蕴含以下字段：

音讯无效负载

音讯的另一部分是无效负载，它是音讯中蕴含的理论数据。例如，它可能是一些音频样本或压缩的视频数据。

用户管制音讯

RTMP 应用音讯类型 ID 4 作为用户管制音讯。这些音讯蕴含 RTMP 流层应用的信息。带有 ID 1,2,3,5 和 6 的协定音讯由 RTMP 块流协定应用。

用户管制音讯应该应用音讯流 ID 0（称为控制流），并且当通过 RTMP 块流发送时，在音讯流 ID 2 上发送。用户管制音讯在流中被接管时失效，他们的工夫戳被疏忽。

客户端或服务器发送此音讯以告诉对端用户管制事件。该音讯携带事件类型和事件数据。

音讯数据 Event Data 的前 2 个字节用于标识事件类型Event Type。事件类型前面跟着事件数据。事件数据字段的大小是可变的。然而，在音讯必须通过 RTMP 块流层的状况下，最大块的大小应该足够大，以容许这些音讯适宜单个块。

RTMP 命令音讯

本节介绍在服务器和客户端之间用于互相通信的不同类型的音讯和命令。

在服务器和客户端之间替换的不同类型的音讯包含用于发送音频数据的音频音讯，用于发送视频数据的视频音讯，用于发送任何用户数据的数据音讯，共享对象音讯和命令音讯。共享对象音讯提供了一种通用的形式来治理多个客户端和服务器之间的分布式数据。命令音讯在客户端和服务器之间传送 AMF 编码的命令。客户端或服务器能够通过流应用命令音讯申请对方的近程过程调用（RPC）。

音讯类型

服务器和客户端通过网络发送音讯以互相通信。音讯能够是任何类型，包含音频音讯，视频音讯，命令音讯，共享对象音讯，数据音讯和用户管制音讯。

命令音讯

命令音讯在客户端和服务器之间传送 AMF 编码命令。这些音讯的 AMF0 编码的音讯类型值为 20，AMF3编码的音讯类型值为 17。这些音讯被发送来执行一些操作，例如 connect，createStream，publish，play，pause 等。诸如 onstatus，result 等命令音讯用于告诉发送者无关申请的命令的状态。命令音讯由命令名称，事务 ID 和蕴含相干参数的命令对象组成。客户端或服务器能够通过流应用命令音讯申请对方的近程过程调用（RPC）。

数据音讯

客户端或服务器发送此音讯用于向对方发送元数据或任何用户数据。元数据包含无关数据（音频，视频等）的详细信息，如创立工夫，持续时间，主题等。AMF0的音讯类型值为 18，AMF3的音讯类型值为 15。

共享对象音讯

共享对象是一个 Flash 对象（name-value 对的汇合），在多个客户端，实例等之间同步的。AMF0的音讯类型 19 和 AMF3 的音讯类型 16 保留用于共享对象事件。每条音讯能够蕴含多个事件。

反对以下事件类型：

音频音讯

客户端或服务器发送此音讯来向对等方发送音频数据。音讯类型值 8 保留给音频音讯。

视频音讯

客户端或服务器发送此音讯以向对等方发送视频数据。音讯类型值 9 保留给视频音讯。

聚合音讯

聚合音讯是单个音讯。音讯类型 22 用于聚合音讯。

聚合音讯的音讯流 ID 会笼罩聚合内的子音讯的音讯流 ID。

聚合音讯的工夫戳与第一个子音讯之间的差别是用于将子音讯的工夫戳从新归一化为流时间尺度的偏移量。将偏移量增加到每个子音讯的工夫戳以达到标准化的流工夫。第一个子音讯的工夫戳应该与聚合音讯的工夫戳雷同，所以偏移量应该为零。

后向指针蕴含前一个音讯的大小，包含其头部。它被蕴含来匹配 FLV 文件的格局并用于向后搜寻。

应用聚合音讯有几个性能劣势：

• 音讯块流最多能够在块内发送单个残缺的音讯。因而，减少块大小并应用聚合音讯可缩小发送的块的数量。
• 子音讯能够间断地存储在内存中。在进行零碎调用向网络上发送数据时效率更高。

用户管制音讯事件

客户端或服务器发送此音讯以告诉对端对于用户管制事件。

反对以下用户管制事件类型：

命令类型

客户端和服务器替换 AMF 编码的命令。发送方发送一条命令音讯，其中蕴含命令名称，事务 ID 和蕴含相干参数的命令对象。例如，connect命令蕴含 'app' 参数，它通知客户端连贯到的服务器应用程序名称。接管方解决该命令并以雷同的事务 ID 发送响应。响应字符串能够是 _result，_error 或办法名称，例如 verifyClient 或contactExternalServer。

_result或 _error 命令字符串示意响应。事务 ID 批示响应援用的未实现的命令。它与 IMAP 和许多其余协定中的标签雷同。命令字符串中的办法名称批示发送方正试图在接管方端运行办法。

以下类对象用于发送各种命令：

• NetConnection：一个对象，它是服务器和客户端之间连贯的更高级别示意。
• NetStream：示意发送音频流，视频流和其余相干数据的通道的对象。咱们还发送管制数据流的播放，暂停等命令。

NetConnection 命令

NetConnection治理客户端应用程序和服务器之间的双向连贯。另外，它为异步近程办法调用提供反对。

以下命令能够在 NetConnection 上发送：

• connect
• call
• close
• createStream

connect

客户端向服务端发送连贯（connect）命令申请连贯一个服务器利用实例。以下为命令的构造：

以下是连贯命令的命令对象中应用的 name-value 对的形容：

audioCodecs属性的标记值：

videoCodecs属性的标记值：

videoFunction属性的标记值：

对象编码 (object Encoding) 属性的值：

以下是服务端到客户端命令的构造：

以下是连贯命令中的音讯流：

命令执行期间的音讯流是：

1. 客户端将连贯命令发送到服务器以申请连贯服务器应用程序实例。
2. 接管到连贯命令后，服务器将协定音讯 'Window Acknowledgement Size' 发送给客户端。服务器还连贯到 connect 命令中提到的应用程序。
3. 服务器将协定音讯 'Set Peer Bandwidth' 发送给客户端。
4. 在解决协定音讯 'Set Peer Bandwidth' 后，客户端向服务器发送协定音讯'Window Acknowledgement Size'。
5. 服务器将类型为 User Control Message(StreamBegin) 的另一个协定音讯发送给客户端。
6. 服务器发送后果命令音讯，告诉客户端连贯状态（胜利 / 失败）。该命令指定事务 ID（连贯命令始终等于 1）。该音讯还指定了属性，例如 Flash Media Server 版本（字符串）。此外，它还指定其余连贯响应相干信息，如级别（字符串），代码（字符串），形容（字符串），对象编码（数字）等。

Call

NetConnection对象的调用办法在接收端运行近程过程调用（RPC）。被调用的 RPC 名称作为参数传递给 call 命令。

从发送方到接管方的命令构造如下：

响应的命令构造如下：

createStream

客户端将此命令发送到服务器以创立用于音讯通信的逻辑通道。音频，视频和元数据的公布是通过应用 createStream 命令创立的流通道执行的。

NetConnection是默认通信通道，其流 ID 为 0。协定和一些命令音讯（包含createStream）应用默认通信通道。

从客户端到服务器的命令构造如下所示：

从服务器到客户端的命令构造如下：

NetStream 命令

NetStream定义了流式音频，视频和数据音讯能够通过将客户端连贯到服务器的 NetConnection 流动的通道。一个 NetConnection 对象能够为多个数据流反对多个NetStream。

以下命令能够由客户端在 NetStream 上发送到服务器：

• play
• play2
• deleteStream
• closeStream
• receiveAudio
• receiveVideo
• publish
• seek
• pause

服务器应用 'onStatus' 命令将 NetStream 状态更新发送到客户端：

play

客户端将此命令发送到服务器以播放流。播放列表也能够应用此命令屡次创立。

如果您想要创立一个可在不同直播流或录像流之间切换的动静播放列表，请屡次调用 play，每次给reset 传递 false。相同，如果要立刻播放指定的数据流，请清空播放队列中的其余流，给reset 传递true。

从客户端到服务器的命令构造如下所示：

Play命令中的音讯流：

命令执行期间的音讯流是：

1. 在客户端收到服务器返回的 createStream 命令的胜利后果后，客户端就开始发送 play 命令。
2. 在收到 play 命令后，服务器发送协定音讯来设置块大小。
3. 服务器发送另一个协定音讯（用户管制），用于指定事件 'StreamIsRecorded' 的和该音讯中的流 ID。该音讯在前 2 个字节中携带事件类型，在最初 4 个字节中携带流 ID。
4. 服务器发送另一个指定事件 'StreamBegin' 的协定音讯（用户管制），以批示流传输到客户端的开始。
5. 如果客户端发送的播放命令胜利了，则服务器发送 onStatus 命令音讯 NetStream.Play.Start 和NetStream.Play.Reset。NetStream.Play.Reset只有在客户端发送的播放命令设置了重置标记时才由服务器发送。如果没有找到要播放的流，则服务器发送 onStatus 音讯NetStream.Play.StreamNotFound。
6. 在此之后，服务器发送客户端播放所需的音频和视频数据。

play2

与播放命令不同，play2能够切换到不同的比特率流，而不扭转播放内容的工夫线。服务器保护多个文件，用于反对客户端在 play2 中申请的所有比特率。

从客户端到服务器的命令构造如下所示：

在 ActionScript 3 语言参考 [AS3] 中形容了 NetStreamPlayOptions 对象的公共属性。

下图显示了该命令的音讯流：

deleteStream

当 NetStream 对象被毁坏时，NetStream发送 deleteStream 命令。

从客户端到服务器的命令构造如下所示：

服务器不发送任何响应。

receiveAudio

NetStream发送 receiveAudio 音讯以告诉服务器是否将音频发送给客户端。

从客户端到服务器的命令构造如下所示：

如果在将 Bool Flag 设置为 false 的状况下发送 receiveAudio 命令，则服务器不会发送任何响应。如果 Bool Flag 设置为 true，则服务器会应用状态音讯 NetStream.Seek.Notify 和NetStream.Play.Start作为响应。

receiveVideo

NetStream发送 receiveVideo 音讯以告诉服务器是否将视频发送给客户端。

从客户端到服务器的命令构造如下所示：

如果在将 Bool Flag 设置为 false 的状况下发送 receiveVideo 命令，则服务器不会发送任何响应。如果 Bool Flag 设置为 true，则服务器会应用状态音讯 NetStream.Seek.Notify 和NetStream.Play.Start作为响应。

publish

客户端发送 publish 命令以将已命名的流公布到服务器。应用该名称，任何客户端都能够播放此流并接管已公布的音频，视频和数据音讯。

从客户端到服务器的命令构造如下所示：

服务器应用 onStatus 命令进行响应以标记 publish 的开始。

seek

客户端发送 seek 命令来查找媒体文件或播放列表中的偏移量（以毫秒为单位）。

从客户端到服务器的命令构造如下所示：

当 seek 胜利时，服务器发送状态音讯 NetStream.Seek.Notify。如果失败，它将返回一个_error 音讯。

pause

客户端发送暂停命令以告诉服务器暂停或开始播放。

从客户端到服务器的命令构造如下所示：

当流暂停时，服务器发送状态音讯 NetStream.Pause.Notify。当流处于未暂停状态时发送NetStream.Unpause.Notify。如果失败，将返回一个_error 音讯。

音讯替换示例

以下是几个解释 RTMP 音讯替换的示例。

公布录制的视频

此示例阐明发布者如何公布流并将视频流式传输到服务器。其余客户端能够订阅此公布的流并播放视频。

播送共享对象音讯

此示例阐明在创立和更改共享对象期间替换的音讯。它还阐明了共享对象音讯播送的过程。

从录像的流公布元数据

本示例形容了公布元数据的音讯替换。

FMS: Flash Media Server

参考：

• rtmp_specification_1.0.pdf

记得帮我点赞哦！

精心整顿了计算机各个方向的从入门、进阶、实战的视频课程和电子书，依照目录正当分类，总能找到你须要的学习材料，还在等什么？快去关注下载吧！！！

朝思暮想，必有回响，小伙伴们帮我点个赞吧，非常感谢。

我是职场亮哥，YY 高级软件工程师、四年工作教训，回绝咸鱼争当龙头的斜杠程序员。

听我说，提高多，程序人生一把梭

如果有幸能帮到你，请帮我点个【赞】，给个关注，如果能顺带评论给个激励，将不胜感激。

职场亮哥文章列表：更多文章

自己所有文章、答复都与版权保护平台有单干，著作权归职场亮哥所有，未经受权，转载必究！