Loading [MathJax]/jax/output/CommonHTML/config.js
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >RTMP vs SRT:延迟与最大带宽的比较

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

作者头像
用户1324186
发布于 2019-10-10 07:08:41
发布于 2019-10-10 07:08:41
7.5K2
举报
文章被收录于专栏:媒矿工厂媒矿工厂

引言

文来自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会成为流媒体公网传输的又一个选择。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-10-09,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 媒矿工厂 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
2 条评论
热度
最新
https://www.haivision.com/
https://www.haivision.com/
回复回复点赞举报
赞!!!
赞!!!
回复回复点赞举报
推荐阅读
编辑精选文章
换一批
公网传输技术之SRT协议解析(上)
 点击上方“LiveVideoStack”关注我们 作者:张博力 编辑:Alex ▼扫描下图二维码或点击阅读原文▼ 了解音视频技术大会更多信息 ” 摘  要:SRT协议(即安全可靠传输协议)是一个新兴的网络传输协议,适用于实时音视频传输。本文将从SRT协议的原理分析入手,尝试定义出一个衡量SRT链路可靠性高低的指标:链路安全冗余量(Secure-Margin),并详细介绍如何依照这个指标来部署一个可靠的SRT传输链路,并分析在不同的直播场景中的参数调整策略。   引  言   音视频的信号传输技术作为广
LiveVideoStack
2022/03/14
1.9K0
SRT、RTMP、NDI视频传输协议对比!
SRT是由Haivision和Wowza共同创建的互联网传输协议,是时下非常受欢迎的开源低延迟视频传输协议。使用SRT传输技术,能够成功实现普通互联网环境下、多地之间、安全可靠的高清视频传输与分发。现在在嵌入式直播设备上,也用的多,特别是广电相关产品!
用户6280468
2023/09/12
4.9K0
SRT、RTMP、NDI视频传输协议对比!
RTMP之后,SRT与QUIC
https://ngcodec.com/news/2018/11/5/is-the-death-of-rtmp-imminent-the-advance-of-srt
LiveVideoStack
2021/09/01
1.5K0
技术解码 | SRT和RIST协议综述
全文7732字 包括概要、SRT协议、RIST协议三部分 概要 近些年来,互联网行业出现了几波和音视频相关的热潮:VR、短视频、直播等。除了VR因技术成熟度问题,还在蓄势待发,短视频和直播持续热度不减,以各种方式进入新的行业应用领域。视频直播方向,RTMP仍是最流行的上行传输协议,但RTMP的局限性也越来越凸显: RTMP的容器格式FLV,存在不支持新的codec、不支持多音轨、时间戳精度过低等等缺陷; RTMP基于TCP做传输,TCP的公平、可靠传输设计并不适用于实时音视频传输。 业界出现了一
腾讯云音视频
2021/09/22
2.8K0
新一代直播传输协议SRT
SRT协议是基于UDT的传输协议,保留了UDT的核心思想和机制,抗丢包能力强,适用于复杂的网络。在LiveVideoStack线上分享中,新浪音视频架构师 施维对SRT协议的原理、优缺点特性以及在
LiveVideoStack
2020/03/06
3.2K0
新一代直播传输协议SRT
SRT协议在电视直播中的应用
非常高兴能和大家在首届音视频线上峰会上和大家进行分享和讨论。我是来自安徽广播电视台的张博力。本次分享的主题是SRT协议在电视直播中的应用。
LiveVideoStack
2020/08/17
2.4K0
SRT协议在电视直播中的应用
一文详解WebRTC、RTSP、RTMP、SRT
好多开发者,希望对WebRTC、RTSP、RTMP、SRT有个初步的了解,知道什么场景该做怎样的方案选择,本文就四者区别做个大概的介绍。
音视频牛哥
2024/09/27
4.6K0
一文详解WebRTC、RTSP、RTMP、SRT
嵌入式音视频低延迟传输协议srt
SRT(Secure Reliable Transport,安全可靠传输)是一种用于超低(亚秒)延迟的实时音视频流及通用批量数据传输的传输协议。SRT基于UDT协议,Haivision和Wowza合作成立了SRT联盟。SRT解决了复杂的传输时序问题,可以做到支持高吞吐量文件和超清视频的实时传输。SRT是一种开源技术,其开源仓库:
用户6280468
2023/09/12
1K0
嵌入式音视频低延迟传输协议srt
SRT: 开源的视频传输协议
SRT(Secure Reliable Transport)是新一代低延迟视频传输协议,是一种开源、免费和应用灵活的规范,它的性能与专用的协议一样优秀,同时能够在不同制造商生产的产品之间工作。本文主要参考Haivision的SRT白皮书,概述了SRT的一些关键特性,并将SRT与常见传输格式及新一代传输协议QUIC进行比较,最后简述SRT的发展现状。
用户1324186
2018/12/14
18.7K0
音频和视频流最佳选择?SRT 协议解析及报文识别
我们所知道 SRT 是由 Haivision 和 Wowza 开发的开源视频流协议。很多人会认为在不久的将来,它被是 RTMP 的替代品。因为 RTMP 协议安全性稍低,延迟相对较高 ,而相对于 SRT 协议支持高质量、稳定性、亚秒级延迟、强大的编解码器支持。SRT 被许多行业专家认为是视频流的新协议。SRT 究竟是什么?
玖柒的小窝
2021/09/29
2K0
音频和视频流最佳选择?SRT 协议解析及报文识别
8个关于SRT的误区
原文 / https://www.haivision.com/blog/all/8-common-srt-myths-busted/
LiveVideoStack
2019/08/15
2.2K0
8个关于SRT的误区
公网传输技术之SRT协议解析(下)
 点击上方“LiveVideoStack”关注我们 作者:张博力 编辑:Alex ▼扫描下图二维码或点击阅读原文▼ 了解音视频技术大会更多信息 ” 摘  要:本文从SRT协议的工作流程谈起,着重介绍和解析了SRT协议的数据包结构,并举例说明如何利用Wireshark抓包软件进行链路故障分析,从而解决实际工作中的问题。   引  言   SRT(Secure Reliable Transport)协议即安全可靠传输协议,是一种新兴的视音频传输协议,能够在公共互联网环境下实现高质量低延时的实时视音频传输。
LiveVideoStack
2022/05/17
1.6K0
公网传输技术之SRT协议解析(下)
低广播延迟及实现协议
本文来自Elecard,作者是Vitaly Suturikhin,担任Elecard集成和技术支持部主管,主题是“低广播延迟及实现协议”。
用户1324186
2020/07/07
1.7K0
拆解SRT:新UDP视频传输协议
大家好,我是Twitch的视频工程师,今晚我的演讲主题是SRT协议的内幕。在过去,我看过许多关于支持SRT功能的软解的精彩演讲以及它的各种潜能。但是今天,我将掀开幕布,看看SRT协议背后的东西。
LiveVideoStack
2019/12/17
5.2K0
拆解SRT:新UDP视频传输协议
UDP成为低延时流媒体关键 选SRT还是QUIC?
原文:http://www.screenplaysmag.com/2018/08/14/udp-based-streaming-modes-battle-for-traction-as-paths-to-low-latency/
LiveVideoStack
2021/09/01
1.5K0
技术解码丨斗鱼同款的SRT技术是如何对抗推流抖动的?
RT到底是一个什么样的推流协议呢? 针对链路丢包,SRT是如何解决的呢? 本周的技术解码,为您带来 SRT推流技术解析 随着互联网基础设施和硬件设备的不断发展,广大直播观众对于直播观看的清晰度,延时等方面的体验要求越来越高,直播也随之进入了低延时高码率的时代,直播传输技术面临着越来越高的要求和挑战。 腾讯视频云为此在全链路上针对流媒体传输不断深入优化,使得在各大重要赛事上具备了高可靠、低延迟、高画质和音质的需求,同时我们也跟客户,比如斗鱼,进行了更深度的合作。不光在服务端,在APP端也进行了SRT的合
腾讯即时通信IM
2021/04/07
2.1K0
泛广电领域的卫星传输和公网传输
大家好,我是来自安徽广播电视台的张博力,接下来我将为大家详细介绍泛广电领域的卫星传输和公网传输。
LiveVideoStack
2019/11/13
9900
泛广电领域的卫星传输和公网传输
直播弱网优化方法
直播平台纷繁杂多,流量入口逐渐从传统PC端过渡至移动端。直播规 模爆发式增长,2016年更是被誉为“直播元年”。以游戏为代表的泛娱乐直播是这一时期直播生态的重要组成部分。2015-2017年,4G技术普及,手机直播由于不受设备、场景等限制开始迅速普及,推动全民直播的出现;同时,由于直播功能的创新、直播平台以及资本的纷纷入局、政策支持,直播行业一度出现“千播大战”局面。期间,政府出台《电子竞技赛事管理暂行规定》等游戏行业相关政策,进一步推动了游戏直播的发展。
视频云直播helper
2022/02/03
6.2K1
互联网可靠实时协议RIST和SRT
本文是来自SMPTE Webcast的演讲,演讲者是来自Techex的广播工程师Russell Trafford-Jones。本次演讲的主题是互联网上的可靠实时贡献,深入探讨RIST和SRT协议。
用户1324186
2020/08/17
1.7K0
秒懂流媒体协议 RTMP 与 RTSP
RTMP 与 RTSP 是比较常见的两种流媒体协议,那么什么是RTMP?什么是RTSP?它们两之间有什么区别?使用的时候应该如何选择?
网络技术联盟站
2022/05/24
2.8K0
秒懂流媒体协议 RTMP 与 RTSP
相关推荐
公网传输技术之SRT协议解析(上)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档