rtmp协议(rtmp协议详解中文版)

RTMP协议（四）消息格式与类型

在介绍 RTMP 的分块与块包装中已经介绍过块（ Chunk ）的格式，消息（ Message ）的格式也是被封装其中。消息的格式如下：

客户端和服务端通过网络使用 RTMP 块流协议发送 RTMP 消息来进行通信，该消息可以是任何类型，包含音频消息、视频消息、命令消息、共享对象消息、数据数据以及用户控制消息。本篇将主要介绍不同消息类型下不同的消息数据格式。

协议控制消息（ Protocol Control Messages ）用于客户端或服务端对协议相关属性（比如块大小、窗口大小和流带宽）进行配置，其消息类型为 1 、 2 、 3 、 5 和 6 。在两端进行音频、视频或信息数据传输前，两端都需要使用协议控制消息来 保证RTMP 块流协议所需的基本信息统一 。

协议控制消息 1，设置块大小（ Set Chunk Size ），客户端和服务端发送此消息来修改当前最大的块大小，默认最大的块大小为 128 字节。

例如，假设客户端想要发送的音频数据大小为131 字节，而块大小为 128 字节。在这种情况下，客户端可以通知服务器新的块大小为 131 字节，然后就可以使用一个块来发送完整的音频数据了。下面是其消息数据的格式：

协议控制消息 2，中断消息（ Abort Message ），客户端和服务端发送此消息通知对端当前某个块流ID正在传输的消息没有必要再处理了。若已接收块的部分信息，则可以直接丢弃此部分信息。下面是其消息数据的格式：

协议控制消息 3，应答（ Acknowledgement ），客户端和服务端必须在接收完与窗口大小相等的字节数据量后发送一个应答消息给对端。下面是其消息数据的格式：

协议控制信息 5，应答窗口大小（ Window Acknowledgement Size ），客户端和服务端发送这个消息来通知对端应答窗口的大小。下面是其消息数据的格式：

协议控制信息 6，配置流带宽（ Set Peer Bandwidth ），客户端和服务端发送此消息来说明对方的输出带宽限制。接收方以此来限制自己的输出带宽，即限制未被应答的消息数据大小。接收到此消息的一方，如果窗口大小与上次发送的不一致，应该回复应答窗口大小的消息。下面是其消息数据的格式：

用户控制事件消息（ User Control Message Events ）的消息类型为 4， 包含 RTMP 流传输层所使用的信息 ，客户端或服务端发送这个消息来通知对端操作事件。下面是其消息数据的格式：

命令消息（ Command Message ）用于在客户端和服务端传递 AMF 编码的命令。??消息类型为 ?? 20 表示进????行 AMF0 编码，消息类型为?? 17 表示进????行 AMF3 编码????。

RTMP 通过发送命令消息命令对端进行特定操作，比如 connect 、 createStream 、 publish 、 play 、 pause 。

命令消息大致分为两种，一种是用于发送者向接受者发送命令，这种命令信息由命令名( Command Name )、事务ID( Transaction ID )和相关参数的命令对象组成( Command Object 和命令自身所需其他参数)。另一种是用于通知发送者请求的命令状态，比如 onstatus 、 result 和 error 等等。

因此，通过命令消息，客户端或服务端可以通过与对端通信的流进行远程方法调用（RPC）。

数据消息（ Data Message ）用于客户端或服务端通过数据消息来发送元数据或任何用户数据到对端。消息类型为18 用于 AMF0 编码，消息类型为 15 用于 AMF3 编码。

共享对象消息（ Shared Object Message ），用于客户端和服务端同步共享对象的参数值。消息类型 19 用于 AMF0 编码，消息类型 16 用于 AMF3 编码。下面是共享消息的格式：

每个共享对象消息可以包含不同的事件，其支持的 事件类型 如下：

音频消息（ Audio Message ），用于客户端或者服务端通过音频消息发送音频数据到对端，其消息类型为 8。

视频消息（ Video Message ），用于客户端或者服务端通过视频消息发送视频数据到对端，其消息类型为 9。

聚集消息（ Aggregate Message ）是一个包含一系列 RTMP 消息的消息，用于连续发送消息，其消息类型为 22。其结构如下所示：

信息数据主体构造如下：

集合消息的优势 ：

rtmp协议详解

rtmp连接从握手开始。它包含三个固定大小的块。客户端发送的三个块命名为c0,c1,c2;服务端发送的三个块命名为S0,S1,S2。

握手序列:

764 bytes digest 结构：

version(1byte):版本。在C0包内，这个字段代表客户端请求的RTMP版本号。在S0包内，这个字段代表服务端选择的RTMP版本号。当前使用的版本是3。在版本0-2用在早期的产品中，如今已经弃用；版本4-31被预留用于后续产品；版本32-255（为了区分RTMAP协议和文本协议，文本协议通常是可以打印字符)不允许使用。如果服务端无法识别客户端的版本号，应该回复版本3。客户端可以选择降低到版本3，或者终止握手过程。

包含chunk stream ID(流通道id)和chunk type(即fmt), chunk stream id 一般被简写为CSID，用来唯一标识一个特定的流通道，chunk type决定了后面的Message Header的格式。Basic Header的长度可能是1，2，或者3个字节，其中chunk type的长度是固定的（占2位，单位是bit)，Basic Header的长度取决于CSID的大小，在足够存储这两个字段的前提下最好使用最少的字节从而减少由于引入Header增加的数据量。

RTMP协议支持用户自定义[3,65599] 之间的 CSID，0, 1, 2 由协议保留表示特殊信息。0 代表 Basic Header 总共要占用 2 个字节，CSID 在 [64,319] 之间; 1 代表占用 3 个字节，CSID 在 [64,65599] 之间; 2 代表该 chunk 是控制信息和一些命令信息。

包含了要发送的实际消息（可能是完整的，也可能是一部分）的描述消息。Message Header的格式和长度取决于Basic Header的chunk type，即fmt，共有四种不同的格式。其中一种格式可以表示其他三种表示的所有数据，但由于其他三种格式是基于对之前chunk的差量化的表示，因此可以更简洁地表示相同的数据，实际使用的时候还是应该采用尽量少的字节表示相同意义的数据。下面按字节从多到少的顺序分别介绍这四种格式的 Message Header。

type=0时Message Header占用11个字节，其他三种能表示的数据它都能表示，但Chunk stream的开始第一个chunk和头信息中时间戳后退（即值与上一个chunk相比减少，通常在回退播放的时候会出现这种情况）的时候必须采用这种格式。

type为1时占用7个字节，省去了表示message stream id的4个字节，表示此chunk和上一次发的chunk所在的流相同，如果在发送端和对端有一个流链接的时候可以尽量采用这种格式。

type 为 2 时占用 3 个字节，相对于 type = 1 格式又省去了表示消息长度的3个字节和表示消息类型的1个字节，表示此 chunk和上一次发送的 chunk 所在的流、消息的长度和消息的类型都相同。余下的这三个字节表示 timestamp delta，使用同type=1。

type=3时，为0字节，表示这个chunk的Message Header和上一个是完全相同的。当它跟在type=0的chunk后面时，表示和前一

个 chunk 的时间戳都是相同。什么时候连时间戳都是相同呢？就是一个 Message 拆分成多个 chunk，这个 chunk 和上一个 chunk 同属于一个 Message。而当它跟在 type = 1或 type = 2 的chunk后面时的chunk后面时，表示和前一个 chunk的时间戳的差是相同的。比如第一个 chunk 的 type = 0，timestamp = 100，第二个 chunk 的 type = 2，timestamp delta = 20，表示时间戳为 100 + 20 = 120，第三个 chunk 的 type = 3，表示 timestamp delta = 20,时间戳为 120 + 20 = 140。

在 chunk 中会有时间戳 timestamp 和时间戳差 timestamp delta，并且它们不会同时存在，只有这两者之一大于3字节能表示的最大数值 0xFFFFFF ＝ 16777215 时，才会用这个字段来表示真正的时间戳，否则这个字段为 0。扩展时间戳占 4 个字节，

能表示的最大数值就是 0xFFFFFFFF ＝ 4294967295。当扩展时间戳启用时，timestamp字段或者timestamp delta要全置为1，而不是减去时间戳或者时间戳差的值。

最后实际发送的chunk如下面表格所示，该表格展示了由此音频流产生的块信息。从第 3 条信息开始，数据传输达到最大优化。每条消息的头部只增加了 1 字节长度。

在网络直播中什么叫推流？

推流，指的是把采集阶段封包好的内容传输到服务器的过程。其实就是将现场的视频信号传到网络的过程。“推流”对网络要求比较高，如果网络不稳定，直播效果就会很差，观众观看直播时就会发生卡顿等现象，观看体验很是糟糕。

要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。常用的流传输协议有RTSP、RTMP、HLS等，使用RTMP传输的延时通常在1_3秒，对于手机直播这种实时性要求非常高的场景，RTMP也成为手机直播中最常用的流传输协议。最后通过一定的Qos算法将音视频流数据推送到网络断，通过CDN进行分发。

扩展资料：

直播中使用广泛的“推流协议”一般是RTMP（RealTimeMessagingProtocol——实时消息传输协议）。该协议是一个基于TCP的协议族，是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括AdobeMediaServer/UltrantMediaServer/red5等。

在高精尖沙龙直播中，最初使用传统设备进行“推流”。

具体过程就是：通过网线将EFP系统中的切换台、网络编码器、笔记本按顺序连接，连接完成后确保笔记本电脑的IP地址和网络编码器的地址在同一网段，然后在电脑页面上对编码器的各种“推流参数”进行调整，为保证正常“推流”，还需设置网络推流地址，输入推流地址、直播地址、视频模式、分辨率、码率、播放域名、播放地址等内容。设置完毕后确认IP地址，再进行网络测速，并确保网络与网络编码器连接正常。此种“推流”所需设备过多，出现问题后十分麻烦，需要对设备进行逐一排查，极耗费时间。

后来，将直播系统改为Livestudio系统，“推流”内置在Livestudio的软件之中，整个“推流”过程不再需要额外的网络编码器和笔记本等设备，也无需再设置IP，只要网络正常，联网即可完成操作，还可根据网络的实际情况设置“推流”的质量以满足要求。此种操作十分便捷，有效避免了上述问题的出现。

参考资料：百度百科：网络直播