“AI 技术+人才”如何成为企业增长新引擎?戳此了解>>> 了解详情
写点什么

5G 超高清关键技术:高帧率重置、高动态渲染、云加端增强

  • 2020-04-30
  • 本文字数:4273 字

    阅读完需:约 14 分钟

5G超高清关键技术:高帧率重置、高动态渲染、云加端增强

随着 5G 落地,用户对视频体验的要求越来越高。当带宽不再是超高清的主要矛盾之后,超高清还存在哪些挑战?我们距离全面超高清还有多远?阿里文娱一直在做相关技术的预研,并在 2019 年底推出了互联网视频行业超高清解决方案——帧享。那么,帧享是什么、有哪些关键技术、未来有哪些发展方向?且看阿里文娱高级算法专家 张行在 GMIC Live 2020 智慧文娱技术专场中的相关分享。

帧享是什么?

帧享是一个超高清的解决方案,从 2B 到 2C 的视角,帧享具备 4 个技术能力:


  • 一是高帧率增强,可提供最高 120 帧的超高帧率视频,顺滑地呈现物体运动场景;

  • 二是超高分辨率,对于画面中微小的细节与结构,在帧享的视频中也能刻画得非常清楚;

  • 三是 HDR 高动态渲染,画面对比更丰富,颜色鲜活有质感;

  • 四是帧享环绕音效,我们利用声道间的相位差异,充分体现声音的立体感和空间感。


前三个方向的特性分别体现了帧享对于时间、空间、亮度、色度的超高分辨与呈现能力,第四点是声音特性和声场效果,这四点组合起来,既是帧享能给用户提供的关键特性,也涵盖了观众对于超高清的诉求。



要真正将帧享落地,需要深入到视频制播产业的各个环节中,从左到右有 5 个关键词:拍摄、制作、生产、传输和呈现,这五个环节环环相扣,每一步都与最终视频的呈现质量息息相关。我们首先要保证每一步都能够正确地处理,尽可能采集和保留更多内容信息;其次是挖掘链路上各环节的处理能力,利用我们在制作、生产和呈现上的人力和算力,进行信息的重建和增强,提升视频体验。


具体来讲,在拍摄和制作环节,我们会给出明确的超高清视频的要求规范;在制作环节,开放云剪辑能力,为后期的剪辑提质提效;在介质环节,做严格品控,保证介质内容的基础质量。在生产环节,减少转码的损失,利用我们平台的计算能力进行恢复和重置增强,同时对视频进行结构化分析,拿到视频的各种分类、场景、标签等高低层的语义信息,将其与码流一起传输到终端设备上,并进行适配的后处理增强和渲染。这种适配包括对内容、设备和用户偏好的适配等,确保最终的体验和效果。

帧享的关键技术:高帧率重置、高动态渲染、云加端增强

1. 高帧率重制

从视频中可以明显看出,低帧率的竖线运动时一直在颤动,而高帧率的运动就很平滑。 为什么低帧率会抖动?



如上图,x 轴表示时间,y 轴表示位移,物体的匀速运动在坐标系中是一条斜线,如图中有箭头标记的蓝线。而实际的物体位置在这条蓝线之上。由于低帧率的刷新率是有限的,物体的实际位置在一帧内是固定的,到下一帧会跳跃到另一个位置,就像上台阶一样。人的眼睛会天然的跟踪运动的物体,也会根据当前位置和运动速度,去推测物体的下一个位置,如图中绿星星所标记的。我们看到物体的实际位置和物体的预测位置一直不重合,且预测位置一直在实际位置的上下抖动,非常伤害观看体验。


高帧率重置,在算法上就是插帧。插帧技术已经存在很久了,方法大概分成两类,一类是基于特征的传统方法;另一类是基于数据的网络方法。两者思路是一致的,根据像素的帧间相关性去推算光流,再做插值。


在传统算法中,先根据多帧的视频图像去做光流,预测出前后向光流,来映射到需要插帧的相位上。这时候就需要考虑很多特征,比如到底是用前向光流还是后向光流、用双向光流还是单向光流,哪些地方是露出遮挡区域等,根据这些去做插值重建,得到高帧率视频,这是一种完全基于运动特性的传统方法。


网络方法非常类似,只是将光流的预测还有像素的差值都用网络来实现,还有一些网络方法可能更极端,它会把光流网络和插值网络合二为一,直接用一个端到端的数据训练,得到一个插帧网络。但无论是传统还是网络办法,在插帧中有一个难以解决的问题——在一些运动的交界处,光流很难严格贴合物体的实际边缘,这样会导致各种各样的问题。


优酷是如何优化的?


首先是基于成熟的插值算法,将各点效果做到极致,在实际场景中有效解决问题;其次是拆解问题,尝试把通用的插帧问题,分层分类成不同的垂类,用不同的插帧方法来解决,实现整体最优。



1)场景分类。在时间上做分类,将时间轴上的一个视频按照场景切开,分成了多个场景,把不同场景分成全局运动场景、静止场景、复杂运动场景、片头片尾等。


2)目标的分割。在空间维度将图像分成多个目标区域,例如台标角标的区域、字幕区域、前景背景、露出遮挡的区域。


3)垂类场景的插帧完成后,再经过一些柔性的融合得到最终的插帧结果。


4)人工校对。无论用多么精巧的办法、算法,总会有一些疑难的 case,是技术无法处理的,所以在设计算法时,会自动对疑难 case 进行标记。在审核后台,这些标记区域进行人工审核,对于有问题的插帧结果进行回退处理。



上图是对比图,左侧上方飞掉的字幕,通过对字幕区域的特殊处理以后,已经能够正常做插帧了。右侧,将运动光流进行精细化,让光流更贴合运动的前景轮廓,有效去除在运动物体周报的光圈效应。

2. 高动态的渲染


高动态渲染其实就是 HDR。上图是对比图,左侧是 SDR 效果(画面偏灰,看不清细节);右侧是 HDR 效果,画面很美,点点繁星和山势的暗部细节轮廓都非常清楚。


HDR 是一个成熟概念,行业中有各种各样的 HDR 标准。我们如何区别中间的差异,并选择一个好的 HDR 算法?HDR 解决的是一个从高动态到低动态,从宽色域到色域的映射效果问题。自然景物能够呈现出的亮度范围是非常高动态的,从 1/万 nit 到 1 万 nit 以上都有。但显示设备能够呈现的亮度范围是低动态的,大部分只有几百 nit,而低亮也不够低。要把自然景物呈现到显示器上,就面临着一个从高动态到低动态的映射问题。所以,HDR 的关键不是 8ibt 还是 10bit,也不是 4k 或者 1080,而是去理解内容和设备,确定在什么设备什么环境下,用什么样的映射去渲染内容,达到主观效果的最优。



上图,左侧是亮度从高到低映射,右侧是色彩映射,需要把马蹄形的大的宽色域映射到内部小三角形上面的窄色域。


帧享 HDR 在技术上做了哪些改进?


  • 一是测屏校屏,帧享要做标准的颜色管理,需要将不同颜色做到在不同设备做到显示效果一致,用来排除屏幕的颜色偏移,把颜色做的更加准确。

  • 二是屏幕亮度和色度适配,不同设备的亮度差异非常大,从两三百尼特到上千尼特,我们的测试也发现,即使用标准的 HDR 视频,在不同亮度的设备上面的效果也存在差异。 所以帧享 HDR 采用了多种的流策略,对于超过 500 尼特的屏幕,输出标准 HDR 流;对于低亮屏幕,基于亮度去适配调整出独特的 SDR 流;

  • 三是内容适配。每一个场景的内容,很少是满动态或宽动态,有的场景整体很亮,有的场景整体很黑,这时我们可以取巧一点,将内容所在的部分亮度范围做更好的映射,然后在其他亮度范围,将映射做的差一些,这就是根据内容来做动态映射的一个出发点。帧享的 HDR 也是基于这一特性,用动态元数据,根据场景做动态的 tone mapping。

  • 四是做链路的把控,后期、平台以及端上渲染,都可以做这种映射,但不能各自为战,需要信息互通、互相协同,用统一的映射将效果做到最佳。


下图是 HDR 对比图。



第 1 幅是颜色准确性、渲染颜色准确性的对比。右下角是优酷在苹果上的播放效果显示,其他三张都是同一个安卓手机的不同 APP 的显示效果。因为屏幕本身是有些偏色的,所以可以看到友商两幅图的效果,人脸比较红润,就会红的不太正常。 但是优酷,人的脸色比较正常,更像苹果的颜色显示,所以对比就能说明在我们优酷通过测屏校屏,能够去纠正错误的颜色渲染,然后得到更好的颜色效果。



上幅图是帧享 HDR 的对比图,左侧是 HDR 前(画面颜色整体偏亮,对比小、画面偏灰偏白);右侧是 Tone mapping 后的 HDR 效果,动态 TM 后,扩大对比度,提升了画面质感。

3. 云加端增强

以前,我们常遇到这些问题:为什么视频流很好,到电视上却效果不佳?每个设备的效果不一致,如何兼顾?如果知道内容特性,算法参数可以设置得更好,但实际上我们无法知晓内容特性,所以效果只能打折。以上都反映了一个共同问题,体验是整条链路的体验,必须将云和端协同起来,一起为体验负责。


云和端如何做协同?


云上,在编码前做前处理;端上,在解码后做后处理。我们在云上处理的优势,主要是算力丰富、算力高,并且它是非因果和离线的,可以算得很慢。劣势是云上算的时候,不知道设备信息,所以只能够去做统一的处理,不能单独调优。其次,云上的增强恢复重建,都是增加信息量,所以压缩效率低,压缩后的码率高,导致传输效率降低。在端上,我们知道设备、用户以及环境的信息,用多参数、多种算法做适配,是一个多样性的能力。



我们将云和端联合在一起,用云上的丰富算力做分析,用端上的多样性做呈现,实现优势互补的效果。右图的 4 种情况,1 是纯云端的处理,2 是纯端上的处理,3 是云端都可以处理,4 是云加端的协同处理。


云+端的联合处理到底有哪些应用?


基于算力优势,我们会在云端做复杂的探测、分析、分类,打标签、编码,再将码流和探测出的语义信息、一些结果通过控制流去传输到设备端。用来指导端上的后处理模块进行参数的设置、算法的选择,以及适配处理。例如,通过去块、锐化、超分等让端上效果更出色。



案例一,去块。块效应是压缩导致的,在码率不够或者低亮的场景中。统一的去块,有可能会损失信号的有用细节,使图像变得模糊。但如果我们能够做云加端的配合,可以在源头将流上块的强度、类型都探测出来,然后把信息传到端上,用这种信息去控制端上的去噪去块算法的强度,达到既有效去块又能够保护细节的效果。



案例二,智能满屏的效果对比。


优酷有大量的年代剧,往往是 4:3 比例,现在屏幕尺寸是 16:9,甚至是 23:9、22:9。如果直接播放 4:3 视频,画幅会很小。普通平铺是以图像的中心为中心,这样的构图布局经常会丢一些重要画面。优酷智能平铺是利用 CV 的识别分析能力,将眼睛更关注的信息保存下来,让画面的布局更合理。


所以整个应用过程就是在云端利用分析理解能力,对画面进行自动的分析、提取,将信息与码流一起传到端上,根据信息进行渲染窗口的调整,达到实时的拆切满屏的目的。优势是一个流能够满足各种尺寸屏幕的观看需求。

优酷超高清的愿景

帧享的愿景是,在 5G 和 AI 的背景下,为国内的互联网视频超高清路线提供解法和答案,推进视频的超高清体验的升级,让 C 端用户早日进入到超高清的观影时代。另一个愿景是超高清产业共赢。我们需要有超高清的标准去约束视频产业链条的各方,制作生产出符合超高清标准的内容、设备,培养提升用户心智,使他们愿意为体验买单。只有用户愿意买单,平台才愿意为超高清买单,制作公司才会愿意为超高清买单,实现超高清的商业化、规模化,实现用户、制作、平台、终端整个链条上的共赢。


作者介绍::阿里文娱高级算法专家 张行


2020-04-30 10:311286

评论

发布
暂无评论
发现更多内容

区块链技术发展及应用:现状与挑战

CECBC

区块链

关于微信8.0的一些社交小心思

静陌

微信 张小龙 社交

航运业“搭台” 区块链“唱戏”

CECBC

航运

《程序员修炼之道》- 解决问题,而不是去责备(6)

石云升

程序员 bug修复 28天写作

聊聊我的原创维权二三事

架构精进之路

自我思考 七日更 28天写作

区块链隐私保护、体系结构与智能合约研究

CECBC

区块链

产品 0 期 - 第三周作业

vipyinzhiwei

欢度春节|话题王者 VS 互动先锋(第二季)

InfoQ写作社区官方

话题讨论 热门活动

第十周 模块分解 作业 「架构师训练营 3 期」

胡云飞

技术创业,股权设置的常见“坑” | 视频号28天(24)

赵新龙

28天写作

Spring 动态代理时是如何解决循环依赖的?为什么要使用三级缓存?

程序员小航

spring 源码

Elasticsearch document routing 数据路由

escray

elastic 七日更 28天写作 死磕Elasticsearch 60天通过Elastic认证考试

我看好数据湖的未来,但不看好数据湖的现在

王知无

大数据 数据湖

2021年,开发者的落日

王知无

大数据

Apache老母鸡又下蛋?一文俯瞰Apache Superset

王知无

大数据

2月日更挑战|达标抽奖季,更有暖春大满足礼包等你来

InfoQ写作社区官方

2月春节不断更 热门活动

架构师训练营 - 第五周作业

Mark

【计算机内功修炼】八:函数运行时在内存中是什么样子?

码农的荒岛求生

高并发 内存 高性能 内存管理 运行时栈帧

发布 Go Modules

Rayjun

go modules Go 语言

VS +QT 手动添加Q_OBJECT 报错问题解决

Creep

c++ qt

产品 0 期 - 第三周作业

Jxin

VS2019 + Qt Creator 4.11.1 导入Qt源码进行调试记录

Creep

c++ qt

用helm chart将chripstack部署到kubernetes之上

远鹏

Kubernetes IoT Helm ChirpStack LoraWan

同城快递架构设计

Mars

读2020年Javascript趋势报告展望ES2020

devpoint

大前端 ES2020 构建工具

week10-homework

J

week10-总结

J

数据结构和算法学习总结-复杂度分析

Nick

时间复杂度 数据结构与算法 复杂度

企业是如何解决HDFS单点问题的?

大数据老哥

大数据 hadoop

Reactive Spring实战 -- 响应式Redis交互

binecy

redis Reactive Spring

Mybatis【17】-- Mybatis自关联查询一对多查询

秦怀杂货店

数据库 mybatis

5G超高清关键技术:高帧率重置、高动态渲染、云加端增强_行业深度_阿里巴巴文娱技术_InfoQ精选文章