UDP成为低延时流媒体关键 选SRT还是QUIC?

简介: 版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/82920451 ...
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/82920451

640?wx_fmt=jpeg


无论是SRT还是QUIC,UDP都成为实现低延迟视频流传输的必选项。在刚刚结束的俄罗斯世界杯,以及即将到来的重大体育赛事中,SRT与QUIC还将有一番较量。LiveVideoStack对原文进行了摘译。


文 / Fred Dawson

译 / 王月美

审校 / Ant

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


一个充满挑战的任务—通过互联网实现低延迟、电视级别的优质视频内容,已经演变成了一个不那么令人沮丧但仍然令人生畏的挑战。


对于执行流媒体操作的人员来说,如何在SRT,QUIC,WebRTC和CMAF之间选择,是日常工作中一个特别令人恼火的干扰。


在消费者拥有比以往更多的服务选择时(根据Parks Associates的说法,仅在美国就有超过200种OTT服务),如果不喜欢他们所看到的东西(而且往往他们经常不喜欢),他们可以很容易地选择离开去其他地方。Parks在2017年第三季度对超过10,000个美国家庭进行的一项调查中发现,OTT视频服务的累积流失率超过了50%,这不包括相对低流失率的Netflix和亚马逊服务。


如FCC在其最新的年度宽带报告中列出的那样,当下载速度平均高于55 mbps时,消费者不能在忍受启动延迟和卡顿。由Akamai赞助的一项涉及2300万视频观看会议的研究发现,观众开始大量放弃启动时间延迟超过两秒的视频。研究发现,对于延迟超过两秒的每一秒中就有6%的观众停止观看,这意味着延迟5秒的视频将会失去四分之一的观众。


由缓冲不足造成的卡顿也会产生类似的结果。出席IEEE 2017年网络协议国际会议的研究人员表示,他们对美国9个城市625,626名用户的行为进行审查发现:对于经历很少或没有卡顿的用户,平均每日观看时间超过210分钟;对于每分钟经历0.5次缓冲事件的用户,平均每日观看时间从该值减少到不到30分钟。另外,Conviva在北美近20亿次观看会议上编制的统计数据表明,在8%的观看会话中,缓冲问题至少会造成一个卡顿。


在大型电视屏幕上观看OTT视频,尤其是涉及直播体育或其他线性内容时,其所带来的期望,会加剧对性能不佳的无法容忍。eMarketer表示,目前有55%的美国人口至少每月有一次在联网电视上观看互联网视频。根据Conviva最新公布的数据,通过电视观看视频的时间实际上占据了第二季度人们观看视频流总时间的51%。


UDP 强大的功能


减少延迟的最新开源方法称为安全可靠传输(SRT),这是一种基于UDP(用户数据报协议)的平台。自其发明者Haivision通过一个名为SRT联盟的支持组织免费提供许可证后,该平台在过去一年中迅速获得了市场关注。以Haivision和Wowza为联合创始人,该联盟已经吸引了127家公司加入其中,包括Bitmovin,Brightcove,Canal Cable,Comcast Technology Services,Cinergy,Deluxe,Ericsson,Harmonic和Limelight等少数知名公司以及数十家小型供应商。

 

根据Haivision全球联盟副总裁Sylvio Jelovcich的说法,在5月份插头音乐节上,利用芝加哥,蒙特利尔,丹佛和德国的测试设施,15个联盟成员成功完成了50多项测试,并验证了摄像机,编码器,解码器,网关,多视图和播放器之间的SRT流。Jeloveich说:“看到广泛的新SRT就绪解决方案不断在流媒体和广播界推出是令人兴奋的”。


SRT侵犯了Quick UDP Internet Connections(QUIC)已经占据的领地。谷歌发明的协议作为IETF标准现在处于最终草案阶段,目标是在年底前完成。SRT和QUIC旨在克服UDP的数据包丢失和排序问题,同时消除TCP(传输控制协议)常见的缓冲延迟。这两种协议都利用最新版本的传输层安全协议TLS 1.3来提供安全传输。


QUIC通过分发和接收端的算法调整来修改UDP的实现,即将UDP的实现修改为一种流中封装HTTP 1.1或HTTP / 2格式流的优越传输替代方法。这使得QUIC传送的流能够无缝转换为接收设备上的HTTP,意味着QUIC可以传输ABR使用的多个流。事实上,QUIC通过TCP恢复到HTTP作为后备,以缓解发往多个用户的数据流可能落后于阻塞的UDP流量的罕见情况。


QUIC采用多种技术来最小化阻塞:例如基于每个流所采用的路径的持续带宽估计来生成数据包,以及主动重传最重要的数据包,支持诸如纠错或启动加密之类的事情。


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


SRT采用了许多这些技术的变体,包括快速会话建立,带宽估计和通过低延迟重传技术处理丢包恢复,当拥塞程度较高时,通过丢弃数据包来缓和该现象。但是,SRT不是依靠HTTP和ABR来改变比特率以适应带宽可用性的变化,而是实时分析网络状况并滤除抖动、噪声和拥塞的影响。


人们可能会迷失在SRT与QUIC细微差别中。但有一点似乎是肯定的:增强型UDP注定要取代TCP来传输低延迟视频流。


目前关于UDP的思考带来了流媒体传输的全面发展。由RealNetworks发明的第一个广泛部署的媒体流平台Real Time Streaming Protocol就是基于UDP的;随后是第一个基于HTTP的流媒体模式,它们最初也基于UDP。TCP在两种环境中都取代了UDP,并且它是基于HTTP的ABR占据主导的流媒体传输基础。


SRT和QUIC的战场


由于SRT与HTTP流媒体直播(HLS),MPEG-DASH和其他ABR模式的流媒体规范完全不同,因此它在中间和最后一英里应用中将面临着一场艰苦的战斗。但作为一种开源选择,SRT正在迅速取得其作为第一英里传输解决方案专有前驱的成功。


Haivision首席营销官Peter Maag去年在接受StreamingMedia杂志采访时表达了这一观点,他评论说:“SRT目前是性能流贡献和分配的理想选择。”他补充说,“我们的目标是扩展SRT以应对大规模的OTT交付挑战。”


与此同时,QUIC在全球端到端商业部署中获得了越来越广泛的关注。谷歌是通过将所有网络资产中的技术放在服务器端,并将其置为Chrome浏览器中的默认模式来得以展开。任何人在Chrome浏览器上访问YouTube视频都将通过QUIC来接收数据流。


根据互联网统计编译器W3Techs的说法,该技术的使用正在迅速蔓延到谷歌网站领域之外,现在全球所有网站中就有1%的网站支持它。该数据高于2018年初的0.5%。


去年,Akamai成为第一家宣布支持QUIC的CDN运营商,QUIC现已成为Media Acceleration and Efficiency平台的一部分。在从CDN边缘到运行兼容客户端软件(如Chrome浏览器)的端终用户设备的负载相关子集的访问路线上,Akamai提供了QUIC服务。


 “无论是否使用了QUIC进入,都可以应用于任何利用Akamai的Media Acceleration and Efficiency平台的视频流”,Akamai媒体部门首席架构师Will Law说。Law还补充道,Akamai CDN上的ABR流视频可以使用QUIC通过TCP或UDP从边缘位置传送,其具体取决于客户端的支持与边缘服务器的负载。


Verizon Digital Media Services最近也宣布其支持CDN上的QUIC,而该CDN在六大洲运营125个节点。VDMS公司的首席技术官Frank Orozco表示,VDMS客户可以通过简单的规则引擎更改来启用QUIC,该更改可在几分钟内生效,且无需额外费用。Orozco说道:“无论是流媒体广受关注的体育赛事还是加速购物车交易,每一毫秒都是很异常重要的”。


Bluekiri首席执行官IñakiFuentes表示,VDMS客户Bluekiri与其他网站一起运营着欧洲领先的在线旅行社Logitravel,该网站在QUIC帮助下使得旅行社取得了骄人的业绩。“自从实施QUIC以来,我们在网络性能方面取得了显着地进步,现在访问者能够较以往来更快地访问所需信息”,Fuentes说。


QUIC使用潜在的重大扩展的一个发展指向涉及3GPP,即5G移动标准的开发者。正如来自爱立信研究部高级研究员Zaheduzzaman Sarker最近的一篇博客所述,3GPP创建了一个服务基础分组核心架构(SBA),其中HTTP / 2通过TCP作为传输模式,而它现在正在研究UDP上的QUIC。


凭借“no-HoL,多路复用,流量控制,安全性,更好的拥塞控制”等功能,QUIC是一种比TCP更好、更快的协议”,Sarker说。“3GPP正在研究QUIC取代TCP的潜力。虽尚未做出定论,但这说明了QUIC成为首选运输选择的潜在途径,这不仅是考虑用户的流量,也是为了控制平面的流量。”


SRT的反击


在贡献(第一英里)领域,这是SRT的最佳选择。问题在于该技术是否能够获得IBM Aspera,Signiant,Adobe Send&Track以及其他许多财力雄厚公司的专有系统提供服务,是否足以作为卫星或专用链路的替代方案。如果是这样,那么影响可能是深远的,使得各类专业视频制作者能够在免许可证的平台上访问基于UDP性能的级别。


福克斯体育近期使用Aspera的FASPStream平台,为莫斯科国际足联世界杯现场制作的经验提供了一个戏剧性的视角—即在这种情况下,在长距离生产场景中可以做些什么。正如Aspera副总裁Richard Heitmann所描述的,Fox使用基于UDP的Aspera传输平台与Telestream的Lightspeed Live捕获和Vantage转码解决方案相结合,使得洛杉矶工作室的现场直播制作可距离该活动6000英里以外。


Heitmann指出,“传统上,举办诸如此类的重大活动需要在全球范围内大规模地部署生产人员和设备,包括昂贵的实时卫星馈送或具有高质量服务的专用地面网络。但FOX Sports并未采用这种传统模式,而是选择采用更具创新性的方法,使其能够充分利用其洛杉矶生产设施和人力。”


福克斯在俄罗斯12个场馆的每台摄像机都可以在十秒内完成原始馈送,并在其美国洛杉矶工作室编辑内容,以便在美国进行直播覆盖。“该组织计划明年将为FIFA女足世界杯和其他重大体育赛事(包括NFL比赛)使用Telestream-Aspera联合解决方案”,他说。


从NFL如何使用该技术判断,SRT可能已经应对了这一挑战。正如今年美国国家橄榄球联盟信息技术副总裁John Cave在NAB Show所描述的那样,该应用程序与联盟需要为美国以外的游戏中的游戏裁判审查产生即时回放的需求有关。


美国国家橄榄球联盟通过互联网使用SRT运输的信息来从伦敦审查纽约总部,其接收和伦敦现场观看的重播之间有280毫秒的延迟。“他们只是从广播卡车上获取SDI信号并将其放入Haivision的SRT启用的Makito X编码器中,然后关闭它们,”Haivision的作者Mark John Hiemstra在最近的博客文章中说到。


QUIC和CMAF强强联合


用于最后一英里分发,渠道商选择了开源的QUIC,它的一项新发展是通用媒体应用格式(CMAF),ISO MPEG标准设计为一种通用容器,它通过两种领先的流媒体协议—Apple的HLS(HTTP实时流媒体)和MPEG-DASH进行加密和流式传播。如前所述,该标准支持一种可选的降低延迟的方法,该方法涉及将ABR片段分解为更小的块,这些块可以顺序传递给客户端进行回放,而无需等待整个片段全部加载到缓冲区中。


分块传输编码是HTTP 1.1及更高版本中可用的流数据传输机制。虽然CDN需要支持链接块和存储CMAF片段,但是以新旧设备常见的高处理速度支持ABR的任一客户端都可以使用CMAF分块过程而无需额外的软件支持。通过在块到达时及时播放,播放器避免了等待完整片段到达所导致的延迟。


片段由关键帧限定,而片段内相等长度的块包括ISO-BMFF中称为电影片段文件(moof)和媒体数据盒(mdat)的已知内容。播放器不会请求单个块。相反,块是所请求片段的中间传输的单元,其被顺序地发送到传递链中的所有点,依赖于适时的播放器能够以适当的顺序呈现它们。


作为HTTP兼容协议的QUIC用户将能够在新兴的CMAF环境中工作。虽然前面提到的SRT不支持HTTP,但它支持分段,因此启用CMAF分块所采用方法的极低延迟功能的机制需要一定程度的CDN来支持链接块并存储不属于SRT的路线图。


CMAF的开发是苹果和微软之间罕见的合作,目前还处于采用的早期阶段,但似乎注定是要被广泛使用。值得注意的是,它是消费者技术协会的Web应用视频生态系统(WAVE)项目的定点框架,旨在使内容所有者和分销商通过MPEG的通用加密(CENC),万维网联盟的媒体源和加密媒体扩展(MSE / EME)以及HTML5与CMAF结合使用,能够更容易在不同的流媒体系统和多个设备上启动可互操作的服务。


 “WAVE的一个目标是促进CMAF周边的融合,”Law说。“当CMAF成为一个普通的容器时,它会减少内容分发者必须准备的内容池,以实现广泛的覆盖范围。WAVE正在努力使CMAF的实际使用尽可能地互操作。”


块编码的CMAF的使用已经在商业运营网络(包括Akamai)上产生了4秒范围内的端到端传输指标。虽然适应QUIC和CMAF的综合利用将会是坎坷的,但这方面的势头似乎可能限制SRT超越贡献阶段的程度。



640?wx_fmt=jpeg

相关文章
|
24天前
|
编解码 网络协议 程序员
【RTP 传输协议】实时视频传输的艺术:深入探索 RTP 协议及其在 C++ 中的实现
【RTP 传输协议】实时视频传输的艺术:深入探索 RTP 协议及其在 C++ 中的实现
60 0
|
23天前
|
网络协议 API 网络安全
探讨TCP传输视频流并利用FFmpeg进行播放的过程
探讨TCP传输视频流并利用FFmpeg进行播放的过程
52 0
|
3月前
|
编解码 Linux C语言
实现一个传输h.264的rtsp服务器
实现一个传输h.264的rtsp服务器
50 0
|
4月前
|
存储 网络协议 视频直播
音视频学习之rtsp学习rtp协议的理解(rtp)
音视频学习之rtsp学习rtp协议的理解(rtp)
48 0
|
9月前
|
移动开发 监控 网络协议
视频流传输协议
视频流传输协议
116 0
|
8月前
|
编解码 网络协议 计算机视觉
ffmpeg推流rtmp指定udp传输
ffmpeg推流rtmp指定udp传输
368 0
|
9月前
|
编解码 应用服务中间件 nginx
RTSP协议转换RTMP直播协议
RTSP协议转换RTMP直播协议
436 1
|
存储 编解码 网络协议
音视频基础(网络传输): RTMP封包
RTMP 概念 与 HTTP(超文本传输协议)同样是一个基于 TCP 的 Real Time Messaging Protocol(实时消息传输协议)。由 Adobe Systems 公司为 Flash 播放器和服务器之间音频、视频和数据传输开发的一种开放协议 。在国内被广泛的应用于直播 领域。HTTP 默认端口为 80,RTMP 则为 1935。
194 0
音视频基础(网络传输): RTMP封包
|
编解码 网络性能优化 网络协议
|
存储 编解码 监控
流媒体传输协议之 RTP
本系列文章将整理各路流媒体传输协议,包括RTP/RTCP,RTMP,希望通过深入理解各个流媒体传输协议的设计细节,对今后流媒体部分的开发工作有一定的启发。