[RTMP协议]RTMP设计思想

RTMP传输基本流程

RTMP 视音频数据流程

发送端

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

接收端:

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

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类型的。

在这里插入图片描述当Chunk Size足够大时(一般不这么干),此时所有的Message都只能相应切割成一个Chunk,该Chunk仅msg stream id相同。此时基本上除了第一个Chunk的Header是12Bytes外,其它所有Chunk的Header都是8Bytes。

小结

  • RTMP设计的核心思想: 分块 复用 分等级
  • 还有一些设计思想是: 可灵活设置Chunk Size和灵活的选择RTMP Chunk Header(实现压缩的效果)。
©️2020 CSDN 皮肤主题: 技术黑板 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值