中广鸿泰专注研发视听设备!    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
CECAV
televic
symetrix
ALLEN&HEATH
XILICA
Crestron
产品中心
EAW产品
Televic产品
Symetrix产品
中控系列
扬声器系列
摄像机系列
调音台系列
ALLEN&HEATH
IP分布式系列
Crestron产品
Mackie
XILICA
BSS
自主研发
数字调音台
数字处理器
数字功放
分布式系统
高端手拉手系统
音箱系列
解决方案
视频会议
远程医疗
应急指挥
教育培训
智能酒店
项目案例
企业政府
商业酒店
文化体育
校园教育
其他
技术与服务
宣传与优势
资料下载
咨询&留言

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

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