RTMP vs SRT:延迟与最大带宽的比较

引言

文来自Haivision的白皮书,比较了RTMP和SRT两种流媒体协议的优缺点,并通过实验测试了两种协议在延迟和最大带宽两方面的表现。

介绍

对于希望在IP上以低端到端延时进行视频传输的人来说,可供选择的传输协议非常有限。尤其当使用公网作为传输媒介时,因为公网传输需要克服丢包、抖动等诸多障碍。基于此,文中比较和评估了两种常用协议RTMP和SRT的优缺点。

RTMP是一种成熟的流媒体协议,由于其基于TCP的包重传机制和可调缓冲区的能力,所以以可靠性著称。SRT是由Haivision开发的一种开源协议,它使用UDP数据流之上的智能分组重传机制,并使用AES256加密。文中研究了两种传输协议在公网上的传输能力,包括缓冲区的大小,延迟和带宽限制等。

传输时延对比

文中比较的时延指端到端延时,即一帧视频从摄像机采集到在显示器上显示所需要的时间。端到端延时主要受传输链和视频处理步骤的影响,包括编解码,传输媒介(互联网,卫星,光纤等),视频源和显示设备等。虽然每个步骤的延时较小,但累积起来会引入显著的延时。本部分的重点是研究RTMP和SRT对端到端延时的影响,为了使结果具有可比性,所以在测试阶段使用配置完全相同的设备,唯一的变量便是RTMP和SRT协议。但在某些情况下,为了获得稳定的RTMP流,需要对配置作出一定的更改。

测试装置

测试装置要求设计简单,易于复制,且不需要使用特殊的测试设备,最终的测试装置如图1所示。测试系统主要由信号源,显示屏幕,编码器,解码器,Wowza服务器和Haivision媒体网关服务器等组件构成。

图1 测试装置

信号源使用Blackmagic Hyperdeck Shuttle录像机作为视频源,直接作为第一个屏幕,另一个屏幕连接到编码器的输出端,两个屏幕均会显示时间码,时间码可以用来区分视频中的每一帧。使用一个摄像机捕获两个屏幕的图片(如图2所示),便可以根据时间码来得到编码过程中的延时。

图2 视频源与编码输出(时间差为编码时延)

编码器为一个Haivision KB或一个Makito X编码器。基带视频信号经过编码后,可以并行生成RTMP和SRT视频流,对两路视频流采取相同的音频和视频处理过程。编码配置参数如下所示。编码后的视频流码率达到了3Mbps,并且两路输出比特率有所差异,这是由不同的协议开销造成的。

表1 编码配置参数

解码器使用了VLC播放器,这是工业和家庭使用最广泛的视频播放器之一。本测试装置使用了标准的VLC安装设置,默认缓存为250ms。

RTMP流的传输目的地为Wowza流引擎,并托管在AWS上。而SRT流的目的地为Haivision媒体网关服务器,也托管在AWS实例上,并且二者位于同一个数据中心。虽然Wowza也支持SRT协议,但是它的SRT使用的是非常旧的版本,不能发挥SRT的全部潜力。

网络连接的上行链路由Fritzbox 7590 DSL调制解调器建立,下行链路为100Mps,上行链路为42Mbps。连接性能时刻处于监视状态,以确保该连接没有被其他应用程序饱和。

RTMP和SRT的一个主要区别是RTMP流包头中不包含时间戳,只包含实际流的时间戳,并且单个数据包不包含时间戳。因此RTMP接收端需要在规定的时间间隔内将每个接收到的数据包发送到解码器,为了消除各个包之间在传输时间上的差异,需要使用较大的缓冲区。而SRT流每一个数据包都包含时间戳,这使得接收端可以重建信号特性并且显著降低缓冲区的需求,也就是说,SRT发送端的比特流和接收端的比特流是高度相似的。RTMP和SRT流传输前后信号特性如图3所示。

(a)RTMP视频流信号特性

(b)SRT视频流信号特性

图3 RTMP和SRT流信号特性

RTMP和SRT的另一个显著区别是包重传机制。RTMP基于TCP,依赖于接收端返回的ACK,但是接收端在接收到一个包以后并不会立刻返回ACK,而是要在一系列的包接收完以后才会发回。如果发送端接收到ACK发现有丢包存在,则将当前的包序列重传。而SRT可以识别每个丢失的包,在发生丢包时只会重传丢失的包,从而能够降低延时。

此外,发送端和接收端的缓冲区大小也会影响延时。更大的缓冲区可以提供更高的吞吐量,但会引入更大的延时,并且每秒字节吞吐量必须小于缓冲区大小/RTT。客户端播放器越远,吞吐量就越小,除非距离很远,否则播放器的默认设置是足够的。但缓冲区也不能设置得太低,不然会严重限制吞吐量。在测试中,尝试使用65000字节的默认设置,但对于目的地在澳大利亚的流,RTT为360ms,为了实现稳定的流,所以缓冲区增加到260000字节。

延迟测试结果

与预期结果一样,视频流目的地越远,对端到端延迟的影响越大。这里的延时是指绝对的端到端延时,包含编解码,传输和显示设备延时。延时的测试结果如图4所示。

图4 往返端到端延时测试结果

德国-悉尼-德国:为了RTMP视频流和音频流的稳定,接收端缓冲区需要提高到260000字节,是默认设置的4倍。由于测试基于双向流,所以VLC播放器的接收缓冲区需要从默认值250ms增加到2000ms。低于这些值时,流的质量会受到影响甚至无法播放。

德国-California-德国:与悉尼相比,尽管去California的RTT约为悉尼的一半,但是RTT不是影响延迟的唯一因素。回到德国的链路有较大的波动导致单个包传输时间有差异。视频流从德国到California的传输使用默认缓冲区大小65000字节,返回路径需要增加缓冲区路径到650ms。

德国-Virginia-德国:令人惊讶的是,测试结果显示发送到Virginia的RTT比California的稍高(小于3帧或50ms),尽管在地图上Virginia距离德国更近。这说明最短的地理路径不一定是最快的,数据在数据中心和路由器之间以光速进行传输。根据数据链路的容量利用率,视频信号可能并不总是沿着最短的路径传输,而是以更快的路径而非更直接的路径。尽管RTT略高于California,但链路更稳定,抖动更少,并且允许RTMP缓冲区更小。使用默认值65000字节和250ms的VLC。

Thuringia-Frankfurt-Thuringia:对于从德国Thuringia到Frankfurt的AWS数据中心的媒体流,RTT只有17ms。端到端往返延时与Virginia和California相比并没有降低很多。但是,相比美国位置,SRT协议能够降低超过1秒的延迟。

在这些测试中,SRT相对于RTMP快了约2.5倍到3.2倍。如图5所示(使用Haivision KB编码器)。

图5 软件编解码器端到端延时测试结果

到目前为止,使用软件编解码最快的结果也有1.5s的延时,这在某些对延时要求较高的场景中是远远无法接受的。因此可以考虑使用硬件编码器和解码器来进一步降低延时。

测试装置中,硬件编解码器选型为Haivision Makito X,实际测试的延时结果如图6所示。实验结果表明,使用硬件编解码器可以显著降低延时。

图6 软件编解码器与硬件编解码器延时测试结果对比

最大传输带宽对比

上面的测试结果证明了SRT在降低延时方面具有显著的作用,下面的测试则主要研究SRT在视频质量方面的性能。测试方法为逐步提高媒体流的带宽,并观察在当前带宽下视频流能否成功传输。考虑到延时才是测试的重点,所以在增加媒体流带宽时,保持缓冲区大小不变。带宽测试装置如图7所示。

图7 带宽测试装置

为了测试高带宽媒体流,测试地点选择了具有良好的互联网连接状况的地方——位于华盛顿Redmond的微软制作工作室,距离下一个互联网主要连接点只有两跳的距离,并且所有的连接设备都支持1Gbps的传输速率。具体测试方法为,使用2Mbps视频流来确定缓冲区大小,一旦2Mbps流稳定下来,则固定缓冲区大小不变,依次使用1,2,6,10,20Mbps的流进行传输测试。媒体流由Haivision KB5.4编码器提供,发送到California和Virginia的AWS数据中心的Haivision媒体网关,为了测试视频的质量,视频流通过SRT被发回Redmond,并在Haivision Play 2000机顶盒上播放。测试结果如图8所示。

图8 带宽测试结果

带宽测试结果表明,SRT在任何地方都可以传输高达20Mbps码率的媒体流,而RTMP只在发送端和接收端位于同一大洲时才表现良好,当距离过远时,如图8中红色线所示,只能传输2Mbps码率的流。

结论

在端到端延迟和最大传输码率方面,SRT的性能高于RTMP。尽管这些测试是在实验室中完成,并且使用工具包来添加丢包和抖动,但在测试过程中有意使用公网进行传输,所以结果仍然具有较高的可信度。展望未来,SRT会成为流媒体公网传输的又一个选择。

本文分享自微信公众号 - 媒矿工厂(media_tech)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-10-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏AI研习社

A/B测试常见的10个错误

这是 W. Edwards 的依据名言,它表明,A/B 测试对于做出良好的商业决策来说至关重要。在 Manomano,我们向数百万用户展示数百万 DIY 和园艺...

9220
来自专栏AI科技大本营的专栏

DeepMind悄咪咪开源三大新框架,深度强化学习落地希望再现

作为一种新兴的深度学习技术,采用 DRL 面临着简单实现算法之外的诸多挑战,如训练数据集、环境、监测优化工具和精心设计的实验,以简化 DRL 技术的采用。考虑到...

13420
来自专栏Python自动化测试

Pytest之参数化(四)

懂得UI自动化测试的人,应该都比较清楚ddt的模块,在一个测试场景中,如果是同样的测试步骤,那么使用ddt,就可以使用一个单个测试解决多个测试场景的...

22930
来自专栏光城(guangcity)

Pytorch安装及学习人脸特征点识别

继续cs231n的课程,我们学习到pytorch,这里给出安装过程及pytorch基本使用! 下面一起来学习吧!

9420
来自专栏闻人的技术博客

Java微服务新生代Nacos之配置管理

在上文 Java 微服务新生代之 Nacos 已经介绍了微服务框架 Nacos 以及它在服务注册与发现的功能,本文将主要介绍它的另一强大功能:配置管理,学习利用...

15130
来自专栏mall学习教程

Spring Cloud Hystrix:服务容错保护

在微服务架构中,服务与服务之间通过远程调用的方式进行通信,一旦某个被调用的服务发生了故障,其依赖服务也会发生故障,此时就会发生故障的蔓延,最终导致系统瘫痪。Hy...

8210
来自专栏测试邦

后selenium时代Web UI自动化测试框cypress

优点:selenium 的 API 封装遵循 W3C 提供的 webdriver 标准,很好的支持主流浏览器chrome,firefox,IE,Safari等,...

14320
来自专栏开源优测

Selenium Webdriver 3.X源码分析之DesiredCapabilities分布式测试解决方案

> Selenium Webdriver 3.X源码分析系列第7篇,该系列原则上会将整个源码分享一遍

10010
来自专栏新梦想软件测试

总结49种软件测试方法,你知道几个?

β测试,英文是Beta testing。又称Beta测试,用户验收测试(UAT)。

17620
来自专栏闻人的技术博客

Java单元测试之JUnit 5快速上手

单元测试是软件开发中必不可少的一环,但是在平常开发中往往因为项目周期紧,工作量大而被选择忽略,这样往往导致软件问题层出不穷。线上出现的不少问题其实在有单元测试的...

9830

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励