最新发布《数智时代的AI人才粮仓模型解读白皮书(2024版)》,立即领取! 了解详情
写点什么

淘宝直播三大核心技术揭秘

  • 2020-09-04
  • 本文字数:6890 字

    阅读完需:约 23 分钟

淘宝直播三大核心技术揭秘

本文分享内容主要分为四个部分:


  • 全民直播大时代的背景介绍

  • 直播痛点分析

  • 淘宝直播窄带高清技术

  • 音视频技术趋势探讨

背景-全民直播大时代


在疫情的影响下,直播从传统的秀场应用逐渐渗透到行业的各个领域。包括在线课堂,旅游,政企,房车销售等等,可以说是全民直播时代已经到来。



在这样的一个大背景下,过去一年淘宝直播得以快速发展。2019 年,淘宝直播拥有了 4 亿+的年度用户规模,有 100 万+年度主播入驻,2000 亿+年度直播成交以及 4000 万+直播商品。春节期间,钉钉在线课堂更是有 350 万+的教师主播,为 1.2 亿+中小学生提供了在线课程服务。

直播痛点分析


在这么大的一个业务体量下,我们将会面对非常多的难点与挑战。总的来说,包含以下三个部分,首先是成本,包括带宽、存储和转码三个方面。其次是用户体验,例如画质,音质,秒开、卡顿和延时。最后是效率方面,例如开播的效率、审核的效率和理解分发的效率。接下来我们就来看一下淘宝在成本和体验优化方面做了哪些工作。

淘宝直播窄带高清技术

淘宝直播窄带高清


淘宝直播有三大核心技术, 第一大核心技术是端上窄带高清。 我们采用 HEVC 编码实现了 720p,25fps,800kbps 的压缩,并且 PSNR> 43db/VMAF>90。端上窄带高清技术主要应用有三个方面:第一是音视频增强,采用基于 AI 的图像增强、美颜和语音增强来提高生产质量。第二是感知处理,采用信源信道联合自适应编码。第三是 S265 编码器,S265 编码器是业界领先的 HEVC 编码器。


第二大核心技术是零转码系统, 我们实现了端到端原始流生产的和播放,成功的解决了两个核心的痛点问题:不同网络速度的兼容和不同播放设备的兼容,后者主要通过高性能解码器实现 iOS,Android 和 H5 三端的 100%解码。


第三大核心技术是低延时技术, 我们实现了端到端秒级延时。主要依靠两个技术,一个是基于 RTC 的实时直播系统,第二个是 S265 低延时编码技术。

淘宝直播系统架构


如图所示淘宝直播的系统架构,从生产侧来看,有采集、增强、感知处理、S265 编码四个环节。云端我们有边缘的接入,有中心接入、切片录制和 CDN 分发以及边缘分发。在播放端有拥塞控制、解码、渲染和显示。除此之外,在云端还有内容审核,质量监控,内容理解和智能分发。

端上窄带高清


生产侧的第一个环节是图像增强,为了提升主观质量,我们引入了图像增强技术,对编码前的视频做去噪、去抖、纹理增强以及美颜、美型的功能。除此以外,在后处理部分,我们还引入了适时超分和 HDR 技术来提高观看质量。在美颜、美型以及图像处理等方面,我们引入了 GPU 的技术,包括内存带宽优化、shader 优化、Pipeline 优化等等以减少 GPU 的开销。



针对音质的优化,我们采用了智能降噪技术。无论是在 STO 还是 PESQ 的指标上都显著高于传统 WebRTC 算法,在性能和包大小方面也都可以实现普通设备的覆盖。下面播放的三段音频,分别是原始音频、RTC 降噪和阿里降噪音频。原始音频我们可以明显听到马路上车呼啸而过的声音非常强烈。RTC 降噪音频中降噪产生了一定的效果,但是汽车飞驰而过的呼啸声还是非常明显。而在阿里降噪音频中,我们可以听到汽车呼啸而过的声音已经基本消失。



生产的第二个环节是感知处理。我们采用信源信道联合自适应编码技术。 感知处理分为 5 个方面。


首先是 ROI 区域的感知, 我们基于 PixelAI 人脸检测加商品检测,对 ROI 区域进行提取和重点编码。


第二是场景的感知, 不同的场景适合不同的编码参数,我们通过对场景进行分类,对于不同的场景赋予不同的编码参数来提高压缩质量。


第三个是智能码控 CARC, 我们采用机器学习的码率控制,对简单场景赋予较低的码率,对复杂的场景赋予较高的码率来实现对带宽的节省。


第四个是网络带宽的感知, 在网络比较好的时候,我们会采用比较高的码率来实现画质的提升,在网络不太好的时候,会降低码率,避免发生带宽拥塞,由于 cdn 采用峰值收费,峰谷时间段还可以采用不同码率策略。


最后是设备算力的感知, 不同的设备拥有不同的算力,我们可以实时检测设备的算力情况及时调整编码的档次,以此来实现对算力和质量的平衡。



生产的第三个环节是编码,这又要讲到我们核心的 S265 编码器,得益于 S265 编码器的编码压缩技术,我们实现了淘宝直播的 720p、800kbs、25fps 编码,相比于业界常见的 720p 1600kbps 节省了 50%的带宽。


钉钉的在线课堂我们更是把码率压缩到了 200kbs,并实现了 43db 以上的质量。S265 是淘宝和阿里云共同发起的 HEVC 编码器,目前已经实现集团内部的开源,并落地在点播、直播会议等各个场景中。相比起业界优秀的 HEVC 编码器,S265 在 PSNR 指标上有比较大的优势。首先在编码工具提升方面,我们做了大量工作,实现了 HierarchyB、GPB、Bi-Search、Longterm、RDOQ、AdaptGOP 等编码工具,并且对这些工具进行了大量的算法和速度优化。


我们还设计了 50 多种快速算法,比如说 Deblock 的优化,编码速度对比 X265 有 1 倍以上的提速。在工程上的优化,我们做了浮点转定点、位宽的缩减、SIMD 的优化、冗余去除、访存效率提升及循环展开等等来提升我们的编码速度。


在框架方面,我们还做了线程调度优化等等。在码率控制方面,我们对帧级别码控和块级别码控分别进行了优化,并且对 2pass 编码进行了原创性的优化来提高 2pass 编码的质量。在块级别码控中,我们设计了新的 CUTree 和 AQ 算法。



下面来看一下 S265 的几个典型优化,首先是 CU 划分决策,我们把 CU 划分决策模块分成两个步骤,一是纹理强度决策,通过计算 CU 的纹理梯度来判别平坦块和复杂块,如果是平坦块就直接退出,如果是复杂块就继续向下划分。


第一步可以解决大部分块划分的决策问题,但是对于模棱两可的块,则需要依靠 CNN 模型来辅助划分。我们使用了一个 5 层网络的小模型把决策的准确度从 72%提升到了 96%;这个成果我们跟清华大学刘老师合作发表了一篇论文,在 DCC 会议上展示。



第二个方面的优化是运动搜索方面的优化。运动搜索是从参考帧寻找最佳匹配块的过程,包含整像素搜索和分像素搜索,分像素需要做 7 抽头或 8 抽头插值滤波,计算量大;整像素搜索已经有比较多的快速算法,比如菱形搜索、六边形搜索及分层搜索,但分像素搜索一直没有什么好的方法。比如在图中矩形的整像素周围,分布着 60 个分像素点,如果要对分像素点进行全部搜索的话,需要 60 次,经过优化之后一般需要搜 4 个、8 个或 16 个点,但搜索次数还是比较多的。


我们采用一个二元二次误差平面方程,用 9 个整像素点的预测误差来求解方程的 5 个系数,再对方程求偏导,可得到最佳分像素点的位置。只需对这个最佳分像素点计算 1 个 1/4 差值,就可以完成我们的搜索过程。这个技术在编码器的整个提速有 12%,但 bd-PSNR 只有-0.016db。这些成果在 VCIP 2016 上可以看到。



第三个是我们的码率控制。ABR 是较适合直播的一种码率控制方法。但 HM 中基于𝑅−𝜆模型的码率控制方法没有考虑图像块与块之间的参考强度,有些块会被后续帧参考有些不会,应该根据一个块被参考的强度来决定它的量化系数。x265,x264 中引入了 MB-Tree 技术,但是由于帧的 QP 定制不合理,编码效率不高且码控准确度比较差,我们测过平均只有 90%左右。


我们根据“每 1 个 bit 被分配到任何一个 CU,产生的边际价值都相同”这样一个原则,对 MB-Tree 方法进行了理论创新,使得编码精度提升到了 97%,且编码质量提升了 0.65db,对应 17%的码率节省。


这里有包含三个技术,第 1 个,I 帧的 QP 推导,x265 使用了一个经验值,没有考虑到视频本身的特性,这样做很不合理,我们用预分析中低分辨率图像的复杂度和目标码率,经过多次迭代搜索得到准确的 QP;


第 2 个,随着时间的推移,历史帧的复权重越来越高,新产生的帧权重越来越低,导致其不能很快的响应复杂度的变化,我们根据新产生的帧的参考强度计算出一个𝜆 QP,跟原来的 QP 做加权得到真正的 QP,可以及时的反应新产生帧及其后续帧的复杂度;


第 3 个,x265 采用基于 Viterb 的 P 帧决策方法,每个帧都需要跟历史帧比较,复杂度很高,并在判决 P 帧时没有考虑 QP 的影响,准确率也不高。我们的算法只需要计算相邻帧的变化率,并引入 QP 来作为判决阈值,大幅降低了计算复杂度并提高了准确度。这个成果我们与清华大学刘老师合作发表在 TIP 2019 05 月期刊上。



第四点我们来看一下 S265 智能码控技术(CARC)。ABR 追求码率控制的精准度,但是它忽略了场景的平均复杂度。如果设定一个统一的码率目标,简单的场景会出现码率过剩,复杂场景会出现码率不足。


另一个方面,人眼对失真的敏感度存在衰减效应,高于一定阈值敏感度下降,此时存在码率过剩。我们采用一个 CNN 模型对场景进行分类,计算出场景的复杂度因子,根据复杂度因子调节编码码率,可消除简单场景下的码率过剩( > 42db),并提高复杂场景的质量。


平均下来,我们可以节省 15-30%的码率,以钉钉在线课堂为例,大部分时间画面是静止或慢速运动的,少数时间会播放教学影片,CARC 可以保证播放影片时的质量,同时在静止场景节省大量码字,经过后台统计,钉钉在线课堂 720p 码率在 200kps,且 PSNR 保持在 43db 以上。



最后,我们还有一个画质评价环节。业界常见的客观评价指标有 PSNR,SSIM,VMAF,但这些指标只适合于有源场景;但淘宝内容存在大量的无源场景,比如商家上传的视频,手机硬编码的直播视频,这样的视频,都没有参考对象。针对这种场景,我们训练了基于 CNN 的 VQA 无源评价模型来对视频图像的质量进行评价,并实现对大盘质量的监控,此外,为了指导线下开发,我们还有一个主观评价系统。



接下来让我对淘宝的 S265 编码器做一个简单的总结。MSU 国际编码器大赛是大家所熟知的一个比赛。在去年的比赛中有 100 个序列,同时有 1080p 和 4k 两种测试,有 3 种速度档次,还包括主观和客观测试。


我们用 S265 对 MSU 2019 1080p 的测试序列进行了测试,我们的 PSNR 的指标三个档次上平均节约了 42.1%的码率,对比 2019 年第一名是 37.3%,说明 S265 的 PSNR 指标在业界领先。下面的两张图片,左边是 X265 的结果,右边是 S265 的结果,S265 在主观质量上也有比较大的提升,这里特别感谢清华刘老师在 S265 项目中给予的帮助。

零转码系统


淘宝直播的第二大核心技术是 零转码系统 。普通的有转码系统为了适应不同的网络环境,通常会在服务器集群上对上行码流进行各种分辨率、各种码率的压缩来应对各种网络环境,对于一个好的网络,可能更偏向播出一个高分辨率的视频,如果用户的网络不好,会选择播放低分辨率低码率的视频。


淘宝直播则实现了零转码,播放的是原始的生产流。这需要解决三个核心问题。


第一个是端侧生产, 我们要生产出高质量低码率视频,这个得益于前面说的 S265 编码器以及前处理技术。


第二个就是 H265 的解码兼容性, 目前 H265 在 Web 解码以及手机芯片解码的兼容上做得还不够好,我们在此做了大量的工作来解决这个问题。


第三个是网络环境的适应能力 ,我们可以通过 SVC 技术来适应客户不同的网络环境。



淘宝直播的零转码系统首先需要解决的是 H265 的百分之百解码。对于现在常见的高端芯片,例如 iphone7 以上的手机以及中高端以上的安卓手机都已经支持 H265 的解码,但还有大量的中低端设备并不能支持 H265 的硬解,所以我们开发了一个高性能 H265 解码器。


我们的解码器相比 FFmpeg 有 140%的提速,比业界常见的 libhevc 也快了许多,相比竞品 K 也有 10%以上的提速,可以实现低端机的软解。除此以外,Web 端的解码一直是 H265 的一个痛点,我们实现了 WebAssembly 的解码方案,可以覆盖大部分 pc 解码能力。


除此之外,还有 Webkit+Native 的解码方式。通过这些努力,我们把 H265 的解码实现安卓、IOS 以及 web 端百分之百的兼容从而完全去除转码的环节。



零转码系统需要解决的第二个核心问题是网络自适应技术。这项技术得益于三个方面。


第一个是我们低码率高质量的生产,我们生产的 800kbps 码流在 90%以上网络都可承载。


第二个是时域可分层 SVC 策略,如图,在用户网络较好时,淘宝直播会使用 100%的下发帧率,如果用户网络不好,将会采用 3/4 抽帧来实现 18 帧的解码效果,如果用户网络效果还是不理想,会选择抽取 1/2 的帧来实现 12.5fps 的解码效果。除此以外还有一个基于 A3C 网络来综合用户的网络缓存以及用户当前的编码质量来实现 QoE 的最大化。

低延时技术


淘宝直播的第三个核心技术是低延时技术。我们实现了直播端到端秒级延时,还验证了低延时技术的业务价值;


除此之外,低延时还可以支持新业务形态,如拍卖直播、客服直播等。传统的 HLS/FLV 直播协议的延时,从生产侧来看主要有编码延时、网络延时、分发延时、切片缓冲和播放缓冲,整体加起来大概有 10s 左右的延时。Flv 去除了服务器上的切片缓冲,可以把延时降低到 5s 左右,但延时时间还是比较长。


但淘宝直播的秒级延时采用了 UDP 的流媒体传输协议,WebRTC 的拥塞控制及 FEC、netEQ 的拥塞控制算法来去除播放器缓冲,并且尽我们最大努力减少防抖缓冲的大小。在生产侧,我们还采用了低延时的编码技术来降低编码器的延迟。



这是我们在低延时编码上做的工作。编码延时主要来源三个方面:B 帧、Lookahead 以及 Frame thread。以 x265 为例,编码效率在一定区间内与延时成正比。当延时降低到 8 帧时,编码效率下降 20%,5 帧的编码效率下降 30%;优化后 S265 采用了短距 Lookahead CU-tree 传播代价以及运动强度,作为机器学习模型的训练数据,预测长距 lookahead CU-tree 传播代价来提高我们在低 Lookahead 下的编码质量。如图,S265 在 5 个延时帧下,可达到 95%以上的编码效率。



最后一起来讨论一下音视频技术的发展趋势。我个人觉得传统信号处理已经非常成熟,AI 又有比较强的学习能力,所以怎么结合传统信号处理的优势和 AI 的学习能力来提高我们内容的生产以及内容理解、传输等等的效率是我们下一步的发展趋势。


主要包含五个方面,第一个是视频编解码,第二个是智能语音处理,第三个是图像增强技术,第四个是内容理解算法,第五个是高效传输技术。

基于音视频技术趋势探讨

视频编解码


首先来看一下视频编解码,视频编解码的第一个趋势是云边端一体编码系统。


硬编码主要面对的挑战是 压缩效率 。我们知道传统的手机芯片压缩都会考虑到 PPA 问题,所以会提供一个相对而言较低的压缩效率。


软编码的挑战主要是 压缩速度 ,虽然有些像 Intel 的 SVT 技术可以把压缩速度提到比较高的水平,但是画质会有一些受损。


未来趋势个人觉得 尽可能的利用到端侧的算力 ,采用高性能软编码器来缓解云端转码的成本压力 ,把手机芯片硬编码能力利用起来,但是移动端芯片硬编码的质量还不够好, 如何优化移动端芯片硬编码质量是一个关键的点


其次是云+边的统一的转码。现在越来越多的 ASIC 芯片和 GPU 芯片已经在努力优化编码的质量,包括 FPGA 芯片也有优化方案。所以云+边的转码会成为我们下一阶段研究的重点。


视频编解码的第二个趋势是 下一代编码标准的应用 。主要有 H266、AV1、AVS3,这三个标准目前是各有自己的优势。H266 在传统芯片的支持上比较好;AV1 有先发优势,而且 Web 兼容性较好,在专利上也有些优势;AVS3 经过大家的努力,已经拥有国内生态,且在实体清单的影响下 AVS3 的发展可能会加速。


第三个趋势是 AI+编码 。大家也注意到 CVPR 比赛的情况,AI 压缩可以实现对比 H266 更好的压缩结果,但是在解码速度方面还是会有一些问题,端到端 DL 压缩在未来会是一个研究热点。除此以外,混合编码框架下的 AI 压缩也是一个研究热点;第三是场景自适应编码技术,能够根据场景选择编码也是一个很好的技术;第四个是无参考评价系统,在很多时候,有参考可以评价的比较客观,但很多时候,我们拿不到参考,这时候,无参考评价系统就会比较有优势。

智能语音处理


对于智能语音处理,总结下来主要也分为三个方面。


第一是前端 3A 处理, 主要考察 PESQ,STOI 的指标以及处理和收敛速度,智能降噪,智能回声消除,盲源分离技术,自动增益技术也会是信号处理和 AI 的非常好的结合点;


第二是后端网络自适应, 先考察丢包下的声音体验。这里有音频超分,智能 PLC,自适应码率以及 RSFEC、NACK 来实现恢复与延时的平衡等等;


第三,音效与评价主要考察核声音的主观体验, 如何做到智能美声、自动混响和无参考评价会是我们研究的方向。

图像增强、视频内容理解、高效传输技术


第三个方面是图像增强,即如何利用传统图像增强与 AI 结合达到智能去噪、暗光增强、智能选帧和拍摄辅助的效果。


第四个方面视频内容理解,可以用多模态技术来理解视频内容包括通用物体检测、文本语义理解、自然语言处理 NLP、标签体系和大规模检索技术等等。


第五个方面是高效传输技术,5G 的到来可以提供高带宽,低延时的传输,如何利用 5G 优势实现智能带宽预测,智能调度系统是我们在网络传输方面研究的一个方向。


作者介绍


王立波(庄恕),淘系技术部高级算法专家,毕业于上海交通大学少年班、应用数学系。现为淘宝直播音视频算法负责人,是 S265 编码器的核心成员,参与完成的项目《编码摄像关键技术及应用》获得 2019 年国家科技进步二等奖。


本文转载自公众号淘系技术(ID:AlibabaMTT)。


原文链接


淘宝直播三大核心技术揭秘


公众号推荐:

跳进 AI 的奇妙世界,一起探索未来工作的新风貌!想要深入了解 AI 如何成为产业创新的新引擎?好奇哪些城市正成为 AI 人才的新磁场?《中国生成式 AI 开发者洞察 2024》由 InfoQ 研究中心精心打造,为你深度解锁生成式 AI 领域的最新开发者动态。无论你是资深研发者,还是对生成式 AI 充满好奇的新手,这份报告都是你不可错过的知识宝典。欢迎大家扫码关注「AI前线」公众号,回复「开发者洞察」领取。

2020-09-04 10:082641

评论

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

阿里云架构师张先国:揭秘ECS倚天实例背后的技术

云布道师

算力 云栖大会 倚天实例

注意 ! !|95% 的应用程序中发现错误配置和漏洞

SEAL安全

配置管理 软件供应链安全 漏洞管理

详解Native Memory Tracking之追踪区域分析

华为云开发者联盟

开发 内存 华为云

AntDB入选《2022爱分析·信创厂商全景报告》

亚信AntDB数据库

AntDB 信创 国产数据库 aisware antdb AntDB数据库

技术分享 | 多测试环境的动态伸缩实践

LigaAI

云原生 自动化测试框架 测试环境 测试自动化 kubenetes

Fiori Elements 应用进行二次开发的一个具体案例分享

Jerry Wang

SAP Fiori ui5 Web应用 11月月更

《全国一体化政务大数据体系建设指南》发布,隐私计算将如何发挥作用?

洞见科技

《关键信息基础设施安全保护要求》于明年五月正式实施

行云管家

网络安全

诚迈科技深耕汽车操作系统领域,获评优质供应商

科技热闻

教你一招,安全的从 MySQL 切换到 TiDB

TiDB 社区干货传送门

迁移 实践案例

谈谈前端应用里图标(Icon)的渲染和内容提取方式

Jerry Wang

前端开发 SAP ui5 Web应用 11月月更

React的5种高级模式

夏天的味道123

React

React生命周期深度完全解读

夏天的味道123

React

全国独家 | 上海线下面授大规模敏捷LeSS认证 | 2022年12月8-10日

ShineScrum捷行

less 大规模敏捷 LeSS认证 吕毅老师

使用Docker踩坑,排查完问题之后,又涨知识了

程序员小毕

Java Docker 程序员 程序人生 后端

低代码实现探索(五十三)后台逻辑的控制

零道云-混合式低代码平台

# 分布式数据库新秀TIDB初探

TiDB 社区干货传送门

TiDB 底层架构 TiDB 源码解读

react源码中的协调与调度

flyzz177

React

CQRS与Event Sourcing

胖子笑西风

架构 DDD CQRS Event Sourcing #java

GaussDB CN服务异常实例分析

华为云开发者联盟

数据库 华为云 GaussDB

React源码中的dom-diff

夏天的味道123

React

技术分享 | TiUP工具 - TiDB集群滚动升级核心流程解析

TiDB 社区干货传送门

年搜索量超7亿次背后:这款APP用火山引擎 DataTester 完成“数据驱动”

字节跳动数据平台

大数据 数据分析 A/B测试

Kata3.0.0 x LifseaOS x 龙蜥内核三管齐下!带你体验最新的安全容器之旅

OpenAnolis小助手

容器 云原生 内核 龙蜥社区 袋鼠RunD

【专项测试系列】-缓存击穿、穿透、雪崩专项测试

京东科技开发者

缓存 测试 缓存穿透 缓存击穿 缓存雪崩

Go类型转换和类型断言可别搞混了

王中阳Go

golang 高效工作 学习方法 面试题 11月月更

阿里Redis最全面试全攻略,读完这个就可以和阿里面试官好好聊聊

钟奕礼

Java java程序员 java面试 java编程

react源码中的hooks

flyzz177

React

react源码中的fiber架构

flyzz177

React

10年码农生涯经验总结,聊聊工作中18种接口优化方案!

Java全栈架构师

Java 数据库 程序员 程序人生 性能优化

云安全系列3:如何构建云安全策略

HummerCloud

云计算 数据安全 云安全 11月月更

淘宝直播三大核心技术揭秘_架构_王立波_InfoQ精选文章