Rtmp协议中文介绍

RTMP（real time messaging protocol）协议

1，介绍

这篇文档详细说明了RTMP消息块流，它位高层多媒体流协议提供多路技术和包服务

RTMP消息块流是为RTMP协议设计的，他可以处理任何传送消息流的协议，每一个消息包含时间戳合有效负载类型标示，RTMP消息块流和RTMP一起适用于多样性音视频应用程序，从一对一和一对多向视频点播服务器直接广播到交互式会议应用程序。

当用到实时传输协议就像TCP，RTMP消息块流提供可靠地规则时间戳的端到端全信息传送。穿过多层流，RTMP消息块流不提供任何控制的优先级别和相似形式，但是可以用于高层协议提供这样的优先级，例如：一段实时视频服务会选择丢弃给于缓慢的客户的视频信息确保音频信息可以及时被接收。

RTMP消息块流包含它自己的入队协议控制消息，也提供一个高层协议机制用于嵌入用户的控制消息。

2.定义

有效负载：

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

包：

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

端口：

在TCP/ＩP协议中定义的用正整数表示的端口号用于在传输中提取以区分目标主机的不同应用，用于OSI传输层的传输选择（TSEL）就是端口。

传输地址：

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

消息流：

一个通信的逻辑通道，允许消息流通。

消息流ID：

每一个消息拥有一个分配的ID识别跟随的消息流。

消息块：

消息的片段，消息被分成小的部分，在他们在网络中发送之前交叉存储。消息块确保定制时间戳的端到端全消息传送，穿过多层流。

消息块流：

一个通信的逻辑通道，允许消息块在一个特定的方向上流通，消息块流可以从客户端传送到服务器，也可以相反。

消息块流ID：

每一个消息块有一个分配的ID用于识别更随的消息块流。

复合技术：

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

逆复合技术：

复合的反向过程，交叉存取组装的音频视频数据，使他们成为最初的音视频数据

3．字节顺序，列队和时间格式

所有的整数字段有被网络字节负载着，字节0是第一个显示出来的，也是一段文字和字段中最重要的。这种字节顺序一般被认为“大字节“，数字常量在这种文档里是用十进制表示。

所有RTMP消息块流是以用字节列队，例如：一个16字节的字段也许会在字数字节的偏移段。那里要填充被标示，填充字节应该有0值（似乎看不懂）.

在RTMP消息块流中的时间戳用整数表示，单位为毫秒。每一个消息块流以时间戳0开始，但是这不是必须的，只要两个终端在时间点上达成一致，注意那就意味着任何穿过多消息块流异步传输（特

别是分散的主机）在RTMP消息块流之外需要一些而外的机制。

时间戳必须始终在线性的增加，允许应用程序处理异步传输，带宽度量，检测，和流控制。

因为时间戳一般是只有32字节的长度，他们周期小于50天，因为六流是允许不停地流动的，最终可以运行几年，一个RTMP消息块流应用必须用到模运算用于相减和比较，任何合理的方式都可以被接受，只要两端都达成一致，一个应用可以假设，例如，所有相近的时间戳在2的31次方以内，所以10000在4000000000后面，3000000000在4000000000前面。

时间戳delta作为一个表示毫秒的无符号整数也会被详细介绍，和先前的时间戳相比，时间戳delta可以是24字节或者是32字节的长度。

4．消息格式

一个消息的格式可以分裂成消息块以支持复用，依靠高层协议，消息格式应该包含创造消息块的必须字段。

时间戳：

消息的时间戳，这个字段可以传输4个字节。

长度：

消息的有效负载的长度，如果消息头不能被省略，他应该包含在长度中，这个字段在消息块包头中占有3个字节。

类型ID：

协议控制消息的类型字段的范围是被保留的，这些传播信息的消息被RTMP消息块和高层协议处理，所有其他的类型ID可被高层协议使用，被RTMP消息块当做不透明的值，事实上，在RTMP消息块中需要这些值当做类型的是没有的，所有的消息可以成为通一种类型，或者应用程序用这个字段区分同步迹象而不是类型，这个字段占用1个字节。

消息流ID:

消息流ID可以是任意值，不同的消息复合依靠的同样的消息块流是基于他们的消息流ID被逆复合而成的，在此之上，直到RTMP消息块被关注，这是一个不透明的值，这个字段在包头中占用4个字节。

5．握手

一个RTMP通信以握手开始，握手不像其他的协议，他包含三个固定长度的消息块。

客户（初始化通信的终端）和服务器每放发送同样的三个消息块，说明一下，被客户段发送的消息块被指定为C0，C1，C2，被服务器端发送的消息被指定为S0，S1，S2。

5.1．握手的顺序

握手以客户端发送C0和C1消息块位开始，客户端必须等到S1到达在发送C2。客户端必须等到S2接收到才可以发送其他的数据；服务端必须等到C0到达才发送S0和S1，在C1之后也会等待。服务端必须等到C1到达才发送S2，服务端必须等到C2到达后才发送其他数据。

5.2．C0和S0格式

C0也S0包长8个字节

版本：8比特

在C0中，这个字段识别客户端需求的RTMP的版本，在S0中，

这个字段识别服务器端选择的RTMP的版本，被定义的是版本3，0到2是被早前的版本使用的，4到31保留被用作未来的用途，32到255还没有被允许。不能区分客户的请求的版本的服务应该以3返回，客户端或许会选择3一下的版本，或者放弃握手。

5.3．C1和S1的格式：

C1和S1的数据包有1536个字节长，由以下几个字段组成。

时间：4个字节

这个字段包含时间戳，被当做以后消息块从终端发送的时间点，也许是0，或者一些任意的值，用来同步多重的消息块流，终端或许希望发送其他消息块流的时间戳的当前值。

0：4各个字节

这个字段必须全0。

随即数据：1528个字节

这个字段可以包含任何任意的值，因为每个终端必须区分自己初始化的握手的返回数据和对方初始化的握手的返回数据，这个数据应该发送一些随机数。但是没有必要密码保护随机数和动态值。5.4．C2和S2的格式

C2和S2数据吧有1536字节长度，近似S1和C1的回声，由一下几个字段组成。

时间：4个字节

这个字段必须包含由每方发送的S1（对应C2）或者C1（对应S2）的时间戳.

时间2：4个字节

这个字段必须包含先前的由每一方发送数据包（S1或者C1）被读到的时间戳。

随机返回：1528个字节

这个字段必须包含在每方发送的S1（对应C2）或者S2（对应C1）的随机数据字段。每一方可以利用时间和时间2字段和当前时间戳组成作为连接的带宽或者延迟的评估。但是似乎没有用。

5.5．握手过程

下面的表格表述了提到了在握手阶段的状态

6.消息分块

在握手以后，连接复合一个或者多个消息块，每个消息块流负载一个消息流中的类型，每一个消息块的创造有一个唯一分配的ID，被称为消息块流ID，消息块流在网络上传输。传输的时候每一个消息块在下一个消息块之前必须完全被发送，当接收结束，消息块基于消息块流ID被组装成消息。

消息分块允许高层协议的大的消息被分割成小的消息，例如，阻止大的低优先级消息模块化位高优先级的消息。

消息分块也允许小的消息被传送时带有小的包头，消息块的包头包含了信息的压缩表示，另外这下信息必须在消息自身中包含。

6.1．消息块格式：

每一个消息块有包头和数据组成，包头自身可以被分割成三个部分，

消息块的基本头：1到3个字节

这个字段编码了消息块流的ID和消息块的类型，消息块类型决定了消息包头的编码格式，长度完全取决于可变长的消息块流ID。

消息块消息头：0，3，7，或者11个字节

这个字段编码正在传送的消息的信息，长度可以利用在消息块头中详细的消息块类型来决定。

扩展时间戳：0或者4个字节

这个字段必须在普通时间戳被设置为0xf f f f f f时发送，在普通时间戳被设置成任何其他时不能不能传送。所以对于值比0xf f f f f f小的，普通时间戳字段应该用在扩展时间戳没有被呈现的案例中。对于值大于或者等于0xf f f f f f普通时间戳不能被利用，不ixuba值设置成0xf f f f f f，扩展时间戳要被发送。

6.1.1．消息块基本头：

消息块基本时间头对消息块流的ID和消息块的类型进行编码，（在下面的图表中用fmt表示），消息块类型决定了编码的消息头的格式，消息块基本头字段可以是１，２，或者３个字节长，决定于消息块流ＩＤ。

协议支持超过６５５９７个流，ＩＤ范围3-65599，ID0，1和2是被保留的，值0代表了在64到319的ID，值1代表了在64到65599的ID，值2代表了底层协议消息。对于流ID没有额外增加的字节表示，值3到63表示完成的流ID，没有额外的字节用来表示。

在消息块基本头中0-5比特(最不重要的)代表了消息块流ID

消息块流ID 2-63可以被编码成这个字段的一个字节的版本号。

消息块流ID64到319在这个字段中可以被编码成2个字节的版本号（第2个字节加64）。

消息块流ID64到65599在这个字段中可以被编码成3个字节的版本号（第三个字节*256+第二个字节+64）。

Cs id：6比特

这个字段包含了消息块流ID，值从2到63，值0和1用于代表这个字段的2个或者3个字节的版本号。

Fmt：2比特

这个字段标示了一个或者4个被消息块消息头使用的格式。

Cs id -64：8或者6个比特

这个字段包含了消息块流ID减64，例如ID365在CS id段用1表示，在cs id -64段用301表示。

值为64到319的消息块流ID可以被2字节或者3字节的版本号来表示。

6.1.2．消息块消息头

在消息块消息头中有四种不同的个格式，由消息块基本头的fmt字段选择。

一次执行应该使用最简洁的表达方式表示每一个消息块消息头。

6.1.2.1．类型0：

类型0的消息块有11个字节长们这个类型必须在消息块流开始时使用，只要消息流的时间戳回溯。

时间戳（timestamp）：3个字节

对于类型0的消息块，消息的完全的时间戳放在这里，如果时间戳比16777215大或者相等（16精制0x00ffffff），这个值必须是16777215，扩展的时间戳头被发送，另外，这个值必须是完整的时间戳。

6.1.2.2．类型1

类型1的消息块有7个字节长，消息流ID没有被包含，这个消息块得到和先前消息块同样的流ID，带有可变长的消息的流（例如许多视频格式）在类型0消息块后应该使用这种格式作为每一个消息

的第一个消息块。

6.1.2.3．类型2

类型2消息块有3个字节长，流ID和消息长度都没有被包含，这个消息块和之前的消息块有相同流ID和消息长度，带有不变长的消息的流（例如一些音频格式）在类型0消息块后应该利用这种格式作为每一个消息的第一个消息块

6.1.2.4．类型3

类型3的消息块没有头，流ID，消息长度时间戳delta，这个类型的消息块在之前的消息块中取值，当单一的消息被分裂成消息块，所有的消息块除了第一个，应该使用这种类型，流由同样大小的消息组成。

时间戳delta（timestamp delta）：3个字节

对于类型1和类型2的消息块，先前的消息块的时间戳和当前的消息块的时间戳的不同点可以在这里看到，如果delta的值比16777215大或者相同，这个值必须是16777215，扩展的时间戳被呈现，另外，这和值必须是完整的delta。

消息长度（message length）：3个字节

对于类型0和类型1的消息块，消息的长度会出现在这里。注意这一般和消息块有效负载长度是不一样的。消息块的有效负载长度是出了最后一个消息块的所有消息块的最大的长度。

消息类型 id（message type id）：一个字节

对于类型0和类型1的消息块，消息的类型被表示在这里。

消息流ID（message stream id）：4个字节

对于类型0的消息块，消息流ID会被储存，消息流ID在很小的比特中被存储，代表性的，所有的相同消息块流的消息来自同一个消息流。然而使把分散的消息流复合成同一个消息块流成为可能，就不用所有的头压缩。然而，如果一个消息流被关，另一个更随的是开着的，就没有理由通过发送一个新的类型0的消息块让一个存在的消息块流不能再生。

6.1.3．扩展时间戳（extend timestamp）：

当消息头中的普通的时间戳是0x00ffffff这个字段就会被传送，如果普通时间戳的值小于0x00ffffff，这个字段就不会被呈现，如果时间戳字段没有被呈现这个字段不能被呈现，类型3的消息块没有这个字段。如果这个字段被传送会在消息块头之后，消息块数据之前被立刻定位。

Chunk format

6.2.1．例1：例一给出一个简单的音频消息流，这个例子示范了信息的冗余。

下一个表格展示了消息块在流中被创造，从消息3向前，数据的传输是最优化的，每个消息只有1个字节

6.2.2．例二：例二举例说明一个很长的消息被分割成很多消息块

这里是分割出来的消息块

消息块1的包头数据详细介绍了307个字节的消息的全部。注意这两个例子，类型3消息块可以有用作两个不同的方式，第一种是指定一则消息的延续，第二种是指定新消息的开始，这个新消息可以从已经存在的数据中衍生出来。

7．协议控制消息

Rtmp消息块流支持一些协议控制消息，这些消息包含RTMP消息块流协议需求的信息，不会用于高层的传播，现有两种协议消息使用在RTMP消息块流中，一个协议消息用来设置消息块大小，另外一种用于终端消息，由于没残余的消息块没有被利用。

协议控制消息应该有消息流ID 0（被称为控制流）和消息块流ID 2，带有最高的优先级被发送。每一个协议控制消息类型有一个固定大小的负载，通常在一个单一的消息块中被发送。

7.1．设置消息块大小：

协议控制消息1，设置消息块大小，用来通知对方新的最大的消息块大小。

消息块的大小可以被设置成一个默认的值，但是客户端或者服务端可以改变这个值，可以给对方更新。例如：假设一个客户端想要发送131字节的音频数据，消息块的大小为128字节，在这种情况下，客户端可以发送这个协议控制消息给服务端以通知消息块的大小被设置成131字节，那么客户端就

可以用一个消息块发送音频数据。

最大的消息块大小可以是65536个字节，消息块的大小在每一个方向上是维持不变的。

7.2．中断消息：

这个协议控制消息用来通知对方如果他等待消息块完成一个消息，然后丢弃部分收到的消息。对方受到消息块流ID作为这个协议消息的有效负载。一个应用程序为了表示未来的消息处理过程是不需要

的时候或许会送这个消息。

RTMP消息格式

1.介绍：

这段文字详细介绍了RTMP，详细介绍了在网络上使用底层传输协议的实体调动的消息的格式。RTMP 是设计和RTMP消息块流协议一起工作的，它可以利用任何其他的传输协议发送消息，RTMP消息块协议和RTMP一起适用于多样性的音视频应用程序，从一对一，一对多的向视频点播服务器的直接广播到交互式的回忆应用程序。

2.定义：

消息流：

一个通信的逻辑通道，允许消息流通。

消息流ID：

每一个消息拥有一个分配的ID识别跟随的消息流。

有效负载：

包含在数据包中的数据，例如音频样本或者压缩的视频数据。

数据包：

一个数据包由固定的包头和有效负载数据组成，一些底层的协议或许会需要定义的数据包来封装。

3. 字节顺序，列队和时间格式

所有的整数字段有被网络字节负载着，字节0是第一个显示出来的，也是一段文字和字段中最重要

的。这种字节顺序一般被认为“大字节“，数字常量在这种文档里是用十进制表示。

所有RTMP消息块流是以用字节列队，例如：一个16字节的字段也许会在字数字节的偏移段。那里要填充被标示，填充字节应该有0值（似乎看不懂）.

在RTMP消息块流中的时间戳用整数表示，单位为毫秒。每一个消息块流以时间戳0开始，但是这不是必须的，只要两个终端在时间点上达成一致，注意那就意味着任何穿过多消息块流异步传输（特别是分散的主机）在RTMP消息块流之外需要一些而外的机制。

时间戳必须始终在线性的增加，允许应用程序处理异步传输，带宽度量，检测，和流控制。

因为时间戳一般是只有32字节的长度，他们周期小于50天，因为六流是允许不停地流动的，最终可以运行几年，一个RTMP消息块流应用必须用到模运算用于相减和比较，任何合理的方式都可以被接受，只要两端都达成一致，一个应用可以假设，例如，所有相近的时间戳在2的31次方以内，所以10000在4000000000后面，3000000000在4000000000前面。

时间戳delta作为一个表示毫秒的无符号整数也会被详细介绍，和先前的时间戳相比，时间戳delta可以是24字节或者是32字节的长度。

4.RTMP消息格式：

服务端和客户端在网路上发送发送RTMP消息给彼此，消息尅包含音频，视频，数据或者其他消息。

RTMP消息包含连个部分，包头和有效负载。

消息头：

消息包头包含以下：

消息类型：

一个字节的字段用来表示消息类型。1-7类型范围内的ID是被保留用于协议控制消息。

长度：

3个字节的字段用来表示有效负载的长度。

时间戳：

四个字节的长度包含了消息的时间戳，这四个字节被包在一个大比特序列中。

消息流ID：

三个字节的字段标示消息的流，这些字段被设置在一个大比特格式中。

消息有效负载：

有效负载是包含在消息中的实际数据，例如：它可以是一些音频样本或者压缩的视频数据。

协议控制消息：

RTMP位协议控制消息保留了0-7的类型ID，这些消息包含RTMP消息块流协议或者RTMP本生需要的信息。ID是1和2的协议消息被保留用作RTMP消息块流协议的使用，ID是3-6的协议消息被保留用作RTMP的使用，ID是7的协议消息被用在边缘服务和原电服务之间。

协议控制消息必须有消息流ID0（称为控制流）和消息块流ID2，发送时带有最高优先级。

5.设置消息块大小

协议控制消息1，设置消息块大小，用来通知对方新的可供利用的最大的消息块的大小。

消息块大小的值可以负载4个字节的消息负载。消息块的大小可以被设置成一个默认的值，但是客户端或者服务端可以改变这个值，可以给对方更新。例如：假设一个客户端想要发送131字节的音频数据，消息块的大小为128字节，在这种情况下，客户端可以发送这个协议控制消息给服务端以通知消息块的大小被设置成131字节，那么客户端就可以用一个消息块发送音频数据。

最大的消息块大小可以是65536个字节，消息块的大小在服务端与客户端的通信以及客户端到服务端的通信是维持不变的。

中断消息：

协议控制消息2，中断消息，用来向通知对方是否在等待消息块完成一则消息，然后丢弃部分接收到的消息，放弃消息的处理过程，对方接收到要被丢弃的消息的消息块流ID作为协议消息的有效负载，这个消息在发送方已经发送部分消息后发送，但是想要告诉接收方余下的消息不用发送。

消息块流ID（chunk stream id）：32字节

这个字段持有要被丢弃的消息的消息块流ID。

确认（ACK）：

客户端或者服务端当接收到的字节和窗口大小一样时发送确认给对方，窗口大小是发送方发送的在没有从接收方收到确认之前的最大字节数，服务端在应用程序接通后给客户端发送窗口大小，这个消息指定了序

号，就是目前为止收到的字节数。

序号（sequence number）：32比特

这个字段是有到目前为止收到的字节的数量。

5.4.用户控制

客户端或者服务端发送这个消息用来通知对方用户控制事件，这个消息负载事件类型和事件数据，

头两个字节用来标示事件类型，事件数据跟随在事件类型后面，时间数据字段的大小事可变的。5.5 窗口确认大小

客户端或者服务端在发送确认时发送这个消息来告知对方使用的窗口大小。例如：一个服务端期望在服务端发送的字节数和窗口大小一样是每时每刻都收到客户端的确认，服务端在成功处理客户端请求的连接后向客户端更新自己的窗口大小。

5.6设置带宽

客户端或者服务端发送这个消息用来更新对方的输出带宽，输出带宽的值和对方大小一样。如

果自己当前窗口大小和消息中接收到得不一样，对方发送“窗口确认大小“。

发送标记硬（0），软（1），或者动态（2）消息利用有限的类型字段，在硬（0）请求中，对

方必须在提供的带宽上发送数据，在软（1）请求中，带宽在于双发的判断，发送方可以限制

带宽，在动态（2）请求中，带宽可以是硬的或者是软的。

RTMP命令消息

1.介绍

服务端和客户端交换的消息的不同类型包括用于发送音频数据的音频消息，发送视频的数据的视频消息，发送用户数据的数据消息，共享对象消息，和命令消息。共享对象消息一般提供在多个的客户和一个服务段之间管理分布式数据的方法。

命令消息负载客户端个服务端AMF编码命令，一个客户端或者服务端可以在使用命令消息于彼此通信的流觞请求远程调用。

2.定义

消息流：

消息更随的用于通信的逻辑的通道。

消息流ID：

每一个消息有一个分配的ID用来识别此消息属于的消息流。

远程调用（RPC）

一个允许客户端或者服务端调用一个子程序或者进程的请求。

元数据：

关于数据的表述，影片的元数据包括影片标题，持续时间，创造的数据等等。

应用实例：

客户端通过发送连接请求连接服务器的应用程序的实例。

动作消息格式（AMF）

一种简洁的2进制编码用来连续化ActionSctipt对象。

3.消息类型

客户端和服务端在网络上发送消息和彼此通信，这些消息可以使任何类型，包括音频消息，视频消息，命令消息，共享对象消息，数据消息，和用户控制消息。

3.1．命令消息

命令消息负载了在客户端和服务端的AMF编码命令，这些消息在AMF0中被分配的类型值是

20，在AMF3中的值是17.这些消息发送用来运行操作诸如：连接，创造流，发布，播放，暂

停。像onstatus,result这样的命令用来通知发送方需求命令的状态，一个命令消息由命令名称，

处理ID和命令对象，一个客户端或者服务端可以通过命令消息通信的流请求远程进程调用

（RPC）。

3.2.数据消息

客户端或者服务端发送这些消息用来发送元数据和任何给对方的数据，元数据包括数据（音频，

视频等）的详细资料诸如：创造时间，持续时间，主题等等，在AMF0中这些消息被分配的消

息类型值是18，在AMF3中式15.

3．3.共享对象消息

一个共享对象就是一个同步的穿过多个客户、实体等的flash对象，AMF0小红消息类型

kMsgContainer=19，在AMF3中该值为16，这些值被共享对象事件保留。每一个消息可以包含

多个事件。

支持一下时间类型

3.4.音频消息

客户端或者服务端发送这个消息来发送音频数据给对方，音频消息的消息类型值为8是被保留

的。

3.5.视频消息

客户端或者服务端发送这个消息来发送视频数据，视频消息的消息类型值为9是被保留的。这些

很大会延迟其他类型消息的发送。为了阻止如此的情形，视频消息被分配位最低的优先级。

3.6.聚合消息

一个聚合消息是一个单一的包含一队子消息的消息。消息类型是22是被保留的。

The aggregate message formate

后点（back pointer）包括了在自己包头中包含的先前消息的大小。用来匹配FLV文件的格式和回溯搜索。

利用聚合消息会有一些性能上的优势

消息块流可以在一个消息块中发送至少一个完整的消息，这样增加了消息块的大小，利用聚合消息减少了消息块发送的数量。

子消息在内存中连续的存储，当制造系统（making system）呼叫在网络上发送数据时这就显得非常有效率。

3.7.用户控制消息

客户端或者服务端发送这个消息来通知对方用户控制事件。

以下是支持的控制时间类型

4.命令的类型

客户端个服务端交换的命令式用AMF编码的，发送方发送的命令消息由命令名称，处理ID和包含了相对参数的命令对象组成。例如:连接命令包含’app’参数，告诉服务端客户端连接的应用程序的名字。接收到的进程会以相同的处ID发回应答，回应字符可以是_result,_error,_或者一个方法名称（verifyClient 或者contactExternalServer）中的一种.

一个_result或者_error命令字符串发送回应信号，处理ID指示了回应消息中突出的命令，就像IMAP 和许多其他的协议中的标签（tag）一样。在命令字符串中的方法名称代表了发送方试图在接收端运行一个方法（或动作）。

下面的总类对象用来发送多样性命令

NetConnection---一个高层表示在服务端和客户端连接的高层协议。

NetStream---一个表述音视频或者其他流的通道的对象，我们还发送命令像play,pause等等用来

控制数据的流通。

4.1NetConnection命令

Netconnection在在客户端应用程序和服务端之间的双向连接，另外，他支持异步远程方法调用。

下面的命令可以再Netconnection中发送

Connect、call、close、creatStream

4.1.1 connect

客户端向服务端发送连接（connect）命令请求连接一个服务应用实例。以下为命令的结构

以下为在connect命令中用到的name-value pairs（名称值对）的表述。

音频编码的特性值

视频编码特性值

视频功能特性值

对象编码特性值

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

在命令执行过程中消息的流通过程：

客户端向服务端发送连接命令请求与服务端应用实例的连接。

当接收到连接命令后，服务端给客户端发送协议消息“窗口确认大小“，服务端也连接在连接命令中提及到得应用程序。

服务端向客户端发送协议消息“设置同行带宽“。

客户端在受到“设置同行带宽“后向服务端发送“窗口确认大小”。

服务端向客户端发送（streamBegin）。

服务端发送result命令消息向客户端提供链接状态的情报（失败或者成功），这个命令明确了

处理ID（对于连接（connect）命令来说等同于1），这个消息也明确了一些特性，比如Flash

medial

Server的版本，扩展其他连接的能力，级别的信息，编码，表述，对象编码等等。

4.1.2．call

Call方法在接收方运行远程进程，被呼叫的远程进程调用作为call命令的一个参数。

从发送方到接收方的命令格式如下:

回应的命令格式如下：

4.1.3.createStream（创造流）

客户端向服务端发送这个消息来创造一个逻辑的通道以供消息通信，音视频的发布，元数

据在使用createStream命令创建的流通道上实现。

以下是客户端到服务端的发送的命令格式

以下是从服务端到客户端发送的命令格式

rtmp流媒体协议

H5视频直播扫盲 1 H5到底能不能做视频直播 当然可以， H5火了这么久，涵盖了各个方面的技术。 对于视频录制，可以使用强大的webRTC（Web Real-Time Communication）是一个支持网页浏览器进行实时语音对话或视频对话的技术，缺点是只在PC的chrome上支持较好，移动端支持不太理想。 对于视频播放，可以使用HLS(HTTP Live Streaming)协议播放直播流，ios和android都天然支持这种协议，配置简单，直接使用video标签即可。 webRTC兼容性： video标签播放hls协议视频：

1 2 3 4

Your browser does not support HTML5 video. 2 到底什么是HLS协议 简单讲就是把整个流分成一个个小的，基于HTTP的文件来下载，每次只下载一些，前面提到了用于H5播放直播视频时引入的一个.m3u8的文件，这个文件就是基于HLS协议，存放视频流元数据的文件。 每一个.m3u8文件，分别对应若干个ts文件，这些ts文件才是真正存放视频的数据，m3u8文件只是存放了一些ts文件的配置信息和相关路径，当视频播放时，.m3u8是动态改变的，video标签会解析这个文件，并找到对应的ts文件来播放，所以一般为了加快速度，.m3u8放在web服务器上，ts文件放在cdn上。 .m3u8文件，其实就是以UTF-8编码的m3u文件，这个文件本身不能播放，只是存放了播放信息的文本文件： 1 2 3 4 5#EXTM3U m3u文件头 #EXT-X-MEDIA-SEQUENCE 第一个TS分片的序列号#EXT-X-TARGETDURATION 每个分片TS的最大的时长#EXT-X-ALLOW-CACHE是否允许cache #EXT-X-ENDLISTm3u8文件结束符

rtmp协议

RTMP：Real Time Messaging Protocol 实时消息传送协议 字节序：大端 Message Format： Timestamp：4 bytes Length：3 bytes Type ID：1 bytes Message Stream ID：4 bytes 小端 Handshake three static_sized chunks client：C0 C1 C2 server：S0 S1 S2 simple handshake： handshake sequence 握手开始于客户端发送C0、C1块 客户端在发送C2块之前必须等待直到S1块被接收 客户端在发送任何其他数据之前必须等待直到S2块被接收 服务器在发送S0、S1之前必须等待直到C0被接收或是C1被接收服务器在发送S2之前必须等待直到C1被接收 服务器在发送任何其他数据之前必须等待直到C2被接收 C0和S0格式 一个字节（8bits） 本版本是3 C1和S1格式 1536个字节

C2和S2格式 1536个字节，是C1和S1的回复响应 time：必须包含对等段发送的时间戳（对C2来说是S1，对S2来说是C1）time2：必须包含先前发送的被对端读取的包（S1或C1）的时间戳 handshake diagram

Complete handshake Chunking Chunk format A header and data +--------------+----------------+--------------------+----------+ | Basic Header | Message Header | Extended Timestamp | Chunk Data| +--------------+----------------+--------------------+----------+ | | |<------------------- Chunk Header ----------------->| Chunk Format Basic header：1-3bytes，chunk stream ID and chunk type(fmt) 长度可变type depend on the format of the encoded message header the length depend on the chunk stream ID ID:3-65599,0\1\2 reserved 0:2bytes,ID range 64-319 (the second byte+64) 1:3bytes,ID range 64-65599(the third byte*256+the second byte+64) 2:low-level protocol 2-63: 64-319:

RTMP协议

RTMP Protocol Connect NetConnect.connect() Flash Play 通过NetConnect.connect连接到RTMP Server时,首先进行握手,再发送connect的参数. 1) 握手过程有三步: Step 1, Flash Player 至RTMP Server : 1个byte(0x03)+1536个byte数据. Step 2, RTMP Server至Flash Player : 1个byte(0x03)+1536个byte数据(Server的握手数据) + 1536个byte数据(通过和随机数hash得出, 详见附录) Step 3, Flash Player 至RTMP Server : 1536个byte数据(RTMP Server计算出来的). 注意:这个数据块没有1个byte的0x03. 2) 接下是connect参数 RTMP Server <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

RTMP Server >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Flash Player RTMP协议步骤 Step 1 发送一个0x05的包,即ServerBW, (channel 0x02) (0x00 26 25 a0) Step 2 发送一个0x06的包,即ClientBW, (channel 0x02) (0x00 26 25 a0) + (0x02) Step 3 发送一个0x14的包,即Invoke, (channel 0x03) (body超过128的长度就要分包, 用0xc3来) string (“_result”) + number (0x3F F0 00 00 00 00 00 00) + Object string (“capabilities”) ; number (31.0) string (“fmsV er”) ; string (随便填) (“RubyIZUMI/0,1,2,0”) End Of Object (0x00 00 09) //(connect status) + Object string (“code”) ; string (“NetConnection.Connect.Success”) string (“level”) ; string (“status”) string (“description”) ; string (“Connection Succeeded.”) End Of Object (0x00 00 09) RTMP Server <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

课题_nginx搭建rtmp协议流媒体服务器总结

nginx搭建rtmp协议流媒体服务器总结 最近在ubuntu12.04上搭建了一个rtmp服务器，感觉还挺麻烦的，所以记录下。 大部分都是参考网络上的资料。 前提： 在linux下某个目录中新建一个nginx目录。 然后进入该目录去下载搭建环境所需要的一些资源包。 此处在/root/ 目录下新建一个nginx目录即： /root/nginx/ ==================================== 1、安装依赖包: #yum -y install gcc glibc glibc-devel make nasm pkgconfig lib-devel openssl-devel expat-devel gettext-devel libtool mhash.x86_64 perl-Digest-SHA1.x86_64 2、安装相关工具包 1). git # mkdir soft-source # cd soft-source # wget ://https://www.doczj.com/doc/3b14763376.html,/projects/git-snapshots/git/git-latest.tar.xz # xz -d git-latest.tar.xz # tar xzvf git-latest.tar # cd git-2014-06-27 # autoconf # ./configure # make && make install # git --version git version 2.0.0.GIT # cd .. 2). zlib # wget ://https://www.doczj.com/doc/3b14763376.html,/zlib-1.2.8.tar.gz # tar -zxvf zlib-1.2.8.tar.gz cd zlib-1.2.8 # ./configure # make # make install # cd .. 3). pcre # wget ://exim.mirror.fr/pcre/pcre-8.12.tar.gz # tar zxvf pcre-8.12.tar.gz # cd pcre-8.12 # ./configure # make && make install # cd .. 4). yadmi yadmi的作用是为flv文件添加关键帧，才能实现拖动播放 # wget ://https://www.doczj.com/doc/3b14763376.html,/projects/yamdi/files/yamdi/1.4/yamdi-1.4.tar.gz/download # tar xzvf download # cd yamdi-1.4 # make && make install # cd .. 使用方法： # yamdi -i input.flv -o out.flv 给input.flv文件添加关键帧，输出为out.flv文件 5). OpenSSL # wget ://https://www.doczj.com/doc/3b14763376.html,/source/openssl-1.0.1c.tar.gz # tar -zxvf openssl-1.0.1c.tar.gz # ./config # make # make install 3、安装ffmpeg及其依赖包： 1). Yasm # wget ://https://www.doczj.com/doc/3b14763376.html,/projects/yasm/releases/yasm-1.2.0.tar.gz # tar xzvf yasm-1.2.0.tar.gz

实时流煤体协议概述v1.0

实时流煤体协议概述v1.0

实时流煤体协议概述 流媒体传输类型： 流媒体传输分两类：实时流媒体和顺序流媒体 一般来说，如果视频为现场直播，或使用专用的流媒体服务器，或应用如RTSP等专用实时协议，即为实时流媒体传输； 如果使用普通的HTTP服务器，将音视频数据以从头至尾方式发送，则为顺序流媒体传输。 实时流传输既可传输实况直播，也可传输完整的音视频文件（专用协议流式）。 顺序流媒体不可用于实况直播，仅能传输完整的音视频文件（HTTP渐进式）。 主流的流媒体协议 主流的流媒体协议主要有：RTMP，HLS，RTSP等。

附：流媒体播放实现流程 一，h ttp渐进式下载原理（仅支持文件播放）http边下载边播放，严格意义上讲，不是实况直播协议。他的原理是先下载文件的基本信息，音频视频的时间戳，再下载音视频数据，以播放mp4为例，先下载文件头，根据文件头指引下载文件尾，然后再下载文件的音视频数据。 播放方式：1. 浏览器调用系统播放器播放； 2. 使HTML5的Video标签，浏览器内部支持直接播放。

二，苹果支持的hls原理（支持文件播放和实况直播）HLS的文件点播 1.使用“文件分段器”将基于H264和AAC或MP３的MPEG4分段， 生成.ts和.m3u8文件，存储于普通服务器上。 2.苹果应用程序或苹果浏览器可以通过访问.m3u8文件获取到索引， 并下载所需要的数据片段来播放。 HLS的实况直播 1.使用“流分段器”将基于H264、AAC、MP3的MPEG2传输 流分段， 2.可使用其它工具将MPEG4音视频文件加载到MPEG2传输流当中。 3.生成.ts和.m3u8文件，存储于普通服务器上。 4.苹果应用程序或苹果浏览器可以通过访问.m3u8文件获取到索引， 并下载所需要的数据片段来播放。 三，A dobe Flash 支持的RTMP协议（支持文件播放和实况直播） 必须采用Flash服务器FMS(Flash Media Server) 或 RED5. FMS的文件点播 1. 服务器（FMS或RED5）将F4v 或 Flv文件转化为RTMP流或HTTP流 2. 客户端（Flash插件或应用程序）获取RTMP流，提取相应的Flv 或 F4v文件片段进行播放。 FMS的实况直播 1.设备端（摄像头）将数据转化为F4v片段，通过RTMP流上传到服务器 2. 服务器（FMS或RED5）转发RTMP流到客户端 3. 客户端（Flash插件或应用程序）获取RTMP流，提取数据片段播放。 四，R TSP协议 RTSP为纯粹的传输控制协议。 RTSP协议本身不与它负载的媒体数据相关。 RTSP协议需要自定义客户端向服务器发送RTSP命令。

PANABIT支持协议库

Panabit V9.08（战国r3）专业版支持协议列表 (2009.10.16) 类别 应用协议 客户端 发布日期 版本号/注释 HTTP协议 WWW Web音乐 FLASH HTTP代理 HTTP下载 HTTP分块传输 伪IE下载 其他下载主要是“另存为” 土豆网https://www.doczj.com/doc/3b14763376.html, Web视频 酷6 https://www.doczj.com/doc/3b14763376.html, 6间房 https://www.doczj.com/doc/3b14763376.html, 优酷https://www.doczj.com/doc/3b14763376.html, Youtube https://www.doczj.com/doc/3b14763376.html, HULU网https://www.doczj.com/doc/3b14763376.html, 我乐网https://www.doczj.com/doc/3b14763376.html, Sina视频https://www.doczj.com/doc/3b14763376.html, Sohu视频 腾讯宽频 波波虎https://www.doczj.com/doc/3b14763376.html, 其他Web视频 凤凰网https://www.doczj.com/doc/3b14763376.html, CCTV点播https://www.doczj.com/doc/3b14763376.html, Viewgood https://www.doczj.com/doc/3b14763376.html, 常用协议 电子邮件 SMTP POP3 IMAP 终端类 VNC PCAnyWhere SSH Telnet 远程桌面 文件传输 FTP TFTP RSync 缺省端口873 NFS

CVS MSDS Microsoft-DS DNS DHCP NNTP SNMP NTP UPNP NETBIOS DAYTIME 端口为13 SYSLOG 缺省端口514 DECRPC LDAP NAT端口映射 网络管理 ISA控制协议 HTTPS Socks4/5 L2TP PPTP IPSEC GRE 网络安全 OpenVPN 360更新 Nod32更新 Windows更新 软件更新 卡巴斯基更新 流媒体协议 RTSP MMS QuickTime QuickTime 7 Windows MediaPlayer Windows MediaPlayer 11 Real Player Real Player 11 BBSee 1.3 磊客https://www.doczj.com/doc/3b14763376.html, 新浪奥运视频 网易奥运视频 QQ奥运视频 CCTV央视高清 RTMP P2P下载 BitComet 2009.06.22 1.13 BT BitSpirit 2009.07.27 V 3.6.0.135

RTSP协议转换RTMP直播协议

RTSP协议转换RTMP直播协议 RTSP协议也是广泛使用的直播/点播流媒体协议，最近实现了一个RTSP协议转换RTMP直播协议的程序，为的是可以接收远端设备或服务器的多路RTSP直播数据，实时转换为RTMP直播协议，推送到FMS、Red5、wowza server等RTMP 服务器，以实现flash观看RTSP直播源的需求。程序同时也具备从FLV文件获取输入数据并转换RTMP直播。实现的思路分享如下。 要点分析 首先，程序的主要目的，是从多路RTSP输入源中提取AAC编码的音频和H.264编码视频数据，并生成RTMP数据包，然后组装RTMP推送协议，并发往RTMP 服务器。在发送的过程中，要求可以从RTSP数据源切换到具有相同h.264和aac 编码的FLV文件中，并不影响RTMP直播。因此，本程序的关键点有以下部分： 1.RTSP直播流的读取 2.H.264和AAC编码数据的分析、处理 3.FLV文件数据的提取及与RTSP直接的切换和衔接 4.RTMP数据包封装 5.RTMP推送协议 有了关键点，就可以一项一项的去分析。 设计思路 根据上面分析的要点，首先要选择RTSP直播协议的读取。我们不需要从零做起，网络上有很多和RTSP相关的开源项目可以使用或借鉴，我选择了Live555。 Live555是一个跨平台的流媒体解决方案，主要支持RTSP协议，好像也支持SIP（这个也是我马上研究的重点，之后会写文章研究SIP相关的技术实现）。Live555实现了RTSP包括服务器-客户端的整套结构，是很知名的一个开源项目。网上有很多关于Live555学习和使用的文章，我就不具体介绍了。

flex视频播放器(支持rtmp协议)开发代码

Flex视频播放器(支持rtmp协议)开发代码 开发工具:flash builder4.5 + red5服务器 建议参考之前阶段代码: (1)flex视频播放器开发初级阶段代码:https://www.doczj.com/doc/3b14763376.html,/detail/ll_jj_yy/ (2)支持rtmp协议,播放red5服务器上的flv视频文件. 直接来代码:

RTSP协议转换RTMP直播协议

RTSP协议转换RTMP直播协议

RTSP协议转换RTMP直播协议 RTSP协议也是广泛使用的直播/点播流媒体协议，最近实现了一个RTSP协议转换RTMP直播协议的程序，为的是可以接收远端设备或服务器的多路RTSP 直播数据，实时转换为RTMP直播协议，推送到FMS、Red5、wowza server等RTMP 服务器，以实现flash观看RTSP直播源的需求。程序同时也具备从FLV文件获取输入数据并转换RTMP直播。实现的思路分享如下。 要点分析 首先，程序的主要目的，是从多路RTSP输入源中提取AAC编码的音频和H.264编码视频数据，并生成RTMP数据包，然后组装RTMP推送协议，并发往RTMP服务器。在发送的过程中，要求可以从RTSP数据源切换到具有相同h.264和aac 编码的FLV文件中，并不影响RTMP直播。因此，本程序的关键点有以下部分： 1.RTSP直播流的读取 2.H.264和AAC编码数据的分析、处理 3.FLV文件数据的提取及与RTSP直接的切换和衔接 4.RTMP数据包封装 5.RTMP推送协议 有了关键点，就可以一项一项的去分析。 设计思路 根据上面分析的要点，首先要选择RTSP直播协议的读取。我们不需要从零做起，网络上有很多和RTSP相关的开源项目可以使用或借鉴，我选择了Live555。 Live555是一个跨平台的流媒体解决方案，主要支持RTSP协议，好像也支持SIP（这个也是我马上研究的重点，之后会写文章研究SIP相关的技术实现）。Live555实现了RTSP包括服务器-客户端的整套结构，是很知名的一个开源项目。

网上有很多关于Live555学习和使用的文章，我就不具体介绍了。 H.264和AAC数据的分析处理，这个对于从没做过相关项目开发的人来说，应该是一个难点，主要是相关概念的理解。好在我一直在做这块，也比较好弄。 第4和第5点，可以参照文章“RTMP协议发送H.264编码及AAC编码的音视频（https://www.doczj.com/doc/3b14763376.html,/haibindev/archive/2011/12/29/2305712.html），实现摄像头直播”的技术方法，来加以实现。因此，主要需要处理的就是RTSP 直播流数据的获取，以及对其中H.264和AAC编码数据的处理。 于是可以画出大体结构如下： RtmpThread的主要工作就是发送音频数据流的解码信息头和视频数据流的解码信息头，并不断从DataBufferQueue中取出数据，封装为RTMP Packet，发送出去。流程如下列代码所示：（process_buf_queue_，即是上图中的DataBufferQueue）

RTMP头RTMP协议封包 参考Red5

RTMP头RTMP协议封包参考Red5 RTMP协议封包由一个包头和一个包体组成,包头可以是4种长度的任意一种:12, 8, 4, 1 byte(s).完整的RTMP包头应该是12bytes,包含了时间 戳,AMFSize,AMFType,StreamID信息, 8字节的包头只纪录了时间 戳,AMFSize,AMFType,其他字节的包头纪录信息依次类推。包体最大长度默认为128字节,通过chunkSize可改变包体最大长度,通常当一段AFM数据超过128字节后,超过128的部分就放到了其他的RTMP封包中,包头为一个字节. 完整的12字节RTMP包头每个字节的含义: 用途大小(Byte)含义 Head_Type1包头 TiMMER3时间戳 AMFSize3数据大小 AMFType1数据类型 StreamID4流ID 一、Head_Type 第一个字节Head_Type的前两个Bit决定了包头的长度.它可以用掩码0xC0进行"与"计算: Head_Type的前两个Bit和长度对应关系： Bits Header Length 0012 bytes 018 bytes 10 4 bytes 11 1 byte Head_Type的后面6个Bit和StreamID决定了ChannelID。 StreamID和ChannelID对应关系：StreamID=(ChannelID-4)/5+1 参考red5 ChannelID Use 02Ping 和ByteRead通道 03Invoke通道我们的connect() publish()和自字写的NetConnection.Call() 数据都

RTMP协议

RTMP协议介绍 一．概述 RTMP是Real Time Messaging Protocol（实时消息传输协议）的首字母缩写。该协议基于TCP，是一个协议族，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP 是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括Adobe Media Server/Ultrant Media Server/red5等。 RTMP又是Routing Table Maintenance Protocol（路由选择表维护协议）的缩写。在AppleTalk 协议组中，路由选择表维护协议（RTMP，Routing Table Protocol）是一种传输层协议，它在AppleTalk 路由器中建立并维护路由选择表。RTMP 基于路由选择信息协议（RIP）。正如RIP 一样，RTMP 使用跳数作为路由计量标准。一个数据包从源网络发送到目标网络，必须通过的路由器或其它中间介质节点数目的计算结果即为跳数。 RTMP(Real Time Messaging Protocol)实时消息传送协议是Adobe Systems公司为Flash 播放器和服务器之间音频、视频和数据传输开发的开放协议。 它有多种变种： 1)RTMP工作在TCP之上，默认使用端口1935； 2)RTMPE在RTMP的基础上增加了加密功能； 2)RTMPT封装在HTTP请求之上，可穿透防火墙； 3)RTMPS类似RTMPT，增加了TLS/SSL的安全功能； 二．协议介绍 RTMP协议(Real Time Messaging Protocol)是被Flash用于对象,视频,音频的传输.这个协议建立在TCP协议或者轮询HTTP协议之上. RTMP协议就像一个用来装数据包的容器,这些数据既可以是AMF格式的数据,也可以是FLV中的视/音频数据. 一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的. 网络连接(Connection)

Rtmp协议中文介绍

RTMP（real time messaging protocol）协议 1，介绍 这篇文档详细说明了RTMP消息块流，它位高层多媒体流协议提供多路技术和包服务 RTMP消息块流是为RTMP协议设计的，他可以处理任何传送消息流的协议，每一个消息包含时间戳合有效负载类型标示，RTMP消息块流和RTMP一起适用于多样性音视频应用程序，从一对一和一对多向视频点播服务器直接广播到交互式会议应用程序。 当用到实时传输协议就像TCP，RTMP消息块流提供可靠地规则时间戳的端到端全信息传送。穿过多层流，RTMP消息块流不提供任何控制的优先级别和相似形式，但是可以用于高层协议提供这样的优先级，例如：一段实时视频服务会选择丢弃给于缓慢的客户的视频信息确保音频信息可以及时被接收。 RTMP消息块流包含它自己的入队协议控制消息，也提供一个高层协议机制用于嵌入用户的控制消息。 2.定义 有效负载： 包含在包中的数据，就像音频样本或者压缩的视频数据。 包： 一个数据包由固定的包头和有效负载数据组成，一些底层协议或许需要包的封装来被定义。 端口： 在TCP/ＩP协议中定义的用正整数表示的端口号用于在传输中提取以区分目标主机的不同应用，用于OSI传输层的传输选择（TSEL）就是端口。 传输地址： 网络地址和端口的组合识别一个传输层终端端口，例如一个IP地址和TCP端口，数据包从一个源传输层地址传送到目标段的传输层地址。 消息流： 一个通信的逻辑通道，允许消息流通。 消息流ID： 每一个消息拥有一个分配的ID识别跟随的消息流。 消息块： 消息的片段，消息被分成小的部分，在他们在网络中发送之前交叉存储。消息块确保定制时间戳的端到端全消息传送，穿过多层流。 消息块流： 一个通信的逻辑通道，允许消息块在一个特定的方向上流通，消息块流可以从客户端传送到服务器，也可以相反。 消息块流ID： 每一个消息块有一个分配的ID用于识别更随的消息块流。 复合技术： 把分开的音视频数据组合成一条音视频流的过程，使同时传送许多音视频数据成为可能。 逆复合技术： 复合的反向过程，交叉存取组装的音频视频数据，使他们成为最初的音视频数据 3．字节顺序，列队和时间格式 所有的整数字段有被网络字节负载着，字节0是第一个显示出来的，也是一段文字和字段中最重要的。 这种字节顺序一般被认为“大字节“，数字常量在这种文档里是用十进制表示。 所有RTMP消息块流是以用字节列队，例如：一个16字节的字段也许会在字数字节的偏移段。那里要填充被标示，填充字节应该有0值（似乎看不懂）. 在RTMP消息块流中的时间戳用整数表示，单位为毫秒。每一个消息块流以时间戳0开始，但是这不是必须的，只要两个终端在时间点上达成一致，注意那就意味着任何穿过多消息块流异步传输（特

rtp协议,端口

竭诚为您提供优质文档/双击可除 rtp协议,端口 篇一：实时传输协议Rtp 实时传输协议Rtp 1.Rtp协议： Rtp（Real-timetransportprotocol）协议最初是在70 年代为了尝试传输声音文件，把包分成几部分用来传输语音，时间标志和队列号。经过一系列发展，Rtp第一版本在1991年8月由美国的一个实验室发布了。到本世纪1996年形成 了标准的的版本。很多著名的公司如netscape,就宣称“netscapelivemedia”是基于Rtp协议的。microsoft也宣称他们的“netmeeting”也是支持Rtp协议. Rtp被定义为传输音频、视频、模拟数据等实时数据的 传输协议。最初设计是为了数据传输的多播，但是它也用于单播的。与传统的注重的高可靠的数据传输的运输层协议相比，它更加侧重的数据传输的实时性。此协议提供的服务包括时间载量标识、数据序列、时戳、传输控制等。Rtp与辅 助控制协议Rtcp一起得到数据传输的一些相关的控制信息。 2．Rtp协议的工作原理：

如上所说明的，影响多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。Rtp协议就是提供了时间标签,序列号以及其它的结构用于控制适时数据的流放。 在流的概念中‘时间标签’是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始 的适时的数据。不同的媒体格式调时属性是不一样的。但是Rtp本身并不负责同步，Rtp只是传输层协议，为了简化了 运输层处理，提高该层的效率。将部分运输层协议功能（比如流量控制）上移到应用层完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能，不提供任何机制来保证实时地传输数据，不支持资源预留，也不保证服务质量。Rtp报文甚至不包括长度和报文边界的描述。同时Rtp协议 的数据报文和控制报文的使用相邻的不同端口，这样大大提高了协议的灵活性和处理的简单性。 Rtp协议和udp二者共同完成运输层协议功能。udp协 议只是传输数据包，是不管数据包传输的时间顺序。Rtp的 协议数据单元是用udp分组来承载的。在承载Rtp数据包的时候，有时候一帧数据被分割成几个包具有相同的时间标签，则可以知道时间标签并不是必须的。而udp的多路复用让Rtp 协议利用支持显式的多点投递，可以满足多媒体会话的需求。

RTMP协议详解

Real Time Messaging Protocol（实时消息传送协议协议)是Adobe Systems 公司为Flash播放器和服务器之间音频、视频和数据传输开发的私有协议。 具体使用RTMP的AS代码大概如下： var videoInstance:Video = your_video_instance; var nc:NetConnection = new NetConnection(); var connected:Boolean = nc.connect("rtmp://localhost/myapp"); var ns:NetStream = new NetStream(nc); videoInstance.attachVideo(ns); ns.play("flvName"); Adobe也在官方网站已经提供了RTMP协议的官方文档说明，为什么要写这个系列文章最大的原因只是对前一段工作的一个总结和回顾，最近两个月，实现了一个RTMP Server的c++版本，把公司的流媒体服务和flash无缝对接起来。希望我的文字能给后来研究这个协议的同学有一定的帮助。 RTMP协议是一个基于TCP的高层协议族，当然这个玩意据说还有UDP协议版本的，不过现在还没有出来，好像Adobe下一版本的FMS会提供支持。下文将要描述的是TCP协议版本的协议。 RTMP协议的概要理解： RTMP协议是为了和flash之间交换信令以及媒体数据。为了提高使用效率信令和媒体数据都是使用相同的机制。因为是相同的机制Adobe就整出来了一些比较搞人的概念，当然每个协议第一次接触都是比较难理解的。 在RTMP协议中信令和媒体数据都称之为Message，在网络中传输这些Message，为了区分它们肯定是要加一个Message head的，所以RTMP协议也有一个Message head，还有一个问题因为RTMP协议是基于TCP的，由于TCP的包长度是有限制的（一般来说不超过1500个字节），而RTMP的Message长度是有可能很大的，像一个视频帧的包可能会有几十甚至几千K，这个问题就必然有一

RTMP协议简介

专题报告：RTMP 协议

目录 专题报告：RTMP协议 (1) 一：什么是rtmp (3) 二：RTMP消息格式 (5) 三：RTMP握手过程 (10) 三．协议控制消息 (21) 四：消息交换的例子 (25)

写在前面红色字体是重点必读，蓝色字体是分点便于区分，绿色字体是次分点便于区分一：什么是rtmp

RTMP协议 Real Time Messaging Protocol（实时消息传送协议协议)实时消息传送协议是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的私有协议。它有三种变种： 1)工作在TCP之上的明文协议，使用端口1935； 2)RTMPT封装在HTTP请求之中，可穿越防火墙； 3)RTMPS类似RTMPT，但使用的是HTTPS连接； 介绍: RTMP协议是被Flash用于对象,视频,音频的传输.该协议建立在TCP协议或者轮询HTTP协议之上. RTMP协议就像一个用来装数据包的容器,这些数据可以是AMF格式的数据,也可以是FLV中的视/音频数据. 一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的. RTMP中定义了两种通信单元：消息（message）和消息块（chunk）.RTMP消息是协议中实现各种流媒体控制和应用的基本逻辑信息单元，消息从种类上可以分为协议控制消息、用于发送音频数据的音频消息、用于发送视频数据的视频消息、发送用户数据的数据消息、共享对象消息以及命令消息，属于相同逻辑通道的消息组成一个消息流，这个逻辑通道通过消息格式中的“消息流ID”字段来标识。 作为应用层协议，RTMP协议架构在TCP层之上，但RTMP消息并不是直接封装在TCP中，而是通过一个被称为消息块的封装单元进行传输。消息在网络上发送之前往往要分割成多个较少的部分，这些较小的部分就是消息块，属于不同消息流的消息块可以在网络上交叉发送。这样做可以保证各个消息流中的高优先级消息块能够严格按照时间顺序达到通信的对端。比如某个较长消息的实时性要求比较低，如果不进行消息块处理，等长消息都发送完毕后再发送实时性要求高的短消息，则会对流媒体的播放质量造成影响。