SRT: 开源的视频传输协议

SRT(Secure Reliable Transport)是新一代低延迟视频传输协议,是一种开源、免费和应用灵活的规范,它的性能与专用的协议一样优秀,同时能够在不同制造商生产的产品之间工作。本文主要参考Haivision的SRT白皮书,概述了SRT的一些关键特性,并将SRT与常见传输格式及新一代传输协议QUIC进行比较,最后简述SRT的发展现状。

关键特性

直接建立连接

SRT允许直接在信号源和目标之间建立连接,这与许多现有的视频传输系统形成了鲜明对比,这些系统需要一台集中式服务器从远程位置收集信号,并将其重定向到一个或多个目的地。基于中央服务器的体系结构有一个单点故障,在高通信量期间,这也可能成为瓶颈。通过集线器传输信号还增加了端到端信号传输时间,并可能使带宽成本加倍,因为需要实现两个链接:一个从源到中心集线器,另一个从中心到目的地。通过使用直接从源到目的地的连接,SRT可以减少延迟,消除中心瓶颈,并降低网络成本。

使用ARQ机制进行包投递

比较三种包投递机制,顶部是一个未经纠正的数据流,每当包丢失时,输出信号就会产生错误。中间按照前向纠错 (Forward Error Correction,FEC)机制,它向流中添加固定数量的额外数据,可用于重新创建丢失的包。底部按照自动重传请求(Automatic Repeat-reQuest,ARQ)机制,发送方根据接收方的请求重新发送丢失的包,从而避免了FEC的恒定带宽消耗。

ARQ的工作原理是在视频源和目标之间建立双向连接。每个出站数据包被赋予一个唯一的序列号,而接收者使用这些序列号来确定是否以正确的顺序正确地接收了所有传入的数据包。如果数据包在网络中丢失,接收方可以创建丢失信息包的序列号列表,并自动向发送方发送请求,以便重新传输。对于错误率高的网络(特定时间或发生故障时的网络),这个过程可以重复多次。ARQ要求在发送位置进行缓存(为了在需要重传的情况下临时存储数据包),在发送到视频解码器或其他接收器之前,在接收位置设置一个缓冲区,将数据包重新排列到正确的顺序。

SRT使用ARQ机制主要是因为它可以处理互联网上最常见的错误类型,即损失主要是由随机的丢包造成的。这些错误可以很容易地通过发送方对没有到达接收方的任何数据包进行简单的重传来修复。如果包含位错误的信息包到达接收方,它们将被视为丢失的信息包,发送方将被要求重新传输它们。另一个好处是,SRT为每个包提供高分辨率的时间戳,以便在接收端输出时精确地再现媒体流的时序。这有助于确保下游设备能够正确解码视频和音频信号。

而FEC只适用于能够支持FEC数据所需额外带宽的系统,以及能够承受网络错误率超过阈值时可能发生的信号中断的系统。

使用UDP包格式

SRT会话期间发送的每个包都使用UDP(User Datagram Protocol)包格式,它提供了低开销、低延迟的包投递。大多数为专业应用程序而设计的实时媒体传输网络都使用UDP,因为它提供了稳定的、可重复的包投递系统,具有一致的吞吐量。

不使用TCP(Transmission Control Protocol)的原因在于TCP要求流的所有字节完全按照它们的原始顺序交付。虽然这听起来像是一种发送视频的好方法,但经验表明并非如此。有了视频,一些丢失的字节可以被纠正,或者在最坏的情况下被忽略。使用TCP,不可能跳过坏字节;相反,只要它需要,协议将继续重试发送丢失的数据。这是许多冻结帧的来源,也是在拥挤的网络环境中出现“rebuffering”符号的原因,可能会对观众产生重大影响。TCP的第三个影响是微妙的,但对视频传输很重要。TCP在网络拥塞发生时自动降低包传输速率,虽然这种行为有利于减少网络中的总体拥塞,但它不适用于视频信号,因为视频信号的速度不能低于其标称比特率。

以握手和功能信息交换开始

SRT提供了三种不同的握手模式,让设备相互联系,并设置发送和接收数据包所需的必要数据,例如IP地址。第一种是调用模式,其中SRT端点试图连接到一个已知地址和UDP端口号的远程设备。第二种是侦听器模式,在这种模式下,SRT设备将持续监视传入的通信流,以将其监视到定义的地址和端口号,以等待来自调用方设备的连接。第三种模式称为“汇聚”,其中两个端点同时充当调用者和侦听器,以便通过特定类型的防火墙更容易地建立连接。

每次握手都需要在继续之前通过使用安全cookie对端点标识和密码进行双向确认。握手过程完成后,调用者和侦听器交换它们的功能和配置。网络的两端都需要知道两个端点之间的总体延迟,以便能够建立正确的缓冲区大小来处理包重传延迟。连接带宽也可以估计和通信,以允许视频被压缩至适应网络的容量。可以选择在发送方和接收方之间交换加密密钥,以使用AES 128/192/256位加密对IP包内的视频和音频内容进行加密,使传输更安全。

SRT与常见传输格式比较

SRT与目前市场上的大多数其他视频流传输格式(如RTMP、HLS和MPEG-DASH)相比有几个特点,包括:

非专有

SRT是一个开源解决方案,已经集成到多个平台和体系结构中,包括基于硬件的可移植解决方案和基于软件的云解决方案。因为所有的系统都依赖于相同的底层代码库,所以互操作性被简化了。

能处理长时间的网络延迟

由于其灵活的、自适应的缓冲区管理系统,SRT可以在几毫秒到几秒的延时之间的连接上很好地工作,因此可以处理任何可能在私有网络或全球Internet上发现的东西。

支持多种流类型

与其他一些只支持特定视频和音频格式的解决方案不同,SRT与负载无关。任何类型的视频或音频媒体,或者实际上任何可以使用UDP发送的其他数据元素,都与SRT兼容。

支持多个并发流

多个不同的媒体流例如多个摄像机角度或可选音频轨道,可以通过在一个点对点链接上共享相同UDP端口和地址的并行SRT流发送。这可以在保持每个信号的媒体格式和时序的同时实现,从而允许MP4视频信号与JPEG2000流共享链接。这简化了网络配置和防火墙遍历。

增强防火墙遍历

任何现代组织,无论是基于媒体还是其他,都不允许企业系统无限制地访问公共互联网。防火墙保护私有网络设备(如pc和服务器)免受不必要的外部连接和攻击。SRT使用的握手过程支持出站连接,而不需要在防火墙中打开危险的永久外部端口,从而维护公司安全策略。

信号时间准确

许多压缩视频信号格式对信号不同元素之间的时序变化所造成的中断非常敏感。使用SRT,每个数据包都有一个由发送方分配的高分辨率时间戳,接收方可以恢复该时间戳,以精确重建信号时序关系,而不考虑网络延迟变化。此外,在握手过程中,SRT端点建立了稳定的端到端延迟概要,消除了下游设备需要有自己的缓冲区来应对不断变化的信号延迟。

无需中央服务器

一些专有媒体传输系统需要在发送方和接收方之间使用集中式服务器,这会增加成本和延迟。SRT连接可以直接在设备之间进行,因此不需要中央服务器。此外,如果需要,可以使用集中式服务器和中继点部署SRT,以便应用程序(如基于云的内容收集系统和以集中式模型为首选的剪辑分发网络)。

成本低

SRT系统是使用免费的开放源代码库实现的,这有助于降低各方的成本。SRT部署不需要版税、长期合同或每月订阅费。

基于API

SRT技术包基于API,允许供应商与平台和端点建立紧密的、可重复的集成。

拥有开源社区

SRT已被业界领先的开源项目所采用,例如:VideoLAN的VLC,免费的开源跨平台多媒体播放器和框架;GStreamer是小型设备和移动设备的基础流引擎;Wireshark,领先的网络流分析仪;FFmpeg是世界上最流行的开源视频压缩工具包。

与QUIC比较

SRT和QUIC都旨在克服UDP的包丢失和测序问题,同时消除TCP(传输控制协议)常见的缓冲延迟。两种协议都使用TLS 1.3提供安全传输,TLS 1.3是传输层安全协议的最新版本。

QUIC使用了许多技术来最小化阻塞,例如根据每个流所采取的路径估计持久带宽,根据带宽判断包生成的节奏,以及主动重传支持错误纠正或开始加密等事情的最重要的包。

QUIC还通过减少建立连接所需的往返次数,以及避免在建立了主连接之后在Web页面上与次要源建立连接,从而降低了延迟。与握手、加密设置和初始数据请求相关联的多个步骤合并在初始设置中,而像HTTP/2所采用的压缩和多路复用过程用于避免访问页面上的子源的单独设置。

SRT使用了许多这些技术的变体,包括快速会话设置、带宽估计和通过低延迟重传技术处理包丢失恢复,它在拥塞高时通过丢包来缓和这种情况。但是,SRT不是依赖HTTP和ABR来改变比特率以适应带宽可用性的变化,而是实时分析网络条件并过滤掉抖动、噪声和拥塞的影响。

由于SRT与HTTP Live streaming (HLS)、MPEG-DASH和其他ABR模式下的流媒体标准大相径庭,因此在中段和终段应用程序中,它面临着一场艰苦的战斗。

发展现状

在今年5月举行的plug-in大会上,15个联盟成员成功完成了50多项测试,验证了摄像头、编码器、解码器、网关、多观众和玩家之间的SRT流。

Haivision 和 Wowza共同创建了SRT联盟,自从SRT在2017年成为一种开源技术以来,已有130多家公司通过支持SRT联盟支持了该开源项目。他的供应商和终端用户共同努力,以提高业界对SRT的认识,并将其作为互联网上低延迟视频传输的通用标准。突出的SRT联盟成员包括Ateme、Blonder Tongue、Brightcove、Ericsson、Eurovision、Haivision、Harmonic、Limelight,、Matrox、Sencore和Wowza。

现在,有超过50种支持SRT的产品已经上市,包括IP摄像机、编码器、解码器、网关、OTT平台和CDNs。SRT协议在全球许多应用程序和市场上被数千个组织使用。最终用户包括康卡斯特(Comcast)、ESPN、福克斯新闻(Fox News)、微软(Microsoft)、NBC体育(NBC Sports)、美国橄榄球联盟(NFL)和腾讯(Tencent)。

参考资料

[1]https://www.haivision.com/resources/white-paper/

[2]http://www.screenplaysmag.com/2018/08/14/udp-based-streaming-modes-battle-for-traction-as-paths-to-low-latency/

原文发布于微信公众号 - 媒矿工厂(media_tech)

原文发表时间:2018-11-17

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云市场·精选汇

iPad 已支持使用微信小程序

2018年9月11日北京时间23点06分左右相继收到官方发布的消息,今天早晨小手手的朋友圈就都是这消息。铺天盖地席卷而来。 iPad 也能打开小程序了!这波新能...

95900
来自专栏张善友的专栏

微软学Android Market推出 Web Windows Phone Marketplace

Google在去年推出Android Market web版后,用户对这一特性很赞。用户只需要再web上选择想要的软件,一按INSTALL按钮后手机便会自动安装...

19880
来自专栏玉树芝兰

如何把思维导图秒变成幻灯?

(由于微信公众号外部链接的限制,文中的部分链接可能无法正确打开。如有需要,请点击文末的“阅读原文”按钮,访问可以正常显示外链的版本。)

17420
来自专栏安富莱嵌入式技术分享

【RL-TCPnet网络教程】第29章 NTP网络时间协议基础知识

本章节为大家讲解NTP (Network Time Protocol,网络时间协议)和SNTP(简单网络时间协议,Simple Network Time Pro...

15630
来自专栏IT技术精选文摘

ZStack 的伸缩性秘密(一)异步架构

ZStack 核心架构设计使得 99% 的任务异步执行,因此确保了单个的管理节点能够管理十万级的物理服务器,百万级的虚拟机,数万级的并行任务。

13320
来自专栏逸鹏说道

新浪微博UWP版-实现‘分享功能’的艰难路

索引 介绍 遇到的问题 寻求帮助 最终的解决方案 最终效果 介绍 在整个Team的共同努力下,在众多WPer的期待下,Weibo UWP版终于正式发布了。有关W...

38290
来自专栏腾讯大讲堂的专栏

一秒钟法则

在2014年4月11日的腾讯分享日活动上, 来自腾讯MIG的移动互联网事业群运营总监/T4专家,负责运营QQ手机浏览器、腾讯PC浏览器、腾讯手机安全管家、腾讯...

26790
来自专栏华章科技

关于.NET玩爬虫这些事

从搜索引擎开始,爬虫应该就出现了,爬的对象当然也就是网页URL,在很长一段时间内,爬虫所做的事情就是分析URL、下载WebServer返回的HTML、分析HTM...

25730
来自专栏角落的白板报

Asp.NET Core2.0 项目实战入门视频课程_完整版

看到这个标题,你开不开心,激不激动呢? 没错,.net core的入门课程已经完毕了。52ABP.School项目从11月19日,第一章视频的试录制,到今天完...

574110
来自专栏SDNLAB

VXLAN in OpenStack Neutron

37350

扫码关注云+社区

领取腾讯云代金券