首页 > 新闻动态 > 行业新闻 >
视频发展三个特点
2.1. IPTV
2.1.1 IPTV 介绍
IPTV是由运营商主导建设的一套系统，IPTV的主要业务包括直播、点播、时移、回看和NPVR等，并且同时要达到TV级的质量要求，全天候不间断的直播。IPTV主要的优势是运营商可以自建一套可管理的网络，来保障TV级别的用户体验。
IPTV使用的传输方式主要有两种：一个是组播技术，主要应用在直播业务。这个技术大大降低了业务峰值时，流媒体服务器的压力。另一个是单播技术，使用了RTSP 进行媒体信令控制，使用RTP 协议进行音视频数据传输，单播技术主要应用在点播、时移、回看、NPVR等业务。
2.1.2 IPTV 直播业务（组播）挑战
IPTV首要解决的问题是传输丢包带来的花屏、卡顿等体验问题。
目前采用了2个手段解决这个问题：FEC和ARQ（也叫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帧，会明显感觉游戏画面不够顺畅。
对不同应用场景下视频需求的理解，也能更好的帮助我们理解不同业务领域对技术的选型逻辑，能够让我们更快的发现当前技术的不足。接下来，会分别从IPTV、OTT、RTC业务的角度，梳理音视频传输技术选型背后的逻辑。
2.IPTV、OTT、RTC音视频传输技术选择背后逻辑
2.1. IPTV
2.1.1 IPTV 介绍
IPTV是由运营商主导建设的一套系统，IPTV的主要业务包括直播、点播、时移、回看和NPVR等，并且同时要达到TV级的质量要求，全天候不间断的直播。IPTV主要的优势是运营商可以自建一套可管理的网络，来保障TV级别的用户体验。
IPTV使用的传输方式主要有两种：一个是组播技术，主要应用在直播业务。这个技术大大降低了业务峰值时，流媒体服务器的压力。另一个是单播技术，使用了RTSP 进行媒体信令控制，使用RTP 协议进行音视频数据传输，单播技术主要应用在点播、时移、回看、NPVR等业务。
2.1.2 IPTV 直播业务（组播）挑战
IPTV首要解决的问题是传输丢包带来的花屏、卡顿等体验问题。
目前采用了2个手段解决这个问题：FEC和ARQ（也叫RET）。FEC主要应用在组播场景；对于随机丢包比较有效，同时因为是频道级别的冗余生成，不需要为每个用户独立生成冗余报文，所以效率比较高。ARQ可以应用在组播和单播场景。他可以较好的解决连续丢包问题。组播场景下，一般这2个技术会同时使用。
IPTV一个关键的体验指标是频道切换时长。
频道切换时长主要是指，用户按下遥控器切台按钮到对应画面出现的时间。这里我主要介绍一下组播场景下如何缩短这个时间。首先我们知道要让画面快速显示，就要能够快速解码。而机顶盒加入组播组的时间取决于用户何时切台，这是随机的，所以最初机顶盒收到的报文并不能立即开始解码，这样就会降低频道切换的速度。
我们通过引入一个独立的FCC服务器，机顶盒在加入组播组的同时向这个服务器请求一个单播流，FCC服务器可以确保每次请求都从I帧开始发送。这样机顶盒最初收到报文时就可以解码，从而提高频道切换的速度。优化前频道切换时长需要1-3s，优化后可以缩短到300-500ms。
IPTV本质上是TV领域音视频传输技术的IP化，因为网络条件比较好，所以在技术选择上没有太复杂，更多强调的是系统稳定性和跨厂家易集成性。
OTT
2.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.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只定义了标准化的语法，允许实现厂家在此基础上进行算法创新，而又不影响互相操作。
RTC
随着疫情的持续，实时互动类需求快速爆发，RTC技术在文娱、直播连麦、在线教育、在线会议、医疗金融等场景下，有较为广泛的应用。
2.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帧可能就过时了。但是增加buffer又会带来时延的增加，所以我们的端侧有一个动态Jitter Buffer的算法，来解决丢包、乱序以及延迟到达的问题。同时也可以平滑显示的帧率。
低时延核心的问题是避免网络拥塞，一旦网络中存在大量buffer，就会导致时延变大，这个时候就需要通过拥塞控制算法来解决。拥塞控制算法的目标是：让“发送速率” 逼近 “可用速率”，同时保持尽可能低的“队列占用率”。
RMCAT是一个IETF小组；他们的工作内容包括：定义需求；设计基于RTP的实时流媒体协议传输的拥塞控制算法。目前有三种RMCAT算法包括：GCC、NADA和SCReAM。其中GCC因为应用在Chrome浏览器上，是目前比较成熟的算法。包括GCC-REMB和新版本GCC-TFB。新版本的优势是：由一端来控制算法，有利于版本演进，同时发端可以根据内容属性的不同，分配不同的带宽进行传输，更加灵活。
3.未来音视频传输行业的洞察
3.1. 音视频传输未来面临三大挑战
第一业务多。边缘业务类型越来越多，从现在已经成熟的下载、点播、直播、RTC，在到正在快速发展的云游戏、云XR等；同一节点部署不同类型的服务，包括缓存、推流、拉流、转发、云渲染等；而烟囱式架构面临一系列问题：包括网络、计算、存储资源管理、差异化体验管理等。
第二要求高。新的媒体表现形式沉浸感更强，对音视频传输的要求更高。而且这种提高是全方位的，主要包括：
提升带宽：从1M到10M再到VR屏幕的100M。
降低时延：从直播的5s到RTC的400ms到云游戏100ms再到云XR的20ms；同时新的业务也产生了对新的时延类型的要求，例如云游戏要解决的input lag，云XR在3dof场景下要解决rotation lag和在6dof场景下的position lag问题。
提高帧率：从平面视频的30P，到未来的60P，甚至120P，而VR内容60P只是起步，90P算及格。未来如果需要满足人眼极限要求的VR内容每秒需要大约2Gbps的数据。这还是经过压缩之后的码率。
增强渲染：从平面视频的2D渲染，到VR中的3D渲染、空间音频渲染，这样沉浸感才能更强。
平面视频的主要指标：包括秒开率，卡顿率、和播放成功率，而影响VR沉浸感体验的因素则更多。
第三发展快。在行业竞争日益激烈的环境下，要求企业需要有差异化体验，客观上要求创新速度快，技术发展快， 在这个过程中我们的客户遇到的痛点有：
开发工作量大，适配不同终端机型
耗电快，图形处理为计算密集型处理
手机型号有要求，部分用户无法享受
安装包变大，影响app推广和用户下载体验
3.2. 华为云新媒体网络价值主张
如何应对这三大挑战，我们提出了华为云新媒体网络的价值主张。愿景是打造一张面向娱乐视频、通信视频、行业视频的新媒体网络，来满足视频高效传输的要求。
其中我们的价值主张是：
低时延、全互联、大规模实时音视频分发
高通量、沉浸式新媒体传输
端、边、云协同创新，灵活定义媒体处理流水线
新媒体网络同时具备以下特征：
扁平化：1套网络，1套架构
广覆盖：全网2500+节点，全球覆盖
全场景：使能娱乐、通信、行业视频等各种场景
多连接：实现海量的、面向不同类型终端的连接
超体验：从1080P至8K，毫秒级时延，极致抗丢包
低时延：利用边缘云技术，支持毫秒级的低时延应用
3.3. 价值主张案例
低时延、全互联、大规模实时音视频分发
基于华为云的新媒体网络，我们支持在线教育技术升级，打造更优的在线教育平台。在传统架构下，实现低时延互动与大规模分发需要用到2个产品RTC 和CDN，这样存在4个问题：
CDN和RTC两个网络，问题定界困难，问题修复周期长。
旁路直播引入延时，学生在观看和互动间切换存在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个手段解决这个问题：FEC和ARQ（也叫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帧，会明显感觉游戏画面不够顺畅。
对不同应用场景下视频需求的理解，也能更好的帮助我们理解不同业务领域对技术的选型逻辑，能够让我们更快的发现当前技术的不足。接下来，会分别从IPTV、OTT、RTC业务的角度，梳理音视频传输技术选型背后的逻辑。
2.IPTV、OTT、RTC音视频传输技术选择背后逻辑
2.1. IPTV
2.1.1 IPTV 介绍
IPTV是由运营商主导建设的一套系统，IPTV的主要业务包括直播、点播、时移、回看和NPVR等，并且同时要达到TV级的质量要求，全天候不间断的直播。IPTV主要的优势是运营商可以自建一套可管理的网络，来保障TV级别的用户体验。
IPTV使用的传输方式主要有两种：一个是组播技术，主要应用在直播业务。这个技术大大降低了业务峰值时，流媒体服务器的压力。另一个是单播技术，使用了RTSP 进行媒体信令控制，使用RTP 协议进行音视频数据传输，单播技术主要应用在点播、时移、回看、NPVR等业务。
2.1.2 IPTV 直播业务（组播）挑战
IPTV首要解决的问题是传输丢包带来的花屏、卡顿等体验问题。
目前采用了2个手段解决这个问题：FEC和ARQ（也叫RET）。FEC主要应用在组播场景；对于随机丢包比较有效，同时因为是频道级别的冗余生成，不需要为每个用户独立生成冗余报文，所以效率比较高。ARQ可以应用在组播和单播场景。他可以较好的解决连续丢包问题。组播场景下，一般这2个技术会同时使用。
IPTV一个关键的体验指标是频道切换时长。
频道切换时长主要是指，用户按下遥控器切台按钮到对应画面出现的时间。这里我主要介绍一下组播场景下如何缩短这个时间。首先我们知道要让画面快速显示，就要能够快速解码。而机顶盒加入组播组的时间取决于用户何时切台，这是随机的，所以最初机顶盒收到的报文并不能立即开始解码，这样就会降低频道切换的速度。
我们通过引入一个独立的FCC服务器，机顶盒在加入组播组的同时向这个服务器请求一个单播流，FCC服务器可以确保每次请求都从I帧开始发送。这样机顶盒最初收到报文时就可以解码，从而提高频道切换的速度。优化前频道切换时长需要1-3s，优化后可以缩短到300-500ms。
IPTV本质上是TV领域音视频传输技术的IP化，因为网络条件比较好，所以在技术选择上没有太复杂，更多强调的是系统稳定性和跨厂家易集成性。
OTT
2.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.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只定义了标准化的语法，允许实现厂家在此基础上进行算法创新，而又不影响互相操作。
RTC
随着疫情的持续，实时互动类需求快速爆发，RTC技术在文娱、直播连麦、在线教育、在线会议、医疗金融等场景下，有较为广泛的应用。
2.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帧可能就过时了。但是增加buffer又会带来时延的增加，所以我们的端侧有一个动态Jitter Buffer的算法，来解决丢包、乱序以及延迟到达的问题。同时也可以平滑显示的帧率。
低时延核心的问题是避免网络拥塞，一旦网络中存在大量buffer，就会导致时延变大，这个时候就需要通过拥塞控制算法来解决。拥塞控制算法的目标是：让“发送速率” 逼近 “可用速率”，同时保持尽可能低的“队列占用率”。
RMCAT是一个IETF小组；他们的工作内容包括：定义需求；设计基于RTP的实时流媒体协议传输的拥塞控制算法。目前有三种RMCAT算法包括：GCC、NADA和SCReAM。其中GCC因为应用在Chrome浏览器上，是目前比较成熟的算法。包括GCC-REMB和新版本GCC-TFB。新版本的优势是：由一端来控制算法，有利于版本演进，同时发端可以根据内容属性的不同，分配不同的带宽进行传输，更加灵活。
3.未来音视频传输行业的洞察
3.1. 音视频传输未来面临三大挑战
第一业务多。边缘业务类型越来越多，从现在已经成熟的下载、点播、直播、RTC，在到正在快速发展的云游戏、云XR等；同一节点部署不同类型的服务，包括缓存、推流、拉流、转发、云渲染等；而烟囱式架构面临一系列问题：包括网络、计算、存储资源管理、差异化体验管理等。
第二要求高。新的媒体表现形式沉浸感更强，对音视频传输的要求更高。而且这种提高是全方位的，主要包括：
提升带宽：从1M到10M再到VR屏幕的100M。
降低时延：从直播的5s到RTC的400ms到云游戏100ms再到云XR的20ms；同时新的业务也产生了对新的时延类型的要求，例如云游戏要解决的input lag，云XR在3dof场景下要解决rotation lag和在6dof场景下的position lag问题。
提高帧率：从平面视频的30P，到未来的60P，甚至120P，而VR内容60P只是起步，90P算及格。未来如果需要满足人眼极限要求的VR内容每秒需要大约2Gbps的数据。这还是经过压缩之后的码率。
增强渲染：从平面视频的2D渲染，到VR中的3D渲染、空间音频渲染，这样沉浸感才能更强。
平面视频的主要指标：包括秒开率，卡顿率、和播放成功率，而影响VR沉浸感体验的因素则更多。
第三发展快。在行业竞争日益激烈的环境下，要求企业需要有差异化体验，客观上要求创新速度快，技术发展快， 在这个过程中我们的客户遇到的痛点有：
开发工作量大，适配不同终端机型
耗电快，图形处理为计算密集型处理
手机型号有要求，部分用户无法享受
安装包变大，影响app推广和用户下载体验
3.2. 华为云新媒体网络价值主张
如何应对这三大挑战，我们提出了华为云新媒体网络的价值主张。愿景是打造一张面向娱乐视频、通信视频、行业视频的新媒体网络，来满足视频高效传输的要求。
其中我们的价值主张是：
低时延、全互联、大规模实时音视频分发
高通量、沉浸式新媒体传输
端、边、云协同创新，灵活定义媒体处理流水线
新媒体网络同时具备以下特征：
扁平化：1套网络，1套架构
广覆盖：全网2500+节点，全球覆盖
全场景：使能娱乐、通信、行业视频等各种场景
多连接：实现海量的、面向不同类型终端的连接
超体验：从1080P至8K，毫秒级时延，极致抗丢包
低时延：利用边缘云技术，支持毫秒级的低时延应用
3.3. 价值主张案例
低时延、全互联、大规模实时音视频分发
基于华为云的新媒体网络，我们支持在线教育技术升级，打造更优的在线教育平台。在传统架构下，实现低时延互动与大规模分发需要用到2个产品RTC 和CDN，这样存在4个问题：
CDN和RTC两个网络，问题定界困难，问题修复周期长。
旁路直播引入延时，学生在观看和互动间切换存在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化
视频分发公域化
业务体验多样化
视频传输技术选型的三大法宝：
业务需求：规模、质量、时延
视频分发网络：公域、私域
技术实施代价：技术复杂度、成本、生态
华为云新媒体网络的三大价值主张：
低时延、全互联、大规模实时音视频分发；
高通量、沉浸式新媒体传输
端、边、云协同创新，灵活定义媒体处理流水线
