建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块
实时音视频RTC 主题:37帖子:38

【产品动态】

视频传输面临的挑战和解决之道

小肆 2020/12/12 2246

引语:随着音视频行业的发展,用户对音视频画质的清晰度、播放的流畅度、互动的低延迟、突破终端限制等的要求越来越高。这些需求从客观上对视频的传输提出更高的挑战,而目前不同业务的视频传输方式各有不同,如何基于视频传输现状,全面系统解决用户需求,成为业界面临的普遍问题。华为云视频架构师黄挺,将从视频传输现状入手,剖析不同业务选择不同视频传输方式的背后逻辑,分享华为云新媒体网络价值主张。

 

 

大家好,我是华为云视频架构师黄挺,非常高兴有机会参加2020年 Live video stack音视频峰会,这次和大家分享的主题是:视频传输面临的挑战和解决之道。

今天分享的内容主要涵盖以下几个方面:视频发展的特点、影响IPTV/OTT/RTC音视频传输技术选择的背后逻辑、结合我们对未来音视频传输行业的洞察,华为云提出的新媒体网络价值主张

 

一、视频发展三个特点

 image.png

1.   概念

1.1数字传输IP化:在TV领域,从传统的数字电视基于Cable的传输,到IPTV领域,基于IP传输,以及在制作领域,从传统基于SDI的传输,再到基于Ip的传输,这都是数字传输IP化的方面。数字传输IP化是视频分发公域化的基础。

1.2 视频分发公域化,公域化就有对应的私域化,私域化视频分发,一般是指在可管理网络进行视频分发;公域化,一般是指基于互联网分发,常见的有:从IPTV到OTT;从企业内部视频会议到在线视频会议;视频分发公域化与视频传输技术的发展密不可分。

1.3 业务体验多样化:就是不同业务对体验的规格要求不同,可能会在质量的维度里,针对规模甚至时延都会有一些不一样的要求。如直播时延<5s;RTC时延<400ms;云游戏时延<100ms。

 

2.   数字传输IP化+视频分发公域化

 image.png

这里我们看一下VR领域正在发生的变化。目前VR主要有两类形态,一类是PC VR 如上图,玩家在玩VR 游戏的时候头盔需要连一根线到PC主机,游戏运行在PC主机上,活动灵活性受限。另外一类是一体机VR,这是ALL IN ONE 设计,没有这个“辫子”,活动灵活性好,但是因为计算单元也在这个头盔上,所以受限于功耗的问题,算力比较小。

目前有一个一体机+PC的方案,既没有“辫子”,同时可以使用PC的算力,即通过Wifi 将PC渲染出来的图像经过编码后传输到VR 头盔。这个优化相对于PC VR,可以看成是数字传输IP化。

云VR 是更近一步的方案。云VR 直接使用云端的算力对游戏进行渲染,这个时候视频就需要在公域网咯进行分发了,同时为了满足体验的要求,也需要通信技术和视频传输技术的进一步优化。目前的体验效果与理想状况,还有一定差距。

 

3.   业务体验多样化

 image.png

前面讲到了除了时延还有很多体验上的差异,比如在规模上,不同的业务对分发的要求也不一样。例如云游戏除了对时延的要求较高,对质量的要求也很高,大家玩过王者荣耀的话应该知道,如果只开30帧,会明显感觉游戏画面不够顺畅。

对不同应用场景下视频需求的理解,也能更好的帮助我们理解不同业务领域对技术的选型逻辑,能够让我们更快的发现当前技术的不足。接下来,会分别从IPTV、OTT、RTC业务的角度,梳理音视频传输技术选型背后的逻辑。

 

二、IPTV、OTT、RTC音视频传输技术选择背后逻辑

1.     IPTV

 image.png

1.1 IPTV 介绍

IPTV是由运营商主导建设的一套系统,IPTV的业务主要包括直播、点播、时移、回看和NPVR等,同时要达到TV级的质量要求,全天候不间断的直播。IPTV主要的优势是运营商可以自建一套可管理的网络,来保障TV级别的用户体验。

IPTV使用的传输方式主要有两种:一个是组播技术,主要应用在直播业务。这个技术大大降低了直播业务峰值时,流媒体服务器的压力。另一个是单播技术,使用了RTSP 进行媒体信令控制,使用RTP 协议进行音视频数据传输,单播技术主要应用在点播、时移、回看、NPVR等业务。

 

1.2 IPTV 直播业务(组播)挑战

l  IPTV首要解决的问题是传输丢包带来的花屏、卡顿等体验问题。

目前采用了2个手段解决这个问题:FEC和ARQ(也叫RET)。FEC主要应用在组播场景;对于随机丢包比较有效,同时因为是频道级别的冗余生成,不需要为每个用户独立生成冗余报文,所以效率比较高。ARQ可以应用在组播和单播场景。他可以较好的解决连续丢包问题。组播场景下,一般这2个技术会同时使用。

l  IPTV其次要解决的是频道切换时长。

频道切换时长主要是指,用户按下遥控器切台按钮到对应画面出现的时间。这里我主要介绍一下组播场景下如何缩短这个时间。首先我们知道要让画面快速显示,就要能够快速解码。而机顶盒加入组播组的时间取决于用户何时切台,是随机的,所以最初机顶盒收到的报文并不能立即开始解码,这样就会降低频道切换的速度。

我们通过引入一个独立的FCC服务器,机顶盒在加入组播组的同时向这个服务器请求一个单播流,FCC服务器可以确保每次请求都从I帧开始发送。这样机顶盒最初收到报文,就可以解码,从而提高频道切换的速度。优化前频道切换时长需要1-3s,优化后可以缩短到300-500ms。

IPTV本质上是TV领域音视频传输技术的IP化,因为网络条件比较好,所以在技术选择上没有太复杂,更多强调的是系统稳定性和跨厂家易集成性。

 

2.     OTT

 image.png

2.1 OTT 视频点播

由于在线观看用户数庞大,OTT 视频平台首要解决视频内容规模化分发的问题。首先,服务的范围广,需要面向全球用户分发,视频传输公域化、跨运营商提供服务;其次,用户规模大;最后,需要低成本的同时保证服务稳定可靠。

目前主流解决方案就是采用成熟的第三方CDN服务进行分发。例如Netflix,随着业务规模的增大,走向自建CDN(Open Connect),但依旧对第三方CDN友好,这样当自建CDN出现故障后,可以快速将流量切给第三方CDN的服务,确保业务的可用性。

此外,OTT视频点播还面临一系列体验问题:例如:带宽质量不稳定,导致播放体验下降;终端因为CPU被占用,影响播放器解码稳定性;由于国家和地区的平均接入条件不同,如何让一个内容同时满足不同用户不同终端的体验要求。

2009开始相继出现了HLS、MSS、DASH 等ABR技术,ABR 技术根据实时检测用户带宽和端侧CPU 使用率,调整视频流的质量。这些技术对HTTP CDN 也是友好的。不过,ABR 只是标准化了服务器与客户端的实现规范。体验的好坏,还取决于码率自适应算法的优劣。

 

2.2 OTT 视频直播

直播可以细分为E2E时延不敏感和敏感两类。

第一类:例如新闻直播等,因为没有和观众互动的要求属于时延不敏感性。所以它们依然可以选择对CDN友好的HLS和DASH协议,但是时延会高达10-30s。

第二类:例如网红直播等,需要与观众进行弹幕、评论等互动,所以要求直播的E2E时延必须低于5s,这类厂家选择的技术栈为时延更低的RTMP和HTTP FLV方式。

海外的技术栈选择和国内有一些不同,因为海外要考虑大量web端客户,低时延传输技术基本以CMAF格式为基础。目前有三类技术:分别是DASH LL、LLHLS和LHLS。基于这个技术栈E2E时延也可以做到5s以内。

OTT个人直播体验,还有一个非常重要的点就是上行推流的质量,因为一旦推流质量不好,全网的观看质量都会下降。目前推流协议主要有三类:分别是RTMP、SRT和RIST,其中RTMP是主流,优势是:成熟、稳定、生态好,各类编码工具基本都支持。SRT和RIST是基于UDP传输,主要优势是:长距离传输(例如:跨洋)、大码率传输、弱网传输。另外相较于TCP层的拥塞算法优化,SRT和RIST可以在应用层优化传输算法,更新比较方便。一些大型跨洋直播的第一公里推流会使用这类协议。

SRT 有相对成熟的开源社区支持。RIST只定义了标准化的语法,允许实现厂家在此基础上进行算法创新,而又不影响互相操作。

 

3.     RTC

 image.png

随着疫情的持续,实时互动类需求快速爆发,RTC技术在文娱、直播连麦、在线教育、在线会议、医疗金融等场景下,有较为广泛的应用。

3.1         RTC 架构的选择

RTC 主要有MESH、SFU、MCU三类架构,MESH架构的优势是简单,不需要服务器参与。不足是当与会人越来越多,对客户端CPU、网络资源的压力就会越来越大,最大不超过6人同时与会,改进方向是增加服务器,集中式架构:SFU、MCU。

SFU服务器只负责转发客户端的数据,相比较MESH 的方式客户端的上行带宽压力和CPU 资源消耗都大大降低了。不足是:下行依旧需要多条流。通过MCU在服务端混流可以解决这个问题,不足是:服务器端计算压力变大,画面组合灵活性不够,部署成本相较于SFU更高。

集中式SFU和MCU架构适用小规模场景,例如传统的企业内部视频通话这类的私域化场景。随着公域化业务兴起,集中式的SFU和MCU架构就不能满足要求了。举个例子:一场会议,其中用户a、b在中国,用户c、d在美国,集中式SFU如果部署在美国,则用户a 和 b之间的通信效果不好;反之,则用户c 和d之间的通信效果不好。

级联式SFU 架构,允许一个会议跨越多个SFU。级联SFU 的优势是:允许会议加入方的人数动态增长;通过合适的路由策略,降低跨国、跨运营商传输带宽成本;通过本地就近接入,使得终端可以与就近的SFU 进行快速的错误恢复,进而改善实时音视频通信的体验;架构的演进部分解决了RTC 业务公域化和规模化的问题。

而级联SFU还有一部分问题没有解决,例如:如何同时满足同一房间内,不同网络情况观众的体验没有问题,业界一般有2个技术:分别是SVC 和Simulcast。

Simulcast 也叫联播,是由发送端向SFU 发送多个视频流,质量级别不同,SFU 根据网络条件,屏幕布局等情况,决定发送哪条流给接收端。联播优势是对传统解码器没有额外的要求;劣势是带宽占用大。

SVC:即可伸缩编码,以分层方式创建单个视频流的编码技术。每一层都增加了上一层的质量,支持时域、空域、质量域三种方式,SFU决定发送哪几层流给接收端,目前主流是时域模式。优势是带宽占用小;劣势是只有部分解码器支持SVC解码。

对比OTT ABR在服务器侧完成多码率编码,RTC在端测完成多码率编码,减少了一次转码,这样可以降低E2E时延,这也是业务体验多样化对技术选型带来的不同。

 

因为RTC 主要应用于对低时延要求较高的业务场景,所以RTC采用了更为“积极” 的方式,应对网络变化,来改进用户体验。

首先RTC 从传输底层技术上就选择了RTP over UDP 实时流媒体传输方式,这为后续积极的应对策略提供了基础。RTC共域传输较于IPTV私域传输更加丰富的丢包恢复手段,包括:FEC、NACK、RED、RTX和PLI等。

光有这些丢包恢复方法还不够,客户端还是需要有一定的Buffer,来抵抗网络的抖动和丢包,否则重传之后,这1帧可能就过时了。所以我们的端侧有一个JitterBuffer的算法,来解决丢包、乱序以及延迟到达的问题。同时也可以平滑显示的帧率。

低时延核心的问题是避免网络拥塞,一旦网络中存在大量buffer,就会导致时延变大,这个时候就需要通过拥塞控制算法来解决。拥塞控制算法的目标是:让“发送速率” 逼近 “可用速率”,同时保持尽可能低的“队列占用率”。

RMCAT是一个IETF小组;他们的工作内容包括:定义需求;设计基于RTP的实时流媒体协议传输的拥塞控制算法。目前有三种RMCAT算法包括:GCC、**和SCReAM。其中GCC因为应用在chrome浏览器上,是目前比较成熟的算法。包括GCC-REMB和新版本GCC-TFB。新版本的优势是:由一端来控制算法,有利于版本演进,同时发端可以根据内容属性的不同,分配不同的带宽进行传输,更加灵活。

 

三、未来音视频传输行业的洞察

1.   音视频传输未来面临三大挑战

第一业务多。边缘业务类型越来越多,从现在已经成熟的下载、点播、直播、RTC,在到正在快速发展的云游戏、云XR等;同一节点部署不同类型的服务,包括缓存、推流、拉流、转发、云渲染等;而烟囱式架构面临一系列问题:包括网络、计算、存储资源管理、差异化体验管理等。

 image.png

第二要求高。新的媒体表现形式沉浸感更强,对音视频传输的要求更高。而且这种提高是全方位的,主要包括:

l  提升带宽从1M到10M再到VR屏幕的100M。

l  降低时延从直播的5s到RTC的400ms到云游戏100ms再到云XR的20ms;同时新的业务也产生了对新的时延类型的要求,例如云游戏要解决的input lag,云XR在3dof场景下要解决rotation lag和在6dof场景下的position lag问题。

l  提高帧率从平面视频的30fps,到未来的60,甚至120帧,而VR内容60帧只是起步,90帧算及格。未来如果需要满足人眼极限要求的VR内容每秒需要大约2Gbps的数据。这还是经过压缩之后的码率。

l  增强渲染从平面视频的2D渲染,到VR中的3D渲染、空间音频渲染,这样沉浸感才能更强。

平面视频的主要指标:包括秒开率,卡顿率、和播放成功率,而影响VR沉浸感体验的因素则更多。

image.png

第三发展快。在行业竞争日益激烈的环境下,要求企业需要有差异化体验,客观上要求创新速度快,技术发展快, 在这个过程中我们的客户遇到的痛点有:

l  开发工作量大,适配不同终端机型

l  耗电快,图形处理为计算密集型处理

l  手机型号有要求,部分用户无法享受

l  安装包变大,影响app推广和用户下载体验

 

2.   华为云新媒体网络价值主张

如何应对这三大挑战,我们提出了华为云新媒体网络的价值主张。愿景是打造一张面向娱乐视频、通信视频、行业视频的新媒体网络,来满足视频高效传输的要求。

其中我们的价值主张是:

l  低时延、全互联、大规模实时音视频分发

l  高通量、沉浸式新媒体传输

l  端、边、云协同创新,灵活定义媒体处理流水线

新媒体网络同时具备以下特征:

l  扁平化:1套网络,1套架构

l  广覆盖:全网2500+节点,全球覆盖

l  全场景:使能娱乐、通信、行业视频等各种场景

l  多连接:实现海量的、面向不同类型终端的连接

l  超体验:从1080P至8K,毫秒级时延,极致抗丢包

l  低时延:利用边缘云技术,支持毫秒级的低时延应用

 

3.   价值主张案例

低时延、全互联、大规模实时音视频分发

 image.png

基于华为云通过新媒体网络,我们支持在线教育技术升级,打造更优的在线教育平台。在传统架构下,实现低时延互动与大规模分发需要用到2个产品RTC 和CDN,这样存在4个问题:

l  CDN和RTC两个网络,问题定界困难,问题修复周期长。

l  旁路直播引入延时,学生在观看和互动间切换存在3-5秒以上时差。

l  互动直播和直播两套SDK,对接困难。

l  针对普通直播观看学生,无法实现共享屏幕与教师画面同步传输。

基于华为云新媒体网络的架构,只需要一个华为RTC服务,就可以实现原来2个产品的功能,主要优势有:

l  一套实时音视频网络,问题定位简单,降低运维成本。

l  可支持学生在互动和观看间自由无感切换,无时延。

l  统一架构,一套SDK覆盖连麦,推流和播放,对接简单,资源包消耗小。

l  可保证共享屏幕与教师画面同步性。

 

高通量、沉浸式新媒体传输

 image.png

华为云的Tile wise Streaming技术,解决了目前VR产业的两大难题:第一VR头盔算力有限,无法支持VR 8K 3D 60帧内容的硬件要求;第二VR内容全量传输,带宽消耗过大。

我们的解决方案是:将原始8K VR内容进行预处理,转码成两条流,一个是4K全景背景流和一个高清前景流。同时对高清前景流进行Tile划分。播放器会根据用户的视场角,选择对应的高清晰Tile分块进行下载,同时下载4K全景背景流,用于转头时短暂使用。

这个方案的优势是: 4k硬解终端可以播放8K VR内容;网络下载带宽降低75%;我们通过端边云协同,实现了用户转头到高清画面展示的延迟只需要100-200ms,人眼几乎无法感知。

 

端、边、云协同创新,灵活定义媒体处理流水线

image.png

目前斗鱼携手华为云打造云端特效市场,用算力释放想象力,打造更佳互动的直播体验。

这个方案的有几大优势:第一、为直播品台提供了创新的玩法:特效直接在上云运行、APP消耗更低,主播再也不用担心电池问题;云端服务器性能强劲,特效效果更优,高级特效算法选择更多。

第二点形成算法生态:云端算法生态聚集各种特效,例如:不同脸型、肤色的美颜效果;创新周期更短,主播可以更快体验到各种特效。

第三点优质的体验:依托华为云新媒体网络,基于华为RTC的实时美颜,时延可以做到低于400ms;新特效实时生效,无需更新APP。

LiveVideoStackCon音视频技术大会LiveVideoStackCon音视频技术大会LiveVideoStackCon音视频技术大会LiveVideoStackCon音视频技术大会

四、总结     

视频发展的三个特点:

1.  数字传输IP化

2.  视频分发公域化

3.  业务体验多样化

视频传输技术选型的三**宝:

1.  业务需求:规模、质量、时延

2.  视频分发网络:公域、私域

3.  技术实施代价:技术复杂度、成本、生态

华为云新媒体网络的三大价值主张:

1.  低时延、全互联、大规模实时音视频分发;

2.  高通量、沉浸式新媒体传输

3.  端、边、云协同创新,灵活定义媒体处理流水线

 

本次的分享就到这里,感谢查阅。


回复0

没有评论
上划加载中
直达楼层
标签
您还可以添加5个标签
  • 没有搜索到和“关键字”相关的标签
  • 云产品
  • 解决方案
  • 技术领域
  • 通用技术
  • 平台功能
取消

采纳成功

您已采纳当前回复为最佳回复

小肆

发帖: 77粉丝: 8

级别 : 版主

发消息 + 关注

发表于2020年12月12日 16:08:10 2246 0
直达本楼层的链接
楼主
显示全部楼层
[产品动态] 视频传输面临的挑战和解决之道

引语:随着音视频行业的发展,用户对音视频画质的清晰度、播放的流畅度、互动的低延迟、突破终端限制等的要求越来越高。这些需求从客观上对视频的传输提出更高的挑战,而目前不同业务的视频传输方式各有不同,如何基于视频传输现状,全面系统解决用户需求,成为业界面临的普遍问题。华为云视频架构师黄挺,将从视频传输现状入手,剖析不同业务选择不同视频传输方式的背后逻辑,分享华为云新媒体网络价值主张。

 

 

大家好,我是华为云视频架构师黄挺,非常高兴有机会参加2020年 Live video stack音视频峰会,这次和大家分享的主题是:视频传输面临的挑战和解决之道。

今天分享的内容主要涵盖以下几个方面:视频发展的特点、影响IPTV/OTT/RTC音视频传输技术选择的背后逻辑、结合我们对未来音视频传输行业的洞察,华为云提出的新媒体网络价值主张

 

一、视频发展三个特点

 image.png

1.   概念

1.1数字传输IP化:在TV领域,从传统的数字电视基于Cable的传输,到IPTV领域,基于IP传输,以及在制作领域,从传统基于SDI的传输,再到基于Ip的传输,这都是数字传输IP化的方面。数字传输IP化是视频分发公域化的基础。

1.2 视频分发公域化,公域化就有对应的私域化,私域化视频分发,一般是指在可管理网络进行视频分发;公域化,一般是指基于互联网分发,常见的有:从IPTV到OTT;从企业内部视频会议到在线视频会议;视频分发公域化与视频传输技术的发展密不可分。

1.3 业务体验多样化:就是不同业务对体验的规格要求不同,可能会在质量的维度里,针对规模甚至时延都会有一些不一样的要求。如直播时延<5s;RTC时延<400ms;云游戏时延<100ms。

 

2.   数字传输IP化+视频分发公域化

 image.png

这里我们看一下VR领域正在发生的变化。目前VR主要有两类形态,一类是PC VR 如上图,玩家在玩VR 游戏的时候头盔需要连一根线到PC主机,游戏运行在PC主机上,活动灵活性受限。另外一类是一体机VR,这是ALL IN ONE 设计,没有这个“辫子”,活动灵活性好,但是因为计算单元也在这个头盔上,所以受限于功耗的问题,算力比较小。

目前有一个一体机+PC的方案,既没有“辫子”,同时可以使用PC的算力,即通过Wifi 将PC渲染出来的图像经过编码后传输到VR 头盔。这个优化相对于PC VR,可以看成是数字传输IP化。

云VR 是更近一步的方案。云VR 直接使用云端的算力对游戏进行渲染,这个时候视频就需要在公域网咯进行分发了,同时为了满足体验的要求,也需要通信技术和视频传输技术的进一步优化。目前的体验效果与理想状况,还有一定差距。

 

3.   业务体验多样化

 image.png

前面讲到了除了时延还有很多体验上的差异,比如在规模上,不同的业务对分发的要求也不一样。例如云游戏除了对时延的要求较高,对质量的要求也很高,大家玩过王者荣耀的话应该知道,如果只开30帧,会明显感觉游戏画面不够顺畅。

对不同应用场景下视频需求的理解,也能更好的帮助我们理解不同业务领域对技术的选型逻辑,能够让我们更快的发现当前技术的不足。接下来,会分别从IPTV、OTT、RTC业务的角度,梳理音视频传输技术选型背后的逻辑。

 

二、IPTV、OTT、RTC音视频传输技术选择背后逻辑

1.     IPTV

 image.png

1.1 IPTV 介绍

IPTV是由运营商主导建设的一套系统,IPTV的业务主要包括直播、点播、时移、回看和NPVR等,同时要达到TV级的质量要求,全天候不间断的直播。IPTV主要的优势是运营商可以自建一套可管理的网络,来保障TV级别的用户体验。

IPTV使用的传输方式主要有两种:一个是组播技术,主要应用在直播业务。这个技术大大降低了直播业务峰值时,流媒体服务器的压力。另一个是单播技术,使用了RTSP 进行媒体信令控制,使用RTP 协议进行音视频数据传输,单播技术主要应用在点播、时移、回看、NPVR等业务。

 

1.2 IPTV 直播业务(组播)挑战

l  IPTV首要解决的问题是传输丢包带来的花屏、卡顿等体验问题。

目前采用了2个手段解决这个问题:FEC和ARQ(也叫RET)。FEC主要应用在组播场景;对于随机丢包比较有效,同时因为是频道级别的冗余生成,不需要为每个用户独立生成冗余报文,所以效率比较高。ARQ可以应用在组播和单播场景。他可以较好的解决连续丢包问题。组播场景下,一般这2个技术会同时使用。

l  IPTV其次要解决的是频道切换时长。

频道切换时长主要是指,用户按下遥控器切台按钮到对应画面出现的时间。这里我主要介绍一下组播场景下如何缩短这个时间。首先我们知道要让画面快速显示,就要能够快速解码。而机顶盒加入组播组的时间取决于用户何时切台,是随机的,所以最初机顶盒收到的报文并不能立即开始解码,这样就会降低频道切换的速度。

我们通过引入一个独立的FCC服务器,机顶盒在加入组播组的同时向这个服务器请求一个单播流,FCC服务器可以确保每次请求都从I帧开始发送。这样机顶盒最初收到报文,就可以解码,从而提高频道切换的速度。优化前频道切换时长需要1-3s,优化后可以缩短到300-500ms。

IPTV本质上是TV领域音视频传输技术的IP化,因为网络条件比较好,所以在技术选择上没有太复杂,更多强调的是系统稳定性和跨厂家易集成性。

 

2.     OTT

 image.png

2.1 OTT 视频点播

由于在线观看用户数庞大,OTT 视频平台首要解决视频内容规模化分发的问题。首先,服务的范围广,需要面向全球用户分发,视频传输公域化、跨运营商提供服务;其次,用户规模大;最后,需要低成本的同时保证服务稳定可靠。

目前主流解决方案就是采用成熟的第三方CDN服务进行分发。例如Netflix,随着业务规模的增大,走向自建CDN(Open Connect),但依旧对第三方CDN友好,这样当自建CDN出现故障后,可以快速将流量切给第三方CDN的服务,确保业务的可用性。

此外,OTT视频点播还面临一系列体验问题:例如:带宽质量不稳定,导致播放体验下降;终端因为CPU被占用,影响播放器解码稳定性;由于国家和地区的平均接入条件不同,如何让一个内容同时满足不同用户不同终端的体验要求。

2009开始相继出现了HLS、MSS、DASH 等ABR技术,ABR 技术根据实时检测用户带宽和端侧CPU 使用率,调整视频流的质量。这些技术对HTTP CDN 也是友好的。不过,ABR 只是标准化了服务器与客户端的实现规范。体验的好坏,还取决于码率自适应算法的优劣。

 

2.2 OTT 视频直播

直播可以细分为E2E时延不敏感和敏感两类。

第一类:例如新闻直播等,因为没有和观众互动的要求属于时延不敏感性。所以它们依然可以选择对CDN友好的HLS和DASH协议,但是时延会高达10-30s。

第二类:例如网红直播等,需要与观众进行弹幕、评论等互动,所以要求直播的E2E时延必须低于5s,这类厂家选择的技术栈为时延更低的RTMP和HTTP FLV方式。

海外的技术栈选择和国内有一些不同,因为海外要考虑大量web端客户,低时延传输技术基本以CMAF格式为基础。目前有三类技术:分别是DASH LL、LLHLS和LHLS。基于这个技术栈E2E时延也可以做到5s以内。

OTT个人直播体验,还有一个非常重要的点就是上行推流的质量,因为一旦推流质量不好,全网的观看质量都会下降。目前推流协议主要有三类:分别是RTMP、SRT和RIST,其中RTMP是主流,优势是:成熟、稳定、生态好,各类编码工具基本都支持。SRT和RIST是基于UDP传输,主要优势是:长距离传输(例如:跨洋)、大码率传输、弱网传输。另外相较于TCP层的拥塞算法优化,SRT和RIST可以在应用层优化传输算法,更新比较方便。一些大型跨洋直播的第一公里推流会使用这类协议。

SRT 有相对成熟的开源社区支持。RIST只定义了标准化的语法,允许实现厂家在此基础上进行算法创新,而又不影响互相操作。

 

3.     RTC

 image.png

随着疫情的持续,实时互动类需求快速爆发,RTC技术在文娱、直播连麦、在线教育、在线会议、医疗金融等场景下,有较为广泛的应用。

3.1         RTC 架构的选择

RTC 主要有MESH、SFU、MCU三类架构,MESH架构的优势是简单,不需要服务器参与。不足是当与会人越来越多,对客户端CPU、网络资源的压力就会越来越大,最大不超过6人同时与会,改进方向是增加服务器,集中式架构:SFU、MCU。

SFU服务器只负责转发客户端的数据,相比较MESH 的方式客户端的上行带宽压力和CPU 资源消耗都大大降低了。不足是:下行依旧需要多条流。通过MCU在服务端混流可以解决这个问题,不足是:服务器端计算压力变大,画面组合灵活性不够,部署成本相较于SFU更高。

集中式SFU和MCU架构适用小规模场景,例如传统的企业内部视频通话这类的私域化场景。随着公域化业务兴起,集中式的SFU和MCU架构就不能满足要求了。举个例子:一场会议,其中用户a、b在中国,用户c、d在美国,集中式SFU如果部署在美国,则用户a 和 b之间的通信效果不好;反之,则用户c 和d之间的通信效果不好。

级联式SFU 架构,允许一个会议跨越多个SFU。级联SFU 的优势是:允许会议加入方的人数动态增长;通过合适的路由策略,降低跨国、跨运营商传输带宽成本;通过本地就近接入,使得终端可以与就近的SFU 进行快速的错误恢复,进而改善实时音视频通信的体验;架构的演进部分解决了RTC 业务公域化和规模化的问题。

而级联SFU还有一部分问题没有解决,例如:如何同时满足同一房间内,不同网络情况观众的体验没有问题,业界一般有2个技术:分别是SVC 和Simulcast。

Simulcast 也叫联播,是由发送端向SFU 发送多个视频流,质量级别不同,SFU 根据网络条件,屏幕布局等情况,决定发送哪条流给接收端。联播优势是对传统解码器没有额外的要求;劣势是带宽占用大。

SVC:即可伸缩编码,以分层方式创建单个视频流的编码技术。每一层都增加了上一层的质量,支持时域、空域、质量域三种方式,SFU决定发送哪几层流给接收端,目前主流是时域模式。优势是带宽占用小;劣势是只有部分解码器支持SVC解码。

对比OTT ABR在服务器侧完成多码率编码,RTC在端测完成多码率编码,减少了一次转码,这样可以降低E2E时延,这也是业务体验多样化对技术选型带来的不同。

 

因为RTC 主要应用于对低时延要求较高的业务场景,所以RTC采用了更为“积极” 的方式,应对网络变化,来改进用户体验。

首先RTC 从传输底层技术上就选择了RTP over UDP 实时流媒体传输方式,这为后续积极的应对策略提供了基础。RTC共域传输较于IPTV私域传输更加丰富的丢包恢复手段,包括:FEC、NACK、RED、RTX和PLI等。

光有这些丢包恢复方法还不够,客户端还是需要有一定的Buffer,来抵抗网络的抖动和丢包,否则重传之后,这1帧可能就过时了。所以我们的端侧有一个JitterBuffer的算法,来解决丢包、乱序以及延迟到达的问题。同时也可以平滑显示的帧率。

低时延核心的问题是避免网络拥塞,一旦网络中存在大量buffer,就会导致时延变大,这个时候就需要通过拥塞控制算法来解决。拥塞控制算法的目标是:让“发送速率” 逼近 “可用速率”,同时保持尽可能低的“队列占用率”。

RMCAT是一个IETF小组;他们的工作内容包括:定义需求;设计基于RTP的实时流媒体协议传输的拥塞控制算法。目前有三种RMCAT算法包括:GCC、**和SCReAM。其中GCC因为应用在chrome浏览器上,是目前比较成熟的算法。包括GCC-REMB和新版本GCC-TFB。新版本的优势是:由一端来控制算法,有利于版本演进,同时发端可以根据内容属性的不同,分配不同的带宽进行传输,更加灵活。

 

三、未来音视频传输行业的洞察

1.   音视频传输未来面临三大挑战

第一业务多。边缘业务类型越来越多,从现在已经成熟的下载、点播、直播、RTC,在到正在快速发展的云游戏、云XR等;同一节点部署不同类型的服务,包括缓存、推流、拉流、转发、云渲染等;而烟囱式架构面临一系列问题:包括网络、计算、存储资源管理、差异化体验管理等。

 image.png

第二要求高。新的媒体表现形式沉浸感更强,对音视频传输的要求更高。而且这种提高是全方位的,主要包括:

l  提升带宽从1M到10M再到VR屏幕的100M。

l  降低时延从直播的5s到RTC的400ms到云游戏100ms再到云XR的20ms;同时新的业务也产生了对新的时延类型的要求,例如云游戏要解决的input lag,云XR在3dof场景下要解决rotation lag和在6dof场景下的position lag问题。

l  提高帧率从平面视频的30fps,到未来的60,甚至120帧,而VR内容60帧只是起步,90帧算及格。未来如果需要满足人眼极限要求的VR内容每秒需要大约2Gbps的数据。这还是经过压缩之后的码率。

l  增强渲染从平面视频的2D渲染,到VR中的3D渲染、空间音频渲染,这样沉浸感才能更强。

平面视频的主要指标:包括秒开率,卡顿率、和播放成功率,而影响VR沉浸感体验的因素则更多。

image.png

第三发展快。在行业竞争日益激烈的环境下,要求企业需要有差异化体验,客观上要求创新速度快,技术发展快, 在这个过程中我们的客户遇到的痛点有:

l  开发工作量大,适配不同终端机型

l  耗电快,图形处理为计算密集型处理

l  手机型号有要求,部分用户无法享受

l  安装包变大,影响app推广和用户下载体验

 

2.   华为云新媒体网络价值主张

如何应对这三大挑战,我们提出了华为云新媒体网络的价值主张。愿景是打造一张面向娱乐视频、通信视频、行业视频的新媒体网络,来满足视频高效传输的要求。

其中我们的价值主张是:

l  低时延、全互联、大规模实时音视频分发

l  高通量、沉浸式新媒体传输

l  端、边、云协同创新,灵活定义媒体处理流水线

新媒体网络同时具备以下特征:

l  扁平化:1套网络,1套架构

l  广覆盖:全网2500+节点,全球覆盖

l  全场景:使能娱乐、通信、行业视频等各种场景

l  多连接:实现海量的、面向不同类型终端的连接

l  超体验:从1080P至8K,毫秒级时延,极致抗丢包

l  低时延:利用边缘云技术,支持毫秒级的低时延应用

 

3.   价值主张案例

低时延、全互联、大规模实时音视频分发

 image.png

基于华为云通过新媒体网络,我们支持在线教育技术升级,打造更优的在线教育平台。在传统架构下,实现低时延互动与大规模分发需要用到2个产品RTC 和CDN,这样存在4个问题:

l  CDN和RTC两个网络,问题定界困难,问题修复周期长。

l  旁路直播引入延时,学生在观看和互动间切换存在3-5秒以上时差。

l  互动直播和直播两套SDK,对接困难。

l  针对普通直播观看学生,无法实现共享屏幕与教师画面同步传输。

基于华为云新媒体网络的架构,只需要一个华为RTC服务,就可以实现原来2个产品的功能,主要优势有:

l  一套实时音视频网络,问题定位简单,降低运维成本。

l  可支持学生在互动和观看间自由无感切换,无时延。

l  统一架构,一套SDK覆盖连麦,推流和播放,对接简单,资源包消耗小。

l  可保证共享屏幕与教师画面同步性。

 

高通量、沉浸式新媒体传输

 image.png

华为云的Tile wise Streaming技术,解决了目前VR产业的两大难题:第一VR头盔算力有限,无法支持VR 8K 3D 60帧内容的硬件要求;第二VR内容全量传输,带宽消耗过大。

我们的解决方案是:将原始8K VR内容进行预处理,转码成两条流,一个是4K全景背景流和一个高清前景流。同时对高清前景流进行Tile划分。播放器会根据用户的视场角,选择对应的高清晰Tile分块进行下载,同时下载4K全景背景流,用于转头时短暂使用。

这个方案的优势是: 4k硬解终端可以播放8K VR内容;网络下载带宽降低75%;我们通过端边云协同,实现了用户转头到高清画面展示的延迟只需要100-200ms,人眼几乎无法感知。

 

端、边、云协同创新,灵活定义媒体处理流水线

image.png

目前斗鱼携手华为云打造云端特效市场,用算力释放想象力,打造更佳互动的直播体验。

这个方案的有几大优势:第一、为直播品台提供了创新的玩法:特效直接在上云运行、APP消耗更低,主播再也不用担心电池问题;云端服务器性能强劲,特效效果更优,高级特效算法选择更多。

第二点形成算法生态:云端算法生态聚集各种特效,例如:不同脸型、肤色的美颜效果;创新周期更短,主播可以更快体验到各种特效。

第三点优质的体验:依托华为云新媒体网络,基于华为RTC的实时美颜,时延可以做到低于400ms;新特效实时生效,无需更新APP。

LiveVideoStackCon音视频技术大会LiveVideoStackCon音视频技术大会LiveVideoStackCon音视频技术大会LiveVideoStackCon音视频技术大会

四、总结     

视频发展的三个特点:

1.  数字传输IP化

2.  视频分发公域化

3.  业务体验多样化

视频传输技术选型的三**宝:

1.  业务需求:规模、质量、时延

2.  视频分发网络:公域、私域

3.  技术实施代价:技术复杂度、成本、生态

华为云新媒体网络的三大价值主张:

1.  低时延、全互联、大规模实时音视频分发;

2.  高通量、沉浸式新媒体传输

3.  端、边、云协同创新,灵活定义媒体处理流水线

 

本次的分享就到这里,感谢查阅。


举报
分享

分享文章到朋友圈

分享文章到微博

游客

您需要登录后才可以回帖 登录 | 立即注册

结贴

您对问题的回复是否满意?
满意度
非常满意 满意 一般 不满意
我要反馈
0/200