中广鸿泰专注研发视听设备!    English
返回首页 加入收藏
行业新闻
首页 > 新闻动态 > 行业新闻 >
视频传输面临的挑战和解决之道
阅读 次    时间:2021-06-24 10:55

视频发展三个特点

2.1. IPTV

2.1.1 IPTV 介绍

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

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

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

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

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

IPTV一个关键的体验指标是频道切换时长。

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

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

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

2.2. OTT

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

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

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

1.3. 业务体验多样化

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

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

2.IPTVOTTRTC音视频传输技术选择背后逻辑

2.1. IPTV

2.1.1 IPTV 介绍

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

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

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

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

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

IPTV一个关键的体验指标是频道切换时长。

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

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

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

OTT

2.2.1 OTT 视频点播

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

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

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

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

2.2.2 OTT 视频直播

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

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

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

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

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

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

RTC

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

2.3.1 RTC 架构的选择

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

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

集中式SFUMCU架构适用小规模场景,例如传统的企业内部视频通话这类的私域化场景。随着公域化业务兴起,集中式的SFUMCU架构就不能满足要求了。举个例子:一场会议其中用户ab在中国,用户cd在美国,集中式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私域传输更加丰富的丢包恢复手段,包括:FECNACKREDRTXPLI等。

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

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

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

3.未来音视频传输行业的洞察

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

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

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

提升带宽:从1M10M再到VR屏幕的100M

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

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

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

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

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

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

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

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

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

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

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

其中我们的价值主张是:

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

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

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

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

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

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

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

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

超体验:从1080P8K,毫秒级时延,极致抗丢包

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

3.3. 价值主张案例

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

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

CDNRTC两个网络,问题定界困难,问题修复周期长。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.总结

视频发展的三个特点:

数字传输IP

视频分发公域化

业务体验多样化

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

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

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

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

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

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

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

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

 

 

 

 

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


视频发展三个特点

 

 

2.1. IPTV

2.1.1 IPTV 介绍

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

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

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

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

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

IPTV一个关键的体验指标是频道切换时长。

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

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

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

2.2. OTT

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

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

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

1.3. 业务体验多样化

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

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

2.IPTVOTTRTC音视频传输技术选择背后逻辑

2.1. IPTV

2.1.1 IPTV 介绍

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

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

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

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

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

IPTV一个关键的体验指标是频道切换时长。

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

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

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

OTT

2.2.1 OTT 视频点播

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

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

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

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

2.2.2 OTT 视频直播

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

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

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

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

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

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

RTC

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

2.3.1 RTC 架构的选择

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

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

集中式SFUMCU架构适用小规模场景,例如传统的企业内部视频通话这类的私域化场景。随着公域化业务兴起,集中式的SFUMCU架构就不能满足要求了。举个例子:一场会议其中用户ab在中国,用户cd在美国,集中式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私域传输更加丰富的丢包恢复手段,包括:FECNACKREDRTXPLI等。

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

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

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

3.未来音视频传输行业的洞察

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

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

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

提升带宽:从1M10M再到VR屏幕的100M

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

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

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

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

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

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

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

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

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

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

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

其中我们的价值主张是:

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

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

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

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

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

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

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

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

超体验:从1080P8K,毫秒级时延,极致抗丢包

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

3.3. 价值主张案例

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

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

CDNRTC两个网络,问题定界困难,问题修复周期长。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.总结

视频发展的三个特点:

数字传输IP

视频分发公域化

业务体验多样化

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

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

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

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

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

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

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

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



关于我们
公司介绍
公司荣誉
公司文化
社会责任
招聘人才
联系我们
新闻动态
公司新闻
行业新闻
品牌中心
AKG
BSS
QSC
EAW
Blamp
AVsdiudio
symetrix
AMX
ALLEN&HEATH
XILICA
Crestron
ZGHTacoustic
产品中心
EAW产品
Symetrix产品
中控系列
摄像机系列
调音台系列
ALLEN&HEATH
IP分布式系列
AMX
Crestron产品
Mackie
XILICA
BSS
ZGHTacoustic
自主研发
数字调音台
数字处理器
数字功放
分布式系统
高端手拉手系统
音箱系列
解决方案
视频会议
远程医疗
应急指挥
教育培训
智能酒店
项目案例
企业政府
商业酒店
文化体育
校园教育
其他
技术与服务
宣传与优势
资料下载
咨询&留言

公司地址:北京市丰台区宋家庄路苇子坑149号麒麟商务楼六层8601室|电话:010-67618309

法律声明 | 联系我们 | 诚聘英才 北京中广鸿泰视听科技有限公司 版权所有 Power by DedeCms 京ICP备17062887号-1