声网许振明:RTC 场景 UHD 视频应用和探索

大家好,我是声网的视频工程师许振明,今天跟大家主要介绍一下声网在 RTC 场景 UHD 视频的应用和探索。主要基于声网 HFR 和 VDR 两个系统来展开分享。

**随着 RTC 技术的发展和应用,越来越多的场景都需要接入 RTC 的能力。**尤其是随着编码技术、设备能力的迭代,应用场景对视频分辨率、帧率、色彩还原提出了更高的要求。

声网 RTC 在 UHD 视频 4K60FPS、HDR 方面做了一些工程实践和探索,主要应用在教育双师、高端会议、体育运动等场景。下面我们介绍下声网 UHD 视频的技术支撑,探讨下 4K60FPS、 HDR 产品化上遇到卡顿、设备适配相关的典型问题。

1、UHD

UHD 是 Ultra High Definition 的缩写,也就是超高清的意思。超高清的标准一般是当分辨率达到 4K 或以上,也就是 3840x2160 分辨率及以上,与之对应的概念是 FULL HD、HD。

UHD 视频的概念出现的很早,传统的视频领域、家庭电视、传统的视频直播等都有所应用。UHD 视频有 5 大要素:

  • 超高清:4K、8K
  • 高帧率:渲染
  • 高动态范围:HDR
  • 宽色域:WCG
  • 色深:10bit、12bit

对于 RTE UHD 视频而言,即继承了传统 UHD 视频的几大要素,也做了一些扩充:

  • 超高清:4K、8K
  • 高帧率:采集、渲染
  • 高动态范围:HDR
  • 宽色域:WCG
  • 色深:10bit、12bit
  • 色彩范围:Limit、Full 低延时

RTC 区别于传统直播很重要的一个优势,便是低延时,不能因为分辨率的提升影响延时的效果。

2、声网 UHD 视频

在声网的业务场景中,主要通过 HFR(high frame rate)、VDR(variable dynamic range) 2 套系统实现 UHD 视频的支持。

HFR 主要涉及的是超高清、高帧率和低延时;VDR 包含了高动态范围、HDR 到 SDR 的转换、宽色域、色深、色彩范围。

扫描二维码关注公众号,回复: 14546799 查看本文章

如上图右侧所示,我们对 UHD 视频的能力进行了简单的分层。

硬件层以相机为例,至少需要能采集 4K60FPS 的相片;显示设备也需要支持 HDR 的显示效果;系统层包含所有业务场景中应用的系统。假如系统因版本问题不支持色彩管理或者色域管理,对于 HDR 效果的实现会增加难度。

再往上是声网提供的基础能力层。比如我们前面提到的 HFR、VDR,以及新一代编码算法 H.265、传输 SD-RTN;业务层包含各种指标、UHD 和基础能力层为业务提供的 API。

最顶部是应用层。声网作为一家 ToB 的公司,针对不同行业的客户会提供不同的场景应用能力,用业务层对应并支撑应用层。

对于 HFR 我们制定了几个指标:

  • 不掉帧
  • 无卡顿
  • 延时
  • 清晰度

对于 VDR 的指标则主要是针对于色彩相关,包括:

  • 色彩、色差
  • 对比度、亮度
  • MOS
  • 设备适配

下面我们针对 HFR 和 VDR 分别进行展开介绍。

3、HFR

在一些常见的卡顿场景中,虽然带宽足够,但因为帧率较低所以造成了主观上严重的卡顿。除帧率外,对于卡顿的另一个评价标准是均匀度。如在 50 帧的视频中,每两帧的间隔是 20 毫秒,唯独第 47 帧和 48 帧间隔了 200 毫秒,这种不均匀的情况也会导致明显的卡顿。

除帧率外,对于卡顿的另一个评价标准是均匀度。如在 50 帧的视频中,每两帧的间隔是 20 毫秒,唯独第 47 帧和 48 帧间隔了 200 毫秒,这种不均匀的情况也会导致明显的卡顿。

在 RTC 场景中,影响卡顿的因素主要有三个:

  • 网络
  • PIPELINE
  • 性能

网络传输中的丢包或抖动,会导致卡顿;视频 PIPELINE 中掉帧、重复帧、吞帧以及抖动造成的不均匀,也会使得帧率或均匀度出现问题,从而导致卡顿;性能导致的卡顿主要是 CPU 或者 GPU 负载较高时,出现耗时较高的情况。

通过我们的测试,当 CPU 跑到 85% 以上时,会明显影响引擎的工作,进而出现卡顿的风险。所以建议把 CPU 的占有率保持在 70% 以下,从而保证较好的处理性能。

现阶段常见的RTC 场景是 720FPS15、720FPS30 或者 1080FPS50,4K60FPS 因为对 SDK 负载的压力以及各个环节的处理精度提出了更高的要求,比如带宽、线程调度、内存管理、采集精度、上屏帧率等,目前一般只应用于某些专业的场景。

另外,条件要求越高便越容易出现问题,越靠近最终效果主观越难判断。60FPS 和 10FPS 的区别人眼是可以分辨的,但 56FPS 和 57FPS、60FPS 的区别,在人眼看来几乎没有不同,因此需要借助专业的量化工具来进行测量。

量化的方法一般有两种,第一种是 perfdog 方法,通过统计屏幕 Display 新一帧后真实刷新的 FPS 和帧耗时。

这种方法的优点是可以看到整个业务的真实帧率,并且比较贴近用户的主观感受。缺点是无法检测出当视频中出现的重复帧。

举个例子。当 60 帧的视频中第 56 帧和 57 帧是重复帧时,人眼明显可以看出卡顿,但 perfdog 仍然会显示 60 帧的刷新,检测不到出现的重复帧。对此,声网进行了方案的优化,基于相邻帧的相似度和间隔提取,来解决重帧检测不到的问题。

这种方法主要通过对相邻的两帧进行相似度的计算,当相似度为 100%,也就是完全重合的时候,就可以判断这两帧为重帧。另外要考虑的是两帧提取的时间和间隔,如果在 60 帧的情况下提取的时间间隔是 30 毫秒,是与我们的预期不相符的,我们便可以认定这个视频不太符合正常的逻辑。

从一些视频相邻的两帧,可以看出有一定的变化幅度,但幅度很小。因为人眼的观察能力存在差异,进行主观的评测很可能会遗漏或出现偏差,存在不确定性,因此通过量化方法可以避免不确定性的出现,保证 4K60帧的视频真的具有 60 帧。

前文我们讲了如何评测 4K60帧的视频质量,下面我们谈一下针对 4K60帧的卡顿都涉及哪些问题,又该如何优化。

首先和大家介绍一个基于渲染来优化卡顿的方案 —— 基于 vsync 的渲染。

vsync 是垂直同步( Vertical Synchronization )的简称。基本的思路是将 FPS 和显示器的刷新率进行同步。vsync 在设备中一般是一个硬件信号,根据不同的平台封装不同的系统机制。

针对 60 帧的视频来说,每一帧都控制在 16.6 毫秒内刷新,就能保证在一个 vsync 周期内,保证不会产生 Jank。但很多场景中不存在理想的情况,如下图所示:

本来 Jank 要显示 B,但因为 A 还在显示,导致了 B 的延时,从而产生了卡顿。B 会延时的原因是在中间处理时 B 的耗时稍微有些长,产生了一些抖动。面对这种情况,声网采用了类似于 Double Buffering 或者 Triple Buffering 的机制来处理偶尔出现的抖动。

另外,采集的精度也会影响卡顿的情况。例如在屏幕采集时,假设我们模拟了一个 16.6 毫秒的事件驱动来采集 vsync,但很多情况下因为时延的问题采集不到比较高的精度,效果如下图所示:

图中下侧折线图展示的是目前市面上以及部分开源 SDK 的能力状态,基本会在 14 毫秒到 18 毫秒间的波动。这种情况下 60 帧的采集是不够的。因此声网在此基础上进行了优化,效果如图中上侧折线图所示,基本能够收敛在 16.6 毫秒上下,误差 1 毫秒左右,效果基本可以接近 vsync。

上图是一个主观对比的简单示例。左侧为优化前,右侧为优化后。大家可以观察下画面外围的圈在转动时,左侧的顿挫感明显大于右侧。

在 VDR 中有一个很重要的概念叫色彩空间,包含了 Color range 和 Color space。其中 Color range 主要是色彩范围,分为 full range 和 video range,取值范围 [0,255], [16,235]。

Color space 指的是色域。RGB 是一个相对色彩空间,xyz 是绝对的色彩空间对应自然界的颜色,RGB需要通过color space(bt601,bt709,bt2020,srgb,dcp13) 映射到绝对色彩空间。同一个 RGB 值,不同的色域定义下,对应到不同的自然界颜色。

如下图所示,从 bt601 到 bt709 再到 bt2020,色域的范围是越来越广的。所以如果是同一个 RGB 值,如果色域的定义不一样,那么对应到图中的落点也是不同的。

色差是 HDR 里面非常重要的一个概念。一个 yuv 用某个矩阵从 RGB 得到,转换成 RGB 也要用同样的逆矩阵,才能得到正确的 RGB 和颜色。

如上图所示,最左侧第一个人像为原图,第 2、第 3 个人像是用了错误的逆矩阵进行转换,导致人脸、衣服的亮度和色彩都发生了较为明显的变化。第 4、第 5 个人像是用来相同的逆矩阵,所以转换出来的效果和原图更为接近。

另外在 VDR 中,HDR 在亮度、色彩色域、对比度上比 SDR 有优势。如下图所示:

我们可以看几个细节点。首先看天空的云彩云层以及蓝天的颜色,HDR 的表现力以及细节展示是比 SDR 更丰富的。另外可以看一下夕阳的部分,光照照到地面上的一些细节表现,HRD 明显比 SDR 要更清晰,细节展示更多。

目前越来越多的设备开始支持 HDR 显示,据不完全统计大致有几万种不同的设备,但不同的设备对 HDR 的支持程度是不一样的。支持 HDR 的设备屏幕亮度从 500nit 到 2000nit,并且还有一部分支持 P3 色域、一部分支持 BT2020。

HDR 视频要在该设备上达到好的效果需要 tone mapping。下图是同一设备中不同 tone mapping 的对比:

这三张图来自同一个源,但在饱和度、画面细节、亮度处理、平滑处理等维度均有差异化的表现。人眼判断下,可以看出第一张图的算法处理效果是相对较好的。

另外,很多设备并不支持 HDR 显示,并且 SDR 屏幕的亮度和色域达不到 HDR 的要求,如果不考虑设备的支持强制的把 HDR 视频显示在 SDR 的屏幕上,会产生比优化前更差甚至不可接受的效果。

为了让尽可能多的用户体验到 HDR,我们可以借助 HDR2SDR,把 HDR 的视频通过算法降级到 SDR,然后再在 SDR 的屏幕上做显示。

这个功能在 RTC 场景中有着很实际的应用。当一个频道内多人互动时,如果有一个人的设备不支持 HDR,传统的逻辑是所有人都需要退回到 SDR 发送。而借助 HDR2SDR 功能就可以让大家都体验到 HDR 的效果。

大家关注的另一点,是如何判断从 HDR 转换到 SDR 后的效果是否够好。对于好坏的判断需要一个参照物,如果效果和 HDR 很接近并且又能正常显示,我认为就是一个相对较好的效果。

下方的 4 张图是同一场景中不同的画面展示效果:

从图中开一看出,HDR 的在亮度和细节展示方面明显优于 SDR。第三张图是 HDR2SDR 的一种算法实现,展示效果有所优化,但细心的朋友可以发现算法消除了灯光的光晕。

第四张图是 HDR2SDR 的另一种算法,在提升展示效果的同时保留了光晕的细节。我们一般认为第二种算法要优于第一种算法,更接近我们想要的需求和效果。但这类评价都是偏主观的,还是要看优化后的参照物是什么,特定情况进行特定的分析。

以上是我本次分享的内容。声网在 UHD 视频方面主要是通过高帧率系统和 VDR 系统实现 UHD 视频的支持。欢迎大家体验、交流,谢谢。

点击下方图片,即可查看完整视频回顾

{{o.name}}
{{m.name}}

猜你喜欢

转载自my.oschina.net/agora/blog/6308062