[RTMP协议]RTMP设计思想

RTMP传输基本流程

RTMP 视音频数据流程

发送端

把数据封装成消息(Message)
把消息分割成消息块(Chunk, 网络中实际传输的内容)
将分割后的消息块(Chunk)通过TCP协议发送出去

接收端:

在通过TCP协议收到数据后, 先将消息块重新组合成消息(Message)
通过对消息进行解封装处理就可以恢复出数据

RTMP的突出优点是: 延时低，正常延时1~3秒，理想的话直播可控制在1秒之内。
它是怎么做到的?有什么好的设计思想?

RTMP设计思想

在这里插入图片描述

大而化小轻车简行

RTMP协议中基本的数据单元称为消息(Message)。
在互联网中传输数据时, 消息(Message)会被拆分成更小的单元, 称为消息块(Chunk).
大的Message被切割成利于在网络上传输的小Chunk，个人认为这是RTMP之所以延时低的核心原因。
切成小块, 还可防止大的数据块(如视频数据)阻塞小的数据块(如音频数据或控制信息)。

本是天涯同路人你方唱罢我登场

RTMP基于TCP协议，包括控制信息、视频数据、音频数据都共用同一个TCP Connection。
也就是说路只有一条。而且同一时间只允许一辆车通过。
生成好的视频Chunk和音频Chunk，依次上路。
在这里插入图片描述这就涉及到RTMP中一个非常重要的概念: 复用。
RTMP协议开篇是这么介绍的:

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

其中multiplexing就是复用的意思，指的就是将独立的音视频数据整合到一个数据流，让音视频流可以同步传输的过程。
RTMP直播中，实时生成视频Chunk和音频Chunk，依次加入到数据流，通过网络发送到客户端。
复用在RTMP中是传输方式，也是音视频同步的关键。

事分轻重缓急军令最重粮草次之

在RTMP中，消息(Message)主要分为两大类: 控制消息和数据消息。
数据消息中由包括Video 消息和Audio 消息等。

这些消息都是怎么进行管理的呢?有点像车辆的管理问题。
也就是说路，只有一条，到底谁先走呢，谁后走呢?
答案是: 分优先级，优先级高的先行。优先级低的不能阻塞优先级高的。
RTMP协议可从整体分为两个层次:
在这里插入图片描述 Message stream属于应用层次消息，Chunk stream属于更底层RTMP协议层次。

** RTMP Chunk Stream层级没有优先级的划分，而是在高层次Message stream提供优先级的划分**。
也就是说: 不同类型的消息会被分配不同的优先级，当网络传输能力受限时，优先级用来控制消息在网络底层的排队顺序。
比如当客户端网络不佳时，流媒体服务器可能会选择丢弃视频消息，以保证音频消息可及时送达客户端。

RTMP Chunk Stream层级允许在Message stream层次，将大消息切割成小消息，这样可以避免大的低优先级的消息(如视频消息)阻塞小的高优先级的消息(如音频消息或控制消息)。
在这里插入图片描述

Protocol Control Messages属于RTMP Chunk Stream层级的控制消息，用于该协议的内部控制。
User Control Messages是RTMP streaming layer(即Message stream层次)的消息。
军令最重:协议控制消息(Protocol Control Messages)和用户控制消息(User Control Messages)应该包含消息流ID 0(控制流）和块流ID 2，并且有最高的发送优先级。
粮草次之:据消息(音频信息、音频消息)比控制信息的优先级低。另外，一般情况下，音频消息比视频数据优先级高。

凡事好商量

发送端，在将Message切割成Chunk的过程中，是以Chunk Size(默认值128字节)为基准进行切割的。
在这里插入图片描述

Chunk Size越大，切割时CPU的负担越小；但在带宽不够宽裕的环境下，发送比较耗时，会阻塞其他消息的发送。
Chunk Size越小，利于网络发送，但服务器CPU负担大。不适用于高码率数据流的情况。
Chunk Size是可以实际情况进行改变的，即通过发送控制命令(Set Chunk Size)的方式进行更新。
充分考虑流媒体服务器、带宽、客户端的情况，通过Set Chunk Size可动态的适应环境，从而达到最优效果。

能偷懒时就偷懒

RTMP Chunk Header的长度不是固定的，分为: 12 Bytes、8 Bytes、4 Bytes、1 Byte 四种。

在这里插入图片描述一般情况下，msg stream id是不会变的，所以针对视频或音频，除了第一个RTMP Chunk Header是12Bytes的，后续即可采用8Bytes的。

在这里插入图片描述 如果消息的长度(message length)和类型(msg type id, 如视频为9或音频为8)又相同，即可将这两部分也省去，RTMP Chunk Header采用4Bytes类型的。

在这里插入图片描述如果当前Chunk与之前的Chunk相比, msg stream id相同，msg type id相同，message length相同，而且都属于同一个消息(由同一个Message切割成)，这类Chunk的时间戳(timestamp)也是相同的，故后续的也可以省去，RTMP Chunk Header采用1 Byte类型的。