MediaUni——面向未来的流媒体传输网络设计与实践

原创
2023/08/08 08:10
阅读数 242

  //  

“立足当下,着眼未来”,任何一位从业者都应该谨遵这样的格言。阿里云通过总结这么多年的流媒体传输服务,分析痛点、提出措施、改进技术、认真思考,带来了MediaUni这样一个面向未来的流媒体传输网络。LiveVideoStackCon2023上海站邀请到了黄海宇为我们介绍阿里云在MediaUni上的设计与实践。

文/黄海宇
编辑/LiveVideoStack
大家好,我是阿里云视频云的黄海宇,今天分享主题是MediaUni——面向未来的流媒体传输网络设计与实践。
下面我将会从应用对流媒体传输网络的要求、MediaUni定位与系统架构、MediaUni技术剖析、基于MediaUni的应用落地和流媒体传输网络的未来5个方面展开介绍。

-01-

应对流媒体传输网络的要求

如图所示,不同场景延时从左往右依次升高。最右侧,超过30秒的延时,通常被认为是一个可传播的场景,例如视频点播,行业内会通过一张CDN点播网,服务这样的传输需求。
3~10秒的延时区间多见于直播,会使用如RTMP、HTTPFLV和HLS等协议,进行一些流式或小分片的传输,可满足3~5秒的延时需求,通常适用于弹幕互动的场景。在行业内,通常使用CDN直播网络进行这样的传输服务。
最近兴起的800毫秒到1秒左右的延时,通常可以满足体育赛事直播中的传输延时需求,例如,在世界杯直播场景中,该延时的直播让用户不再会感受到进球时刻的明显差异。另外,通过淘宝等电商场景的实践发现,该延时级别的直播,相对于3~10秒的普通直播,可以有效提升GMV。
视频会议、直播连麦、语音聊天的延时通常在250毫秒到400毫秒之间,行业内通常会采用如BGP带宽或者三线带宽,构建一张低延时的音视频通讯网络,来进行实时音视频传输支持。
更低延时的场景,我们将其称为可操控和可沉浸场景,延时在50~80毫秒,可操控的典型场景是平行驾驶,当自动驾驶出现问题时,可以通过远程指令操控汽车、接管驾驶。而云游戏、云渲染则是典型的可沉浸场景。
从上面可以看到,延时的降低带来了更多的业务场景和更多新的玩法。
以延时最低的云渲染场景为例,通过其顶层架构图,可以发现,用户产生一系列的操作指令,通过传输网络传输到相关的业务服务器,再控制渲染服务器进行渲染,渲染后的数据会经过流媒体服务器,再通过流媒体传输网络进行传输,最终达到用户终端。
相比传统的媒体传输,该架构有两个特点:第一,视频来自于渲染而非拍摄,会涉及到大量的计算环节;第二,传输网络不仅要传输媒体,还要传输控制指令,需要保证控制指令的低延时和可靠的交付。
成本和质量是传输网络绕不开的两个话题。左图展示了一个阿里云典型直播APP客户的云上成本构成,70%左右来自于传输,这意味着在当下企业降本的大环境下,需要对传输提出更低成本的要求。右图是另一个典型视频APP的播放时长与卡顿率的关系数据,通过AB测试我们发现,随着卡顿率的逐步降低,播放时长也会有明显的提升。
综合来看,应用对流媒体传输网络的要求来自于四个方面:第一,延时的降低可以催生更多业务场景;第二,低成本,媒体传输是视频应用成本的重要组成部分;第三,更高质量的视频可以提升用户的观看时长;第四,多维度,除了媒体传输之外,还需要支持互动消息的传输、控制信令的传输,同时也要支持与计算的紧密相连。

-02-

MediaUni定位与系统架构

基于以上思考,阿里云设计并实现了MediaUni,其中Uni取自单词unified,意为通过一张统一的网络,服务各种业务场景。
MediaUni是阿里云全球实时传输网络GRTN的升级,是基于广泛的异构节点,构建的全分布式、超低延时、多业务支撑的多元融合流媒体传输网络。
MediaUni的核心理念在于融合,这主要出于如下三方面的思考。
第一、业务混跑带来的资源利用率提升。 云厂商的基本商业逻辑是:云是弹性服务,大家可以按需付费,即买即用,那么,由于不同用户使用的时间段是不同的,购买的固定资源则可分时服务到不同的厂商,使得云服务的资源利用率大于客户自行购买的的资源利用率,从而降低成本。与普通的云计算不同,流媒体的一大特点是业务的聚集,例如,单一的互联网娱乐直播,大部分都会发生在晚上8:00~11:00的晚高峰之间,而大部分的会议分布在白天上班时间,体育赛事则可能出现在任一时间段,如果我们仅仅支持其中一种业务,则无法达到资源复用的目的。
这背后的理论依据是概率论最基本的中心极限定理:大量独立的随机变量之和服从正态分布,随机变量越多,他们的和将越聚集在平均值之和附近。对应到流媒体传输业务,每个客户对资源的使用就是一个随机变量,他们对资源的总需求就是服务商需要保障的资源总量。为了达到更高的复用率,我们需要尽可能扩大业务的规模与多样性,从而达到综合降本的目的。
第二、技术复用带来的研发边际成本降低。 不管是音视频点播的传输网络,还是直播的传输网络,还是实时音视频通讯,都会涉及一些相同的技术,比如协议的优化、QoS优化、调度等,而在一张网上实现这些技术,可以带来更好的技术复用,将单点技术做得更加深入,从而带来更大的业务价值。
第三、云产品更加便捷与高效。 从云厂商的角度来说,把各种传输能力进行融合,意味着用户在使用产品时会更加便捷,比如通过一张网的融合,用户在阿里云上可以通过一键升级,将自己的普通直播(3~5秒延迟)升级为低延时互动直播(400毫秒)。
图为MediaUni的架构
可以看到,MediaUni构建在阿里云广泛的异构资源上,包括3200+的边缘计算节点,以及29个region,同时也包括超过180T的带宽,涉及的计算资源类型包括CPU、GPU、ASIC。
这里有两个很重要的系统,第一个是感知系统。感知系统需要具备三方面的感知能力:
①感知业务信息,在直播时有些应用信息是在真正发生之后才知道的,例如,某个直播流观看人数突然增多,我们必须有能力实时感知到,从而提供一些差异化的服务;
②感知资源信息,包括基础资源的水位、CPU与内存的状态、带宽的使用情况、以及网络的延迟、丢包率等;
③感知服务质量,例如各种业务的卡顿率、视频首帧的延时、推拉流成功率等。
第二个是决策系统 ,这些感知信息在收集以后,会推送给决策系统,并基于成本与质量的平衡,进行调度决策:包括接入的调度、路由的选择、实时的逃逸策略以及算力的调度等等。
MediaUni的整体架构具有几个明显的特点:
一、可以支持多种协议。这些协议是在边缘支持的,在边缘节点进行一层卸载,卸载以后中心会采用统一的内部传输协议,这样利于我们扩展业务场景,同时又不影响内部核心系统;
二、MediaUni支持混合组网。延时要求不高的场景,会采用树状组网,而对于音视频通讯这样延时要求高的场景,会采用对等组网的方式;
三、网络之间的路由会基于源选择动态路径服务用户;
四、全链路可编程。很多业务在同一张网上运行以后,可能会存在业务之间相互影响的问题,为了减少系统的变更,我们支持了全链路的可编程,让大部分业务需求能够通过可编程的方式实现;
五、算网结合。计算部署在网络节点上,能够提高资源利用率,同时也降低为了计算而传输数据带来的成本与延迟;
六、异构网络、计算资源支持。系统支持单线、多线、BGP多种网络资源类型,也支持CPU、GPU、ASIC多种计算类型;
七、持续迭代的QoS。系统支持QoS算法的可插拔,并具备完善的AB测试能力,帮助QoS不断迭代。
融合带来诸多好处,但也会带来额外的挑战。首先是异构资源的适配和纳管。其次是基于不可靠的资源提供可靠的服务,这是这张网络最大的挑战,通常的音视频通讯网络,采用更加优质的资源以达到更低的延迟及稳定性,对于统一的网络,如何在更多的节点里面优选出节点,进行更好的服务则至关重要。
另外的挑战来自于多业务混跑带来快速迭代的需求,运行的业务越多,系统更新也会越来越快,如何满足系统的快速迭代以及缓解随之而来的稳定性冲击,也是一个很大的挑战。最后是标准化和智能化带来的挑战。

-03-

MediaUni技术剖析

下面简要介绍MediaUni对不同场景的支持。
直播场景有几个特点,一个是大规模会带来高并发和成本敏感,另外一个是突发的直播事件。对此阿里云采取了以下措施:首先是混合组网。在3~10秒延迟的直播中采用树状组网,如果延迟需求达到400毫秒左右,将会采用对等组网。其次是热流的秒级感知,当一个流突然从冷流变成热流时,将迅速动态扩大服务资源。另外,目前行业内直播业务仍以基于TCP的协议为主,我们对协议栈进行了深度优化,以达到更好的服务质量。最后是质量与成本可运营,能够根据业务的质量、成本偏好进行调节。
实时通讯场景有两个特点,一个是低延时,一个是场景化。在低延时的实时通讯场景下,为了保障低延时,通常会采用各种QoS策略,但不同场景的QoS策略是千差万别的。例如,视频会议和普通的语音聊天传输,采用的QoS技术差别非常大,为此MediaUni采用动态组网、就近接入、可插拔QoS和秒级逃逸几个技术来解决上述问题。
就近接入,意味着能够快速感知用户和节点之间的链路状态,服务器可以很快做出一些QoS策略的调整。可插拔的QoS能够帮助团队应对各种不同场景化的QoS需求。阿里云的传输依靠大量边缘节点,各个边缘节点的可靠性不尽相同,所以需要对这些节点进行更快速的感知,预防故障的发生以及服务质量的下降。
云渲染场景伴随超低延时和控制信令传输两个特点。这里采用就近接入和就近异构计算两种方式,选择距离用户最近的计算节点和传输节点进行接入,并采用异构的计算方式服务用户。
数据传输场景,通常延时低、可靠性高,而且数据传输量相对较少。通过协议复用与扩展,支持数据的传输,同时采用多径和FEC技术,提升数据传输可靠性,减少重传。
针对不可靠资源的高质量是传输网络面临的巨大挑战,也是关键技术。
传输网络的不可靠主要来源于两个方面,一是资源的不可靠:一方面边缘节点的可用性不尽相同,另一方面大部分的传输都基于公网,而公网建立在IP之上,是一张尽力而为的网络,经常会遇到网络抖动,如何去对抗网络质量的抖动也是一个很大的挑战。
二是流媒体传输的业务特点,包括长链接和热点突发。为了保障低延迟,流媒体的传输通常采用长链接方式,需在建立连接时就分配系统资源,但视频的特点是音视频码率会动态波动,例如世界杯,开始时视频的码率可能只有一兆,但是进球时可能会波动到四兆、五兆甚至更高;另一方面,热点事件突发时会对资源的需求迅速扩大,这都意味着用户业务对资源有很大弹性的要求。
针对上述问题,我们进行了两方面的优化。一方面是弱网对抗。从生产端到传输端,再到播放端,会有很多的优化策略,例如,在前处理时进行降噪、通过阿里云窄带高清技术降低码率、支持多流、SVC等;传输侧相应的策略有动态路由、协议栈优化、FEC、多径等;播放侧会有jitterbuffer、neteq、后处理等方式。
另一方面的优化是感知与逃逸。因为构建在不可靠的资源上,所以非常需要实时感知资源的状态以及业务的状态,再通过智能的决策做秒级的逃逸。
在感知与逃逸的关键技术方面,以下分享一些细节。
我们设计了多维感知评分系统。通常的流媒体传输只感知服务节点的可用性,为了能够支持多种业务,同时提供更好质量,我们引入了评分的概念,对每一个节点进行评分,同时也对节点之间的链路进行评分。
评分来自于三个方面:首先是节点的日志,包括资源的信息、资源的水位和软件运行的状态;其次是端边探测系统,我们不能够仅仅相信服务端的日志,因为可能存在服务质量或服务可用性问题,一些客户没有访问到服务就失败了,从而导致幸存者偏差,为此我们构建了几十万的端设备,用于不断探测系统,探测的结果也是评分的重要依据;最后,是业务层的一些质量数据,比如卡顿率、首帧,以及拉流成功率这类核心的服务质量指标,也将作为评分的一大依据。
在多维感知系统得到这些评分之后,会输出每个节点以及每条链路的评分,并根据评分结果,把相应的信息传输到智能决策系统。智能决策系统会依据业务类型、服务等级、资源的成本以及水位这三方面信息作出决策,包括节点的管控、用户接入的调度、路由动态切换以及无损切换等。由于音视频采用长链接,其可调度性较差,当发生故障或感知到质量下滑后,需要对原有的长链接进行迁移,其中包括处理任务的无损迁移和传输链路上链接的无损迁移。
这里面有三个难点,一是感知的速度,我们采用了两种手段,一方面做业务分级,对系统资源利用率非常大的数据,会使用高优先级通道传输;另一方面进行节点上的计算,将很多计算,包括评分,放在节点上完成,这样传输的数据会大幅减少,从而提升传输速度。第二个难点是如何实现无损切换,要保证音视频的无感切换需要进行帧级别的续接,同时也要处理时间戳连续性、分布式系统调用异常等细节。第三个难点是如何做决策,因为拥有大量的信息,而不同的业务对质量的要求又不尽相同,如何进行智能决策,同时又满足成本的需求,就存在着很大的挑战。
经过技术上的迭代优化,阿里云成功实现在节点故障时的秒级切换,并保障了在质量恶化时的分钟级逃逸。
另一个关键技术是协议栈的应用层联动,这里主要针对TCP场景。
TCP场景一直都有一个优化手段叫做单边加速,这是因为服务器的协议栈由自己控制,可以修改内核进行优化,但是客户侧的TCP协议栈由客户端操作系统提供,不能进行修改,而最近几年出现的Quic,可以在应用层进行拥塞控制以及协议栈优化,但由于TCP仍然是流媒体传输的主要协议,我们进行了深度的优化。传统的单边加速采用通用的加速方法,修改传输的拥塞控制策略,但传输层与应用层相互独立,4层的TCP协议不能感知到7层的应用信息,同时7层也感知不到4层的网络传输变化。产生这样的问题,主要是因为4层在设计上是一个通用协议,不区分流媒体,也不区分文件。为此,我们将4层和7层的信息打通,实现4层和7层的联动以及7层和4层的联动。
右图上面为流媒体传输引擎Tengine-Live,处于应用层,能够获得相应的业务信息、码率信息,同时也会控制一些丢包的策略。在传输时可以通过4层的通道,把业务的偏好、带宽的需求、码率波动以及带宽的大小,传递给操作系统,而操作系统则根据传输的不同阶段采取不同的应对措施。
具体来说,操作系统可以根据应用层的信息选择拥塞控制算法类型,如我们自研的类Cubic算法和类BBR算法,也可以进行子算法的选择,同时,操作系统还可以根据应用层传入的具体信息对算法进行微调,例如,可以根据码率的大小选择首窗窗口,可以根据播放的阶段来均衡策略的激进性,也可以对算法的参数进行调节。
相应的传输信息也会通过4层到7层的通道,把底层拥塞控制里面的实时带宽、网络拥塞状态、网络RTT丢包率等信息传递给应用层,如果应用层发现底层网络已经严重拥塞,则可以采取更激进的丢包策略。
该技术上线以后,实现了播放首帧降低12.1毫秒、卡顿率降低32.5毫秒、拉流成功率提升0.101%的显著效果。
全链路可编程,是为了应对多链路混跑所带来的挑战,多业务混跑会使得需求爆炸性增长,需要一种尽量减少侵入的方式来满足需求的快速迭代。
为此我们开发了全链路可编程系统,对流媒体传输和流媒体处理都进行了可编程扩展,把C代码进行原子能力的抽象,抽象到相应Lua的API,通过调用这些API,可以组合出各种不同的业务能力,以满足播放行为、时间戳、QoS算法迭代以及转码动态规则调整等需求。Lua代码实现以后,会通过配置中心传输到流媒体的传输网络和处理网络,以满足新功能或优化快速迭代的需求。
这里有几点需要注意:高性能,对于传输节点来说,Lua的性能非常重要,因为传输节点的吞吐量非常大,我们大量使用 Lua FFI 而非 Lua Cfunction,减少 Lua 栈数据交互操作,同时也对其中的热点进行性能优化;安全性,需要严格控制Lua的可操作范围,避免对系统造成影响;此外,灵活性是我们采用可编程的目的,实现中也考虑了动态下发,支持灰度、AB 实验、热更新,可插拔等能力,以提高可编程的灵活性。

-04-

基于MediaUni的应用落地

在卡塔尔世界杯期间,我们支持了超低延时的直播,将端到端直播延时降低到一秒以内。此外,我们还带来了更好的播放体验,卡顿率显著下降,从3.19%降低至2.13%。
在一些云渲染的场景,通过就近传输和就近处理,我们实现端到端延时降低到58毫秒。目前,这项技术已经应用在央博的云庙会,以及去年双11淘宝未来城中。
云上艺考则综合使用了多项能力。在远程监考场景,当老师对一个学生感兴趣时,可以单击进入电视直播模式,达到400毫秒延时的直播。如果老师有问题需要和学生进行沟通,开启连麦,也可以做到400毫秒之内的通信。同时,媒体处理服务可以对这些流进行实时的合流,形成一个老师面对多个学生的画面。另外,基于数据传输的能力,应用层可以实现口播的功能,将数据通过网络传给学生,进行考场规则的宣读与显示。

-05-

流媒体传输网络的未来

流媒体传输网络的未来主要有4个方向,分别是更低延时、更智能、更开放和算网融合
随着AIGC的发展,越来越多的视频内容,不再局限于拍摄产生,而可以通过AIGC来生成。当如此多内容通过AIGC的方式生产时,更低的延时毫无疑问会带来更多的玩法。
无论是前面提到的调度系统,还是4层7层联动的策略,都有很多的智能逻辑在里面。从更大的范围讲,传输系统内部存在大量参数与逻辑组合,这些组合目前是经验性的,或者是通过AB测试选择出来的,但对这些参数与组合的衡量结果是确定的,通过衡量视频核心的播放参数,可以构成一个监督学习系统。如何根据反馈,调整网络里面复杂的参数,更智能无疑是更好的解决办法。
在视频领域,两个最重要的方向就是视频的处理和视频的传输。视频处理已拥有很多国际标准,例如H.265、H.266、AV1。但在视频传输上,标准并没有这么被广泛定义或者使用,例如,音视频底层的RTP这样的传输协议标准,只规定了非常基础的包格式,而在大部分偏向应用的场景下,例如RTMP、HLS等标准都是由一些公司自己制定的,这些标准并没有进行很好的统一,随着AIGC的到来,整条视频链路的分工更加细化,行业需要更多的标准帮助不同工具、服务的提供方进行数据交互。阿里云也在积极参与一些协议的标准化,促进协议更加开放。
最后一点是算网融合,正如刚才所说,AIGC的出现,会让更多的视频通过计算的方式产生,这个时候就需要更多地把计算能力融合到网络能力中,通过算网融合,综合调度,进一步降低整体的资源消耗,同时也带给用户更高质量的服务。
谢谢大家!


本文分享自微信公众号 - LiveVideoStack(livevideostack)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部