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字段与以后工夫戳一起疾速估算连贯的带宽和/或提早，但这不太可能有用。

握手过程图

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

阶段形容
未初始化协定版本在此阶段发送。 客户端和服务器都未初始化。 客户端发送数据包C0中的协定版本。 如果服务器反对该版本，则发送S0和S1作为响应。 否则，服务器将采取适当的措施进行响应。 在RTMP中，此操作正在终止连贯。
版本发送在未初始化状态之后，客户端和服务器都处于版本已发送状态。 客户端正在期待数据包S1，服务器正在期待数据包C1。 在接管到期待的数据包时，客户端发送C2并且服务器发送S2。 状态而后变成Ack发送。
ACK发送客户端和服务端别离期待S2和C2。
握手实现客户端和服务替换音讯。

音讯分块

握手后，连贯复用一个或多个音讯块流。每个块流从一个音讯流携带一种类型的音讯。每个创立的块都有一个与其关联的惟一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，这个类型的音讯块在之前的音讯块中取值，当繁多的音讯被决裂成音讯块，所有的音讯块除了第一个，其余都应该应用这种类型，流由同样大小的音讯组成。

公共头字段

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

字段形容
timestamp delta (3 bytes)对于类型1或类型2块，此处能够看到发送前一个块的工夫戳和以后块的工夫戳之间的差别。 如果增量大于或等于16777215（十六进制0xFFFFFF），则该字段必须是16777215，示意扩大工夫戳字段以编码残缺的32位增量的模式存在。 否则，这个字段应该是理论的增量。
message length (3 bytes)对于类型0和类型1的音讯块，音讯的长度会呈现在这里。留神这个别和音讯块无效负载长度是不一样的。音讯块的无效负载长度是除了最初一个音讯块的所有音讯块的最大的长度。
message type id (1 byte)对于类型0和类型1的音讯块，音讯的类型呈现在这里。
message stream id (4 bytes)对于类型为0的块，存储音讯流ID。 音讯流ID以little-endian格局存储。 通常，同一块流中的所有音讯将来自同一个音讯流。 尽管能够将独自的音讯流多路复用到同一个块流中，但这会毁坏头压缩的长处。 然而，如果一个音讯流敞开并且另一个随后关上，则没有理由通过发送新的类型为0的块来从新应用现有的块流。

扩大工夫戳

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音讯有两局部，头部和无效负载。

音讯头

音讯头蕴含以下字段：

字段形容
Message Type一个字节的字段来示意音讯类型。 一系列的类型ID（1-6）被保留用于协定管制音讯
Length三字节字段，以字节示意无效负载的大小。 它以big-endian格局设置。
Timestamp蕴含音讯工夫戳的四字节字段。 这4个字节按big-endian顺序排列。
Message Stream Id标识音讯流的三字节字段。 这些字节以big-endian格局设置。

音讯无效负载

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

用户管制音讯

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高级软件工程师、四年工作教训，回绝咸鱼争当龙头的斜杠程序员。

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

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

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

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