用时:29ms

云计算研究报告-PDF版

您的当前位置:首页 > 人工智能 > 云计算
  • 算力行业深度报告:海外科技启示录英伟达(1)超级工厂是怎样炼成的-240408(34页).pdf

    证券研究报告|行业深度|计算机 1/34 请务必阅读正文之后的免责条款部分 计算机 报告日期:2024 年 04 月 08 日 海外科技启示录:英伟达(海外科技启示录:英伟达(1)超级工厂是怎样炼成的.

    浏览量0人已浏览 发布时间2024-04-12 34页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • 火山引擎:火山引擎视频云技术实践精选集2023版(173页).pdf

    火山引擎视频云2023版技 术 实 践 精 选 集抖音同款的音视频技术实践与前沿探索面 向 体 验 驱 动 增 长卷首语FOREWORD龙年开端,OpenAI 推出的视频生成模型,横空出世,引发业界广泛关注,而 24 年也被认为是AI 视频元年,从泛互联网到全行业应用,从 2D视频到 3D 互动,从虚实结合到虚实融合,技术将推动我们走向全新的世界。而技术从来不曾孤单,它在无尽的探索中寻找同伴,渴望得到协助,一同照亮未知的领域。共享与进化,是它永恒的方向,每一步前行都承载着时代的梦想,引领我们共同迈向一个更加美好的未来。火山引擎视频云,基于抖音集团音视频技术沉淀,致力于打造面向体验的视频云,帮助企业端到端提升视频能力,实现播放体验、画质体验、交互体验、性能体验的全面提升与创新。特别推出 火山引擎视频云实践精选集 2023版,收录了全年 70 余位音视频专家倾情出品的 24 篇技术深度 Blog,期待给各位同仁带去一些思考和启发的同时,也能在 AI 视频元年到来的今天,一起探索、融合和推动音视频技术进步和发展。精选集内容将围绕火山引擎视频云与抖音集团在过去一年的音视频技术实践,包括:计算机视觉、人工智能&视频质量、音频技术领域等全球前沿的论文精选;AIGC、6DoF 互动、三维重建等能力叠加的技术探索;画质、交互、播放、性能等用户指标的体验优化;赛事、游戏、汽车、VR 大空间等行业场景的最佳实践;目录CONTENTSInterspeech 2023火山引擎流媒体音频技术之语音增强和 AI 音频编码火山引擎获全国人工智能大赛 AI 视频质量评价冠军CVPR 2024 满分论文DEFORMABLE 3D GAUSSIAN:基于可变形 3D 高斯的高质量单目动态重建新方法CVPR 2024MODULAR BLIND VIDEO QUALITY ASSESSMENT模块化无参视频质量评估CVPR 2024CAMixerSR 动态注意力分配的超分辨率加速框架技术探索1234和德爷一起 6DoF 互动探险火山引擎空间重建和虚实融合技术让文物“活”起来揭秘火山引擎视频云三维重建技术基于深度学习的超分辨率效果优化火山引擎实时、低延时拥塞控制算法的优化实践云上智能驾驶三维重建最佳实践035041048053061如何利用播放器节省 20%点播成本?深度解读字节跳动的画质评估工具抖音也在用实战超低延时直播技术的落地实践超低延时直播技术演进之路WebTransport 开播的应用实践之路veImageX 演进之路:iOS 高性能图片加载 SDKRTC 端到端视频体验优化技术实践与探索视频时代需要一个新的“体验增长论”了0690760840981051101 1 7129抖音世界杯的画质优化实践解析“世界杯直播”技术实践解析:抖音视频编码器优化抖音世界杯直播的低延迟是怎么做到的?游戏出海,如何让全球玩家“纵享丝滑”体验?毫末智行&火山引擎,迈向自动驾驶“智”高点龙游神州:揭秘云 VR 大空间背后的技术魔法137141145158160163全球前沿THE GLOBAL FRONTIERTECHNOLOGY EXPLORATION体验优化EXPERIENCEOPTIMIZATION最佳实践BESTPRACTICEPARTPARTPARTPART003017019023029全球前沿01THE GLOBAL FRONTIER全球前沿003Interspeech 2023 火山引擎流媒体音频技术之语音增强和 AI 音频编码 基于可学习梳状滤波器的轻量级语音谐波增强方法 基于 Intra-BRNN 和 GB-RVQ 的端到端神经网络音频编码器 基于两阶段渐进式神经网络的回声消除方法 CHiME-7 无监督域自适应语音增强(UDASE)挑战赛冠军方案摘要THE GLOBAL FRONTIER004背景介绍BACKGROUND为了应对处理各类复杂音视频通信场景,如多设备、多人、多噪音场景,流媒体通信技术渐渐成为人们生活中不可或缺的技术。为达到更好的主观体验,使用户听得清、听得真,流媒体音频技术方案融合了传统机器学习和基于 AI 的语音增强方案,利用深度神经网络技术方案,在语音降噪、回声消除、干扰人声消除和音频编解码等方向,为实时通信中的音频质量保驾护航。作为语音信号处理研究领域的旗舰国际会议,Interspeech 一直代表着声学领域技术最前沿的研究方向,Interspeech 2023 收录了多篇和音频信号语音增强算法相关的文章,其中,火山引擎流媒体音频团队共有 4 篇研究论文被大会接收,论文方向包括语音增强、基于 AI 编解码、回声消除、无监督自适应语音增强。值得一提的是,在无监督自适应语音增强领域,字节跳动与西工大联合团队在今年的CHiME(Computational Hearing in Multisource Environments)挑战赛子任务无监督域自适应对话语音增强(Unsupervised domain adaptation for conversational speech enhancement,UDASE)获得了冠军(https:/www.chimechallenge.org/current/task2/results)。CHiME 挑战赛是由法国计算机科学与自动化研究所、英国谢菲尔德大学、美国三菱电子研究实验室等知名研究机构所于 2011 年发起的一项重要国际赛事,重点围绕语音研究领域极具挑战的远场语音处理相关任务,今年已举办到第七届。历届 CHiME 比赛的参赛队伍包括英国剑桥大学、美国卡内基梅隆大学、约翰霍普金斯大学、日本 NTT、日立中央研究院等国际著名高校和研究机构,以及清华大学、中国科学院大学、中科院声学所、西工大、科大讯飞等国内顶尖院校和研究所。本文将介绍这 4 篇论文解决的核心场景问题和技术方案,分享火山引擎流媒体音频团队在语音增强,基于 AI编码器,回声消除和无监督自适应语音增强领域的思考与实践。全球前沿005背景受限于时延和计算资源,实时音视频通信场景下的语音增强,通常使用基于滤波器组的输入特征。通过梅尔和 ERB等滤波器组,原始频谱被压缩至维度更低的子带域。在子带域上,基于深度学习的语音增强模型的输出是子带的语音增益,该增益代表了目标语音能量的占比。然而,由于频谱细节丢失,在压缩的子带域上增强的音频是模糊的,通常需要后处理以增强谐波。RNNoise 和 PercepNet 等使用梳状滤波器增强谐波,但由于基频估计以及梳状滤波增益计算和模型解耦,它们无法被端到端优化;DeepFilterNet 使用一个时频域滤波器抑制谐波间噪声,但并没有显式利用语音的基频信息。针对上述问题,团队提出了一种基于可学习梳状滤波器的语音谐波增强方法,该方法融合了基频估计和梳状滤波,且梳状滤波的增益可以被端到端优化。实验显示,该方法可以在和现有方法相当的计算量下实现更好的谐波增强。模型框架结构为了降低基频估计难度并使得整个链路可以端到端运行,将待估计的目标基频范围离散化为 N 个离散基频,并使用分类器估计。添加了 1 维代表非浊音帧,最终模型输出为 N 1 维的概率。和 CREPE 一致,团队使用高斯平滑的特征作为训练目标,并使用 Binary Cross Entropy 作为损失函数:基频估计器(F0 Estimator)对上述每一个离散基频,团队均使用类似PercepNet的FIR滤波器进行梳状滤波,其可以表示为一个受调制的脉冲串:可学习梳状滤波器(LEarnabLE Comb FiLtEr)基于可学习梳状滤波器的轻量级语音谐波增强方法论文地址:https:/www.isca-speech.org/archive/interspeech_2023/le23_interspeech.htmlTHE GLOBAL FRONTIER006在训练时使用二维卷积层(Conv2D)同时计算所有离散基频的滤波结果,该二维卷积的权重可以表示为下图矩阵,该矩阵有 N 1 维,每一维均使用上述滤波器初始化:通过目标基频的独热标签和二维卷积的输出相乘得到每一帧基频对应的滤波结果:模型结构谐波增强后的音频将和原始音频加权相加,并和子带增益相乘得到最后的输出:在推断时,每一帧仅需要计算一个基频的滤波结果,因此该方法的计算消耗较低。全球前沿007团队使用双路卷积循环神经网络(Dual-Path Convolutional Recurrent Network,DPCRN)作为语音增强模型主干,并添加了基频估计器。其中 Encoder 和 Decoder 使用深度可分离卷积组成对称结构,Decoder 有两个并行支路分别输出子带增益 G 和加权系数 R。基频估计器的输入是 DPRNN 模块的输出和线性频谱。该模型的计算量约为 300 M MACs,其中梳状滤波计算量约为 0.53M MACs。模型训练在实验中,使用 VCTK-DEMAND 和 DNS4 挑战赛数据集进行训练,并使用语音增强和基频估计的损失函数进行多任务学习。实验结果流媒体音频团队将所提出的可学习梳状滤波模型和使用 PercepNet 的梳状滤波以及 DeepFilterNet 的滤波算法的模型进行对比,它们分别被称作 DPCRN-CF、DPCRN-PN 和 DPCRN-DF。在 VCTK 测试集上,本文提出的方法相对现有方法均显示出优势。同时团队对基频估计和可学习的滤波器进行了消融实验。实验结果显示,相对于使用基于信号处理的基频估计算法和滤波器权重,端到端学习得到的结果更优。ModelSDR(dB)STOIPESQ MACs(M)Noisy8.390.9211.97-PercepNet 10-2.73800DeepFilterNet 1 116.60.9422.81350DeepFilterNet2-0.9433.08360DPCRN17.90.947 3.03299DPCRN-PN18.30.9453.06300DPCRN-PN ideal R18.50.9493.10300DPCRN-DF18.10.9443.06310DPCRN-CF18.50.9493.12300DPCRN-CF rescaling18.40.9483.13300ModelSIGBAKOVLNoisy(DNS-4 blind primary)4.162.973.31DPCRN-CF4.124.423.83DPCRN-CF(pYIN)4.124.353.77DPCRN-CF(Learnable weights)4.134.453.85ModelModelSDR(dB)SIGSTOIBAKPESQOVLMACs(M)THE GLOBAL FRONTIER008基于 Intra-BRNN 和 GB-RVQ 的端到端神经网络音频编码器论文地址:https:/www.isca-speech.org/archive/pdfs/interspeech_2023/xu23_interspeech.pdf背景近年来,许多神经网络模型被用于低码率语音编码任务,然而一些端到端模型未能充分利用帧内相关信息,且引入的量化器有较大量化误差导致编码后音频质量偏低。为了提高端到端神经网络音频编码器质量,流媒体音频团队提出了一种端到端的神经语音编解码器,即 CBRC(Convolutional and Bidirectional Recurrent neural Codec)。CBRC 使用 1D-CNN(一维卷积)和 Intra-BRNN(帧内双向循环神经网络)的交错结构以更有效地利用帧内相关性。此外,团队在 CBRC 中使用分组和集束搜索策略的残差矢量量化器(Group-wise and Beam-search Residual Vector Quantizer,GB-RVQ)来减少量化噪声。CBRC 以 20ms 帧长编码16kHz 音频,没有额外的系统延迟,适用于实时通信场景。实验结果表明,码率为 3kbps 的 CBRC 编码语音质量优于 12kbps 的 Opus。模型框架结构CBRC 总体结构全球前沿009分组和集束搜索残差矢量量化器 GB-RVQCBRC 使用残差矢量量化器(Residual Vector Quantizer,RVQ)将编码网络输出特征量化压缩到指定比特率。RVQ 以多层矢量量化器(Vector Quantizer,VQ)级联来压缩特征,每层 VQ 对前一层 VQ 量化残差进行量化,可显著降低同等比特率下单层 VQ 的码本参数量。团队在 CBRC 中提出了两种更优的量化器结构,即分组残差矢量量化器(Group-wise RVQ)和集束搜索残差矢量量化器(Beam-search RVQ)。Group-wise RVQ 将 Encoder 输出进行分组,同时使用分组的 RVQ 对分组后特征进行独立量化,随后分组量化输出拼接输入 Decoder。Group-wise RVQ 以分组量化方式降低了量化器的码本参数量和计算复杂度,同时降低了CBRC 端到端训练难度进而提升了 CBRC 编码音频质量。Encoder 和 Decoder 网络结构Encoder 采用 4 个级联的 CBRNBlocks 来提取音频特征,每个 CBRNBlock 由三个提取特征的 ResidualUnit 和控制下采样率的一维卷积构成。Encoder 中特征每经过一次下采样则特征通道数翻倍。在 ResidualUnit 中由残差卷积模块和残差双向循环网络构成,其中卷积层采用因果卷积,而 Intra-BRNN 中双向 GRU 结构只处理 20ms 帧内音频特征。Decoder 网络为 Encoder 的镜像结构,使用一维转置卷积进行上采样。1D-CNN 和 Intra-BRNN 的交错结构使 Encoder 和 Decoder 充分利用 20ms 音频帧内相关性而不引入额外的延时。分组残差矢量量化器 Group-wise RVQ集束搜索残差矢量量化器 Beam-search RVQTHE GLOBAL FRONTIER010模型训练在实验中,使用 LibriTTS 数据集中 245 小时的 16kHz 语音进行训练,将语音幅度乘以随机增益后输入模型。训练中损失函数由频谱重建多尺度损失,判别器对抗损失和特征损失,VQ 量化损失和感知损失构成。团队将 Beam-search RVQ 引入到神经音频编码器端到端训练中,使用 Beam-search 算法选择 RVQ 中量化路径误差最小的码本组合,以降低量化器的量化误差。原 RVQ 算法在每层 VQ 量化中选择误差最小的码本为输出,但每层 VQ 量化最优的码本组合后不一定是全局最优码本组合。团队使用 Beam-search RVQ,在每层 VQ 中以量化路径误差最小准则保留 k 个最优的量化路径,实现在更大的量化搜索空间中选择更优的码本组合,降低量化误差。实验结果主客观得分为了评估 CBRC 编码语音质量,构建了 10 条多语种音频对比集,在该对比集上与其他音频编解码器进行了对比。为了降低计算复杂的影响,团队设计了轻量化的CBRC-lite,其计算复杂度略高于Lyra-V2。由主观听感比较结果可知,CBRC在3kbps上语音质量超过了12kbps的Opus,同样超过了3.2kbps的Lyra-V2,这表明所提出方法的有效性。https:/ 中提供了 CBRC 编码后音频样音。Beam-search RVQ 算法简要过程:1、每层 VQ 输入前层 VQ 的 K 个候选量化路径,得到个候选量化路径。2、从 K2个候选量化路径中选择 K 个量化路径误差最小的 K 个量化路径作为当前 VQ 层输出。3、在最后一层 VQ 中选择量化路径误差最小的路径作为量化器的输出。全球前沿011客观分主观听感得分Codecbitrate Complexity(Macs)ViSQOL PESQOpus6kbps2.572.18Opus9kbps3.513.08Opus12kbps3.913.81Lyra-V23.2kbps 344M3.182.34Lyra-V26kbps 344M3.552.92Lyra-V29.2kbps 344M3.703.11CBRC 3kbps4.5G3.712.88CBRC6kbps4.5G4.043.57CBRC-lite3kbps.379.3M3.562.67CBRC-lite6kbps379.3M3.843.09CBRC-lite9kbps379.3M4.013.22消融实验团队设计了针对 Intra-BRNN、Group-wise RVQ 和 Beam-search RVQ 的消融实验。实验结果表明在 Encoder和 Decoder 使用 Intra-BRNN 均可明显提升语音质量。此外,团队统计了 RVQ 中码本使用频次并计算熵解码以对比不同网络结构下码本使用率。相比于全卷积结构,使用 Intra-BRNN 的 CBRC 将潜在编码比特率从 4.94kbps 提升到 5.13kbps。同样,在 CBRC 中使用 Group-wise RVQ 和 Beam-search RVQ 均能显著提升编码语音质量,且相比于神经网络本身的计算复杂度,GB-RVQ 带来的复杂度增加几乎可忽略。Encoder Intra-BRNNDecoder Intra-BRNNViSQOL1w/ow/o3.412w/o103.553ww/o3.884ww4.04Quantizer TypeViSQOLRVQ3.81Group-wise RVQ3.92Beam-search RVQ4.02GB-RVQ4.04THE GLOBAL FRONTIER012在免提通信系统中,声学回声是令人烦恼的背景干扰。当远端信号从扬声器播放出来,然后由近端麦克风记录时,就会出现回声。回声消除(AEC)旨在抑制麦克风拾取的不需要的回声。在现实世界中,有很多非常需要消除回声的应用,例如实时通信、智能教室、车载免提系统等等。最近,采用深度学习(DL)方法的数据驱动 AEC 模型已被证明更加稳健和强大。这些方法将 AEC 表述为一个监督学习问题,其中输入信号和近端目标信号之间的映射函数通过深度神经网络(DNN)进行学习。然而,真实的回声路径极其复杂,这对 DNN 的建模能力提出了更高的要求。为了减轻网络的建模负担,大多数现有的基于 DL 的 AEC 方法采用一个前置的线性回声消除(LAEC)模块来抑制大部分回声的线性分量。但是,LAEC 模块有两个缺点:1)不合适的 LAEC 可能会导致近端语音的一些失真,以及 2)LAEC 收敛过程使线性回声抑制性能不稳定。由于 LAEC 是自优化的,因此 LAEC 的缺点会给后续的神经网络带来额外的学习负担。为了避免 LAEC 的影响并保持更好的近端语音质量,本文探索了一种新的基于端到端 DL 的两阶段处理模式,并提出了一种由粗粒度(coarse-stage)和细粒度(fine-stage)组成的两阶段级联神经网络(TSPNN)用于回声消除任务。大量的实验结果表明,所提出的两阶段回声消除方法能够达到优于其他主流方法的性能。背景基于两阶段渐进式神经网络的回声消除方法论文地址:https:/www.isca-speech.org/archive/pdfs/interspeech_2023/chen23e_interspeech.pdf模型框架结构如下图所示,TSPNN 主要由三个部分组成:时延补偿模块(TDC)、粗粒度处理模块(coarse-stage)和细粒度处理模块(fine-stage)。TDC 负责对输入的远端参考信号(ref)和近端麦克风信号(mic)进行对齐,有利于后续模型收敛。coarse-stage 负责将大部分的回声(echo)和噪声(noise)从 mic 中去除,极大减轻后续 fine-stage 阶段模型学习负担。同时,coarse-stage 结合了语音活跃度检测(VAD)任务进行多任务学习,强化模型对近端语音的感知能力,减轻对近端语音的损伤。fine-stage 负责进一步消除残余回声和噪声,并结合邻居频点信息来较好地重构出近端目标信号。全球前沿013为了避免独立优化每个阶段的模型而导致的次优解,本文采用级联优化的形式来同时优化 coarse-stage 和 fine-stage,同时松弛对 coarse-stage 的约束,避免对近端语音造成损伤。此外,为了让模型能够具有感知近端语音的能力,本发明引入了 VAD 任务进行多任务学习,在损失函数中加入 VAD 的 Loss。最终损失函数为:其中 S,O(1),O(2)E CFxT 分别表示目标近端信号复数谱、coarse-stage 和 fine-stage 估计的近端信号复数谱;Puad E R2xT,PER1xT分别表示 coarse-stage 估计的近端语音活跃状态、近端语音活跃检测标签;为一个控制标量,主要用于调节训练阶段对不同阶段的关注程度。本发明限制 来松弛对 coarse-stage 的约束,有效避免 coarse-stage 对近端的损伤。实验结果 实验数据火山引擎流媒体音频团队所提两阶段回声消除系统还与其他方法做了比较,实验结果表明,所提能够达到优于其他主流方法的效果。具体例子1.实验结果 Github 链接:https:/ MOS of rank 1 is used from Challenge34.The AECMOS model estimates MOS with high accuracy36.single-talkdouble-talkFENEechodegavgUnprocessed1.864.072.144.143.053Speex-AEC23.424.082.783.813.523LAEC3.364.142.923.943.590coarse-stage4.794.274.554.014.405rank 1*4.594.254.694.184.428DAEC-64 NRES-64264.354.184.554.254.333Pvad-Rdr-AEC(ours)4.804.324.694.294.525THE GLOBAL FRONTIER014CHiME-7 无监督域自适应语音增强(UDASE)挑战赛冠军方案 论文地址:https:/www.chimechallenge.org/current/task2/documents/Zhang_NB.pdf近年来,随着神经网络和数据驱动的深度学习技术的发展,语音增强技术的研究逐渐转向基于深度学习的方法,越来越多基于深度神经网络的语音增强模型被提出。然而这些模型大多基于有监督学习,都需要大量的配对数据进行训练。然而在实际场景中,无法同时收录到嘈杂场景的语音和与之配对的不受干扰的干净语音标签,通常采用数据仿真的形式,单独采集干净语音与各种各样的噪声,将其按照一定信噪比混合得到带噪音频。这导致了训练场景与实际应用场景的不匹配,模型性能在实际应用中有所下降。为了更好的解决以上域不匹配问题,利用真实场景中大量无标签数据,无监督、自监督语音增强技术被提出。CHiME 挑战赛赛道 2 旨在利用未标记的数据来克服在人工生成的标记数据上训练的语音增强模型因训练数据与实际应用场景的不匹配导致的性能下降问题,研究的重点在于如何借助目标域的无标签数据和集外的有标签数据来提升目标域的增强结果。背景无监督域自适应语音增强系统流程图模型框架结构如上图所示,所提框架是一个教师学生网络。首先在域内数据上使用语音活动检测、UNA-GAN、仿真房间冲击响应、动态加噪等技术生成最接近目标域的有标签数据集,在该域外有标签数据集上预训练教师降噪网络 Uformer 。接着在域内无标签数据上借助该框架更新学生网络,即利用预训练的教师网络从带噪音频中估计干净语音和噪声作为伪标签,将他们打乱顺序重新混合作为学生网络输入的训练数据,利用伪标签有监督的训练学生网络。使用预训练的MetricGAN 判别器估计学生网络生成的干净语音质量评分,并与最高分计算损失,以指导学生网络生成更高质量的干净音频。每训练一定步长后以一定权重将学生网络的参数更新到教师网络中,以获取更高质量的监督学习伪标签,如此重复。全球前沿015Ufomer 网络Uformer 是在Uformer网络基础上加入 MetricGAN改进得到的。Uformer 是一个基于 Unet 结构的复数实数双路径conformer网络,它具有两条并行的分支,幅度谱分支和复数谱分支,网络结构如下图所示。幅度分支用于进行主要的噪声抑制功能,能够有效抑制大部分噪声。复数分支作为辅助,用于补偿语谱细节和相位偏差等损失。MetricGAN 的主要思想是使用神经网络模拟不可微的语音质量评价指标,使其可以被用于网络训练中,以减少训练和实际应用时评价指标不一致带来的误差。这里团队使用感知语音质量评价(PESQ)作为 MetricGAN 网络估计的目标。Uformer 网络结构图RemixIT-G 框架RemixIT-G 是一个教师学生网络,首先在域外有标签数据上预训练教师 Uformer 模型,使用该预训练教师模型解码域内带噪音频,估计噪声和语音。接下来在同一批次内打乱估计的噪声和语音的顺序,重新将噪声和语音按打乱后的顺序混合成为带噪音频,作为训练学生网络的输入。由教师网络估计的噪声和语音作为伪标签。学生网络解码重混合的带噪音频,估计噪声和语音,与伪标签计算损失,更新学生网络参数。学生网络估计的语音被送入预训练的MetricGAN 判别器中预测 PESQ,并与 PESQ 最大值计算损失,更新学生网络参数。所有训练数据完成一轮迭代后根据如下公式更新教师网络的参数:,其中 为训练第 K 轮教师网络的参数,为第 K 轮学生网络的参数。即将学生网络的参数以一定权重与教师网络相加。UNA-GAN 结构图数据扩充方法 UNA-GANTHE GLOBAL FRONTIER016无监督噪声自适应数据扩充网络 UNA-GAN 是一种基于生成对抗网络的带噪音频生成模型。其目的是在无法获取独立的噪声数据的情况下,只使用域内带噪音频,直接将干净语音转化为带有域内噪声的带噪音频。生成器输入干净语音,输出仿真的带噪音频。判别器输入生成的带噪音频或真实的域内带噪音频,判断输入的音频来自真实场景还是仿真生成。判别器主要根据背景噪声的分布来区分来源,在这个过程中,人类语音被视为无效信息。通过执行以上对抗训练的过程,生成器试图将域内噪声直接添加在输入的干净音频上,以迷惑判别器;判别器试图尽力区分带噪音频的来源。为了避免生成器添加过多噪声,覆盖掉输入音频中的人类语音,使用了对比学习。在生成的带噪音频、和输入的干净语音对应位置采样 256 个块。相同位置的块的配对被视为正样例,不同位置的块的配对被视为负样例。使用正负样例计算交叉熵损失。实验结果结果表明所提出的 Uformer 相比基线 Sudo rm-rf 具有更强的性能,数据扩充方法 UNA-GAN 也具有生成域内带噪音频的能力。域适应框架 RemixIT 基线在 SI-SDR 上取得了较大提升,但在 DNS-MOS 上指标较差。团队提出的改进 RemixIT-G 同时在两个指标上都取得了有效提升,并在竞赛盲测集上取得了最高的主观测听 MOS 打分。最终测听结果如下图所示。总结与展望上述介绍了火山引擎流媒体音频团队基于深度学习在特定说话人降噪,AI 编码器,回声消除和无监督自适应语音增强方向做出的一些方案及效果,未来场景依然面临着多个方向的挑战,如怎么样在各类终端上部署运行轻量低复杂度模型及多设备效果鲁棒性,这些挑战点也将会是流媒体音频团队后续重点的研究方向。全球前沿017Al 视频质量评价”赛道奖项团队名称一等奖杨力率领的“mqma1st”企业参赛队二等奖张家斌率领的“MK”企业参赛队杨杨 率领的“热爱 CV 的小七”企业参赛队三等奖薛子育 率领的“MediaAlLab”企业高校联合参赛队刘庆同率领的“ABS-CASIA”科研单位参赛队张世雄 率领的“NUVIC”企业高校联合参赛队火山引擎获全国人工智能大赛AI 视频质量评价冠军 近日,第 4 届全国人工智能大赛 NAIC(National Artificial Intelligence Challenge)圆满落幕。经过激烈角逐,火山引擎多媒体实验室提出的 Patch-based Multi-level Swin Transformer for High Resolution Video Quality Assessment算法荣获 AI 视频质量评价赛道冠军,算法性能在复赛、决赛阶段均稳居第一,技术能力达到行业领先水平。摘要THE GLOBAL FRONTIER018自 2019 年首届举办以来,全国人工智能大赛已经发展成为一个具有国际视野、规模庞大且影响力广泛的赛事。该大赛累积汇集了来自 20 个国家的 1 万多支队伍,涵盖了头部企业、知名院校和科研机构,并且在参赛规模和国际影响力方面不断提升,成为同类比赛中的佼佼者。本届大赛设置了“AI 视频质量评价”、“AI 视觉特征编码”和“AI 无线通信”三个赛道,分别面向人工智能、通信、智能视觉、工业互联网和大数据应用等领域的技术人才和创新团队,发布了一系列具有挑战性的赛题。在本届全国人工智能大赛中,“AI 视频质量评价”赛道是全球首个专注于广色域、高帧率、高比特数的 4K 超高清视频压缩质量评价的人工智能赛道。该赛道要求参赛选手采用更高级别的视频序列和更专业的主观标签数据集,旨在挖掘准确性高、鲁棒性强的人工智能评价算法,以提供出色的视频传输和分发质量,为视听媒体用户提供卓越的观看体验。随着传媒领域技术的不断发展和革新,超高清视频逐渐成为行业发展新趋势,围绕超高清视频的相关技术也引起了学术界和工业界越来越多的关注。得益于真实细腻的视频画面,超高清视频能够为用户提供更精彩的沉浸式体验。超高清视频往往辅以更广的色域范围、更深的量化比特数进行呈现,所需传输的数据量极大。受限于带宽资源因素,超高清视频往往需要经过大幅度压缩编码处理才能够有效传输。目前,主流的视频编码技术在大幅度数据压缩时会不可避免地引入失真,包括模糊、块效应、伪轮廓等。因此,如何有效感知经压缩编码后的超高清视频质量至关重要。视频质量评价技术旨在感知和量化视频的画质优劣,包括分辨率、清晰度、失真度等多种因素。在超高清视频中,视频质量评价能够为压缩编码等操作提供可靠的画质评判依据,保证超高清视频的高质量呈现,从而为用户体验保障、用户黏度提升等方面提供巨大助力。受困于失真特性差异,面向低分辨率的视频质量评价算法在本次赛题的超高清 PGC 视频场景下表现不佳。基于多媒体实验室内部的画质评估算法,团队对大赛提供的超高清视频进行了充分的失真分析,包括空域失真特点分析和时域质量波动分析。在此次竞赛中,多媒体实验室针对性地提出一种 Patch-based Multi-level Swin Transformer for High Resolution Video Quality Assessment 的超高清视频质量评价算法。空域失真特点方面,超高清 PGC 视频与基于局部块的质量评价算法相关性最高,团队采用了图像块输入策略以更好地感知局部质量变化。时域质量波动方面,超高清 PGC 视频的帧间质量波动较小,团队采用了帧级强监督训练策略以充分扩充训练数据。进一步,团队提出了多层级特征融合策略以进一步提升算法的质量感知能力。团队提出的算法表现优越,性能持续领跑,且能以极低的计算代价完成对超高清 PGC 视频的质量评价。最终,团队方案从该赛道 1624 支队伍中脱颖而出,荣获冠军。全球前沿019CVPR 2024 满分论文基于可变形 3D 高斯的高质量单目动态重建新方法DEFORMABLE 3D GAUSSIAN:单目动态场景(Monocular Dynamic Scene)是指使用单眼摄像头观察并分析的动态环境,其中场景中的物体可以自由移动。单目动态场景重建对于理解环境中的动态变化、预测物体运动轨迹以及动态数字资产生成等任务至关重要。随着以神经辐射场(Neural Radiance Field,NeRF)为代表的神经渲染的兴起,越来越多的工作开始使用隐式表示(implicit representation)进行动态场景的三维重建。尽管基于 NeRF 的一些代表工作,如 D-NeRF,Nerfies,K-planes 等已经取得了令人满意的渲染质量,他们仍然距离真正的照片级真实渲染(photo-realistic rendering)存在一定的距离。我们认为,其根本原因在于基于光线投射(ray casting)的NeRF管线通过逆向映射(backward-flow)将观测空间(observation space)映射到规范空间(canonical space)无法实现准确且干净的映射。逆向映射并不利于可学习结构的收敛,使得目前的方法在 D-NeRF 数据集上只能取得 30 级别的 PSNR 渲染指标。为了解决这一问题,我们提出了一种基于光栅化(rasterization)的单目动态场景建模管线,首次将变形场(Deformation Field)与 3D 高斯(3D Gaussian Splatting)结合实现了高质量的重建与新视角渲染。实验结果表明,变形场可以准确地将规范空间下的 3D 高斯前向映射(forward-flow)到观测空间,不仅在 D-NeRF 数据集上实现了 10 的 PSNR 提高,而且在相机位姿不准确的真实场景也取得了渲染细节上的增加。该研究的论文Deformable 3D Gaussians for High-Fidelity Monocular Dynamic Scene Reconstruction已被计算机视觉顶级国际学术会议 CVPR 2024 接收。值得一提的是,该论文是首个使用变形场将 3D 高斯拓展到单目动态场景的工作,并且在公开数据集上取得了 SOTA 结果。摘要THE GLOBAL FRONTIER020图 1 HyperNeRF 真实场景的实验结果Ziyi Yang1,2 Xinyu Gao1 Wen Zhou2 Shaohui Jiao2 Yuging Zhang1 Xiaogang Jin1 1State Key Laboratory ofCAD&CG,Zhejiang University 2ByteDance Inc.DEFORMABLE 3D GAUSSIANS FOR HIGH-FIDELITY MONOCULAR DYNAMIC SCENE RECONSTRUCTION动态场景重建一直以来是三维重建的热点问题。随着以 NeRF 为代表的神经渲染实现了高质量的渲染,动态重建领域涌现出了一系列以隐式表示作为基础的工作。D-NeRF 和 Nerfies 在 NeRF 光线投射管线的基础上引入了变形场,实现了鲁棒的动态场景重建。TiNeuVox,K-Planes 和 Hexplanes 在此基础上引入了网格结构,大大加速了模型的训练过程,渲染速度有一定的提高。然而这些方法都基于逆向映射,无法真正实现高质量的规范空间和变形场的解耦。3D 高斯泼溅是一种基于光栅化的点云渲染管线。其 CUDA 定制的可微高斯光栅化管线和创新的致密化使得 3D 高斯不仅实现了SOTA的渲染质量,还实现了实时渲染。Dynamic 3D高斯首先将静态的3D高斯拓展到了动态领域。然而,其只能处理多目场景非常严重地制约了其应用于更通用的情况,如手机拍摄等单目场景。Deformable-GS 的核心在于将静态的 3D 高斯拓展到单目动态场景。每一个 3D 高斯携带位置,旋转,缩放,不透明度和 SH 系数用于图像层级的渲染。根据 3D 高斯 alpha-blend 的公式我们不难发现,随时间变化的位置,以及控制高斯形状的旋转和缩放是决定动态 3D 高斯的决定性参数。然而,不同于传统的基于点云的渲染方法,3D 高斯在初始化之后,位置,透明度等参数会随着优化不断更新。这给动态高斯的学习增加了难度。在本次研究中,我们创新性地提出了变形场与 3D 高斯联合优化的动态场景渲染框架。我们将 COLMAP 或随机点云初始化的 3D 高斯视作规范空间,随后通过变形场,以规范空间中 3D 高斯的坐标信息作为输入,预测每一个 3D 高斯随时间变化的位置 和形状参数。利用变形场,我们可以将规范空间的 3D 高斯变换到观测空间用于光栅化渲染。这一策略并不会影响 3D 高斯的可微光栅化管线,经过其计算得到的梯度可以用于更新规范空间 3D 高斯的参数。此外,引入变形场有利于动作幅度较大部分的高斯致密化。这是因为动作幅度较大的区域变形场的梯度也会相对较高,从而相关工作研究思想全球前沿021该研究首先在动态重建领域被广泛使用的 D-NeRF 数据集上进行了合成数据集的实验。从图 3 的可视化结果中不难看出,Deformable-GS 相比于之前的方法有着非常巨大的渲染质量提升。我们方法不仅在视觉效果上取得了大幅度的提高,定量的渲染指标上也有着对应的支持。值得注意的是,我们发现D-NeRF 数据集的 Lego 场景存在错误,即训练集和测试集的场景具有微小的差别。这体现在 Lego 模型铲子的翻转角度不一致。这也是为什么之前方法在 Lego 场景的指标无法提高的根本原因。为了实现有意义的比较,我们使用了Lego 的验证集作为我们指标测量的基准。结果展示图 3 该研究在 D-NeRF 数据集上的定性实验对比结果图 2 展示了该研究的流程图,详情请参见论文原文图 2 流程图指导相应区域在致密化的过程中得到更精细的调控。即使规范空间 3D 高斯的数量和位置参数在初期也在不断更新,但实验结果表明,这种联合优化的策略可以最终得到鲁棒的收敛结果。大约经过 20000 轮迭代,规范空间的 3D 高斯的位置参数几乎不再变化。在真实场景中,我们发现真实场景的相机位姿往往不够准确,而动态场景更加剧了这一问题。这对于基于神经辐射场的结构来说并不会产生较大的影响,因为神经辐射场基于多层感知机(MLP),是一个非常平滑的结构。但是 3D 高斯是基于点云的显式结构,略微不准确的相机位姿很难通过高斯泼溅得到较为鲁棒地矫正。因此为了缓解这个问题,我们创新地引入了退火平滑训练(Annealing Smooth Training,AST)。该训练机制旨在初期平滑 3D 高斯的学习,在后期增加渲染的细节。这一机制的引入不仅提高了渲染的质量,而且大幅度提高了时间插值任务的稳定性与平滑性。THE GLOBAL FRONTIER022我们在全分辨率(800 x800)下对比了 SOTA 方法,其中包括了 CVPR 2020 的 D-NeRF,Sig Asia 2022 的TiNeuVox 和 CVPR2023 的 Tensor4D,K-planes。我们的方法在各个渲染指标(PSNR、SSIM、LPIPS),各个场景下都取得了大幅度的提高。我们的方法不仅能够适用于合成场景,在相机位姿不够准确的真实场景也取得了 SOTA 结果。如图 5 所示,我们在NeRF-DS 数据集上与 SOTA 方法进行了对比。实验结果表明,即使我们的方法没有对高光反射表面进行特殊处理,我们依旧能够超过专为高光反射场景设计的 NeRF-DS,取得了最佳的渲染效果。图 4 方法对比虽然 MLP 的引入增加了渲染开销,但是得益于 3D 高斯极其高效的 CUDA 实现与我们紧凑的 MLP 结构,我们依旧能够做到实时渲染。在 3090 上 D-NeRF 数据集的平均 FPS 可以达到 85(400 x400),68(800 x800)。此外,该研究还首次应用了带有前向与反向深度传播的可微高斯光栅化管线。如图 6 所示,该深度也证明了Deformable-GS 也可以得到鲁棒的几何表示。深度的反向传播可以推动日后很多需要使用深度监督的任务,例如逆向渲染(Inverse Rendering),SLAM 与自动驾驶等。图 5 真实场景方法对比图 6 深度可视化全球前沿023模块化无参视频质量评估CVPR 2024MODULAR BLIND VIDEOQUALITY ASSESSMENT无参视频质量评估(Blind Video Quality Assessment,BVQA)在评估和改善各种视频平台并服务用户的观看体验方面发挥着关键作用。当前基于深度学习的模型主要以下采样/局部块采样的形式分析视频内容,而忽视了实际空域分辨率和时域帧率对视频质量的影响,随着高分辨率和高帧率视频投稿逐渐普及,特别是跨分辨率/帧率视频转码档位画质评估场景中,这种影响变得更加不可忽视。在本文中,我们提出了一种模块化 BVQA 模型,以及一种训练该模型以提高其模块化性的方法。我们的模型包括基础质量预测模块、空域矫正模块和时域矫正模块,分别显式地响应视频质量的视觉内容和失真、空域分辨率和时域帧率变化情况。我们用提出的模块化 BVQA 模型在专业生成的内容和用户生成的内容视频数据库上进行了大量实验。实验表明,我们的质量模型实现了优于当前方法或相近的性能。此外,模块化的模型为分析现有视频质量数据库的空间和时间复杂性提供了机会。最后,我们的 BVQA 模型可以轻量高效地添加其他与质量相关的视频属性,例如动态范围和色域作为额外的矫正模块。Wen Wenl,3 Mu Li2,*Yabin Zhang3 Junlin Li3 LiZhang3 Kede Ma1 1City University of Hong Kong 2Harbin Institute of Technology,Shenzhen 3ByteDance Inc.wwen29-cmy.cityu.edu.hk,zhangtao.ceb,liaoyiting,lijunlin.li,kede.macityu.edu.hkModular Blind Video Quality Assessment摘要THE GLOBAL FRONTIER024多年来,研究人员从心理物理学和感知研究中收集了大量证据,证明更高的空域分辨率和更高的帧速率对视频主观画质有积极的影响。具体而言,感知质量取决于视频内容,特别是空域和时域复杂性。针对这些主观发现,早期的知识驱动的 BVQA 模型直接将空域分辨率和帧速率参数作为压缩视频质量预测的输入的一部分。尽管这种方法非常简单,但这些视频属性参数与内容和失真无关,因此它们与感知的视频质量不太相关。基于卷积神经网络(CNN)的数据驱动的 BVQA 方法面临的计算问题十分明显。它们几乎没有尝试评估全尺寸视频,主要原因是计算复杂度很高,尤其是在处理高分辨率和帧速率的视频时,面临的挑战更大。此外,由于视频质量数据集规模较小,许多基于 CNN 的 BVQA 方法依赖于对象识别任务的预训练模型,这些模型通常需要小且固定大小的输入。因此,视频需要在空域上调整大小,并在时域上进行二次采样。在空域中处理视频的传统方法如图 1 所示,在时域中处理视频的传统方法如图 2 所示。图 1.在空域视图中处理视频的传统方法。(a)代表来自 Waterloo IVC 4K 的具有相同内容但不同空域分辨率的两个视频。(b)在不保持宽高比的情况下调整视频大小,与视频质量相关的局部纹理可能会受到影响。(c)调整视频大小,同时保留纵横比并将其裁剪为固定大小,无论实际空域分辨率如何,都会产生几乎相同的输入。(d)裁剪视频会缩小视野并导致不同空域分辨率的内容覆盖范围不同。图.2 来自 LIVE-YT-HFR 的两个视频序列,具有相同的内容,但是时域帧率不同。当根据帧速对帧进行二次采样时,生成的帧是相同的。此外,高达 120 fps 的极高帧速率对端到端 VQA 模型提出了重大挑战。背景全球前沿025为了可靠地评估具有丰富内容和失真多样性以及多种空域分辨率和帧速率的数字视频质量,我们提出了一种模块化 BVQA 模型。我们的模型由三个模块组成:基础质量预测模块、空域矫正模块和时域矫正模块,分别响应视频质量中的视觉内容和失真、空域分辨率和帧速率变化。基础质量预测模块将一组稀疏的空域下采样关键帧作为输入,并生成一个标量作为质量分数。空域矫正模块依靠浅层 CNN 来处理实际空域分辨率下关键帧的拉普拉斯金字塔,并计算缩放和移位参数来校正基础质量得分。类似地,时域矫正模块依靠轻量级 CNN 以实际帧速率处理以关键帧为中心的空域下采样视频块,并计算另一个缩放和移位参数以进行质量得分校正。为了增强模型的模块化,我们在训练期间引入了 dropout 策略。在每次迭代中,我们以预先指定的概率随机丢弃空域和/或时域整流器。这种训练策略鼓励基础质量预测模块作为 BVQA 模型独立运行,并且在配备矫正模块时会表现更好。为了评估空域整流器的性能,我们采用了 BVI-SR和 Waterloo IVC 4K,重点研究不同空域分辨率对视频质量的影响。为了评估时域整流器的有效性,我们利用 BVI-HFR 和 LIVE-YT-HFR,它们专门用于分析不同帧速率对视频质量的影响。这四个数据集都是 PGC(Professionally-Generated Content,专业生成的内容)数据集。我们还使用八个 UGC(User-Generated Content,用户生成的内容)数据库进一步验证了我们提出的模型的普遍性。这些数据库包含各种内容类型、视觉扭曲、空域分辨率和时域帧率。表 1 中提供了这些数据库的全面介绍。图3.所提出模型总体结构。基础质量预测模块采用一组稀疏的空域下采样关键帧作为输入,生成表示为 的基础质量值。空域矫正模块采用从实际空域分辨率的关键帧导出的拉普拉斯金字塔,计算缩放参数 和移位参数 来校正基础质量。时域校正模块利用以实际帧速率的关键帧为中心的视频块的特征来计算另一个缩放参数 和移位参数 以进行质量校正。空域和时域矫正模块可以使用模块化方法协同组合,其中利用尺度参数的几何平均值和移位参数的算术平均值。方法实验结果THE GLOBAL FRONTIER026表 2 和表 3 展示了 4 个 PGC 数据集的结果。可以看出空域矫正模块和时域矫正模块可以分别有效地感知空域分辨率和时域帧率对视频质量带来的影响,并很好地对基础质量分数进行矫正。Table 1.Summary of the benchmark PGC and UGC VQA datasets.Duration in seconds.Table 2.Performance comparison of our models against compet.ing methods on BVI-SR and Waterloo IVC 4K with emphasis onspatial resolution-sensitive distortions,The top-2 results on eachdatabase are highlighted in bold.PGC 数据集结果Dataset#Videos#Scenes DurationSpatial ResolutionFrame RateDistortion TypeBVI-SR 192402454K60Down-scalingWaterloo IVC 4K 161200209-10540p,1080p,4K24,25,30CompressionBVI-HFR 208822101080p15,30,60,120Frame averagingLIVE-YT-HFR 21480166-101080p24,30,60,82,98,120CompressionCVD2014 26234510-25480p,720p10-32AuthenticLIVE-Qualcomm 620854151080p30AuthenticKoNViD-1k 81,20012008540p24,25,30AuthenticLIVE-VOC 3258558510240p-1080p30AuthenticYouTube-UGC 371142114220360p-4K30AuthenticLBVD 11.013101310240p-540p 30Authentic,TransmissionLIVE-YT-Gaming 436006008-9360p-1080p30,60Authentic,RenderingLSVQ 4238,811388115-1299p-4K30)的场景重建、复现及后编辑。在具体实践的场景中,动态物体会使 NeRF 重建出现伪影,借助自研动静态分割、影子检测、inpainting 等算法,对场景中和几何不一致的区域进行提取、修复。同时借助自研高精度 SFM 算法框架,对场景进行高精度的几何重建,包括相机参数估计以及稀疏、稠密点云生成。另外,对场景进行拆分以减小单次训练资源消耗,并可做分布式训练、维护。在神经辐射场训练过程中,针对室外无边界大场景,团队通过优化策略以提升该场景下的新视角生成效果,比如,通过在训练中同时优化位姿提高重建精度、基于哈希编码的层次化表达提升模型训练速度、借助外观编码提升不同时间采集场景的外观一致性、借助 mvs 稠密深度信息提升几何精度等。以团队同毫末智行合作为例,完成单路采集以及多路合并的 NeRF 重建,相关成果已在毫末 AI Day 发布。为提升用户沉浸式体验,火山引擎多媒体实验室自研虚实融合技术,将环境实拍全景图与场景模型进行对齐、融合。团队利用先进的人工智能技术,建立全景图图像特征与模型关键点的匹配关系,通过 PnP 算法以及光束法平差算法将全景图注册至场景模型坐标系,实现尺度、位置的统一,从而实现模型渲染与实拍全景视频渲染的统一,达到虚实融合的效果。同时,为扩大用户体验的自由度,团队针对该场景自研非球面天空盒渲染,克服传统的球面全景图渲染仅在图像采集中心视觉一致的缺陷,进一步提升实拍全景图渲染模型与地形模型的匹配程度,以实现更大运动范围的视觉一致性,进一步提升沉浸式体验。虚实融合,提升用户体验在跟着德爷闯东非互动纪录片中,会有用户虚拟体验探险剧情的桥段,例如钻木取火,木棍训蛇等。为了带来真实的体验,道具往往是在实际拍摄过程中就地取材,有细长的树枝,薄薄的小刀,还有形态复杂的篝火堆。这些道具的重建本身是比较有挑战的,再加上整个拍摄过程比较紧张,留给扫描的时间并不充裕。为此,火山引擎视频云团队沉淀出一套采集方便,操作简单,能还原各类复杂物品的重建系统。物品重建,高精度还原细节技术探索039图:道具重建效果展示采用虚实融合技术可以构造由空间重建模型和实拍 360 VR 视频两部分构成的 6DoF 互动场景,同时在跟着德爷闯东非 项目中,多媒体实验室也实现了终端上的交互技术,同内容团队一起创造出了很多有创意性的虚实结合的玩法。交互技术,让玩法更丰富使用离屏相机管道,把从全景视频球上投影出的针孔 2D 图像重新贴在玩家手持的相机模型上,以实现出玩家可以对环境中任意角度拍照的玩法。拍照功能火山引擎多媒体实验室可以估计 VR 视频中的深度信息,结合 3D 虚拟空间中的虚拟物体的位置信息,计算出全景视频球上指定视频元素,对应于玩家在真实的 3D 空间下的位置。从而,实现视频画面上真实物品转换到玩家可交互虚拟物品模型的无缝转换的玩法。物品交互功能虚实融合技术目前正处于快速发展的阶段,在众多领域中展现出广阔的应用前景。如游戏、教育和医疗等领域,已开始积极探索虚实融合技术的应用,并取得了不错的成绩:虚实融合技术的广阔应用为了重建形状比较复杂的道具(例如狭长的木棍、锋利的小刀)。火山引擎视频云采用符号距离场(Signed Distance Fields,简称 SDF)的技术方案来表示三维物体,结合深度学习的方法克服了以上重建难点。对于如何监督神经网络使其准确地拟合该 SDF,火山引擎视频云先用运动恢复结构(Structure from Motion,简称 SfM)算法,精确计算拍摄图像的相机姿态,再利用可微渲染的方法将 SDF 所表示的空间信息渲染到图像上,把渲染得到的图像和该视角下采集的图像做比较,不断优化神经网络,使 SDF 在各个采集视角下的渲染结果尽可能与实际采集的图像一致。为了进一步提高重建精细度,在优化 SDF 的时候加入稀疏重建得到的三维点做约束,能更好的还原物体的细节特征。TECHNOLOGY EXPLORATION040在游戏领域,虚实融合技术赋予了游戏开发者更多创造力和想象力的空间。通过将虚拟元素与真实世界相结合,游戏能够提供更加沉浸式和交互式的体验。玩家可以与虚拟角色和游戏环境进行实时互动,增强了游戏的娱乐性和参与感。在教育领域,也可以看到虚实融合技术的巨大潜力。通过将虚拟内容融入到教学场景中,学生可以以更加生动和直观的方式进行学习,提高学习效果和兴趣。虚实融合技术可以为学生提供与实物互动的机会,使他们能够亲身体验和理解抽象概念,促进知识的深入理解和记忆。在医疗领域,虚实融合可以用于模拟手术训练、辅助手术导航和可视化诊断等方面。通过结合虚拟现实和真实世界数据,医生可以更准确地进行手术规划和操作,提高手术的安全性和成功率。此外,虚实融合还可以用于康复训练和疼痛管理等方面,为患者提供更加个性化和有效的治疗手段。技术探索041中国历史悠久,文化底蕴深厚,文物数目众多,文物作为前人智慧的结晶,其文献价值不言而喻。古籍是记录中华文明的重要载体,也是流传至今的宝贵文化遗产,文物保护也是一项长期重要的基础工作。全国 2800 多家图书馆收藏有超过 5000 万册的古籍,其中 1/3 存在不同程度的破损。按现有的文物修复人员数量,需要数百年的时间才能把馆藏文物全部修复好。古籍寻游记是字节跳动联合中国第一历史档案馆、敦煌研究院、甘肃简牍博物馆、国家图书馆(国家典籍博物馆),共同打造的古籍活化项目,还原古文献四大发现 殷墟甲骨、居延汉简、敦煌遗书、明清档案,让古籍以数字化的形式“活”起来。该项目以 VR 互动纪录片为核心,依托火山引擎多媒体实验室最新的三维重建技术,复刻线下文物到 PICO 虚拟场景中,并应用自研光场视频技术,采集并惟妙惟肖的还原动态人物的光场信息,在 VR 场景中提供高自由度的观看和交互体验。在这些纪录片中,观众可以通过 PICO、抖音裸眼 VR 等方式,足不出户穿越时空,亲自参与历史事件,零距离接触与欣赏古籍。本文重点介绍火山引擎多媒体实验室的三维重建技术以及光场视频技术的原理、先进性及应用领域,帮助大家能更好的了解和认识三维重建技术,助力相关技术在实际产品和应用中落地。让文物“活”起来揭秘火山引擎视频云三维重建技术摘要TECHNOLOGY EXPLORATION042文物的数字化需要对文物做三维重建和数字复原,同时也对三维重建技术提出了很大挑战:1.文物采集需要使用对于文物无侵害的设备,传统的高精度激光等设备就无法使用。文物通常保护在陈列柜内,难以拿出,也对重建的采集提出了更高的要求;2.文物往往形状复杂,且具有一定的材质,尤其是古籍类文物,往往很薄,如何重建这种很薄的文物,是物品重建的一个难点。如何高真实感复现文物并表现其真实感纹理,包括漫反射、镜面反射、半透明,等复杂材质的恢复与微细表面的重建,也对技术提出了挑战;3.对于石窟等文物,需要采集并重建一定的空间,如何采用纯视觉的方式,在石窟内进行漫游采集,并进行完整重建,是项目的一个难点;4.为了更好地实现博物馆的文化推广,实现历史情景的在线还原,需要对动态人物和场景进行高真实度重建,然而,当前动态人物和场景的高真实度重建缺乏完整的有效解决方案。技术挑战与难点三维重建是计算机辅助几何设计(CAGD)、计算机图形学(CG)、计算机动画、计算机视觉、医学图像处理、科学计算和虚拟现实、数字媒体创作等领域的共性科学问题和核心技术。三维重建技术,一般包括数据采集、预处理、点云拼接、特征分析、网格及纹理生成等步骤。传统的三维重建采用基于视觉或者基于多模态(深度数据,e.g.,激光)重建图像三维信息的过程,能够对静态物体和场景进行建模,但缺乏有效的对于动态物体和场景建模的整体解决方案。火山引擎多媒体实验室具备自研的物品重建技术、场景重建技术,及光场视频技术,能够对静态物体构建高保真的形态,并恢复其复杂材质;能够对大场景,包括城市,园区,房屋空间等进行有效的建模,是数字孪生的重要基础;且能够对动态物体和动态场景,采用先进光场视频技术进行重建和复现,实现点播和直播,具备整套的技术解决方案。三维重建技术介绍三维重建是计算机辅助几何设计(CAGD)、计算机图形学(CG)、计算机动画、计算机视觉、医学图像处理、科学计算和虚拟现实、数字媒体创作等领域的共性科学问题和核心技术。三维重建技术,一般包括数据采集、预处理、点云拼接、特征分析、网格及纹理生成等步骤。传统的三维重建采用基于视觉或者基于多模态(深度数据,e.g.,激光)重建图像三维信息的过程,能够对静态物体和场景进行建模,但缺乏有效的对于动态物体和场景建模的整体解决方案。火山引擎多媒体实验室具备自研的物品重建技术、场景重建技术,及光场视频技术,能够对静态物体构建高保真的形态,并恢复其复杂材质;能够对大场景,包括城市,园区,房屋空间等进行有效的建模,是数字孪生的重要基础;且能够对动态物体和动态场景,采用先进光场视频技术进行重建和复现,实现点播和直播,具备整套的技术解决方案。1.物品重建技术:既要保护文物又要精确扫描图:SDF 示意图技术探索043如何监督神经网络使其准确地拟合该 SDF 是需要研究的问题。先用运动恢复结构(Structure from Motion,简称 SfM)算法,精确计算拍摄图像的相机姿态。有了相机姿态,利用可微渲染的方法将 SDF 所表示的空间信息渲染到图像上,把渲染得到的图像和该视角下采集的图像做比较,不断优化神经网络,使 SDF 在各个采集视角下的渲染结果尽可能与实际采集的图像一致。为了进一步提高重建精细度,在优化 SDF 的时候加入稀疏重建得到的三维点做约束,能更好的还原物体的细节特征。为了达到完整重建的目的,火山引擎多媒体实验室还将分割算法和重建算法相结合,能够有效的重建出物体的底部区域。由于物体在扫描过程中是要固定在某个位置,物体的底面采集不到图片的。物体的完整重建就是要解决物体底部重建的问题,通常的做法是悬线法或多段重建加后处理拼接。悬线法对文物来说不够安全,拼接后处理流程较长,不能自动化。为此,火山引擎多媒体实验室在重建算法中加入了自动化图像分割,能够将正反两次拍摄的数据统一起来一起重建,直接得到完整的重建结果,完整重建的结果对比如下图所示。高光是物体重建的一大挑战,一方面高光影响特征点匹配,导致恢复的相机位姿不准确,再一个高光也会破坏不同视角间观测结果的一致性,对重建造成干扰。为此,火山引擎多媒体实验室总结出一套利用偏振光消除高光的方法,能有效去除大量高光,高光消除的结果对比如下图所示。图:未使用完整重建技术建模结果图:消除高光前图:使用完整重建技术建模结果图:消除高光后火山引擎多媒体实验室的方法还可以模拟不同物体的反射/折射性质,实现对特殊材质物体的建模,文物重建的结果展示如下图所示。TECHNOLOGY EXPLORATION044图:文物原图图:文物重建甲骨文重建结果四大博物馆的文物,有一些是纸质、竹简类的珍贵文物,这些文物也难以从陈列柜中取出并采集。针对这种情况,火山引擎多媒体实验室自研了加入光学偏振片的采集设备,可以消除玻璃陈列柜带来的杂光、高光和反射问题,使得我们在有一层玻璃保护壳的状态下,仍对文物进行高保真的扫描和重建。此外,火山引擎多媒体实验室的物品重建技术还包含精确位姿估计、真实感纹理(漫反射、镜面反射、半透明)等复杂材质的恢复与微细表面的重建,也均在“古籍寻游记”项目中得以运用,将宝贵的文物实现高真实度的 1:1 还原,并转换为数字化资源,让观众“沉浸式”逛馆,让藏品更加深入人心。火山引擎多媒体实验室的物体重建技术具备很强的普适性,不仅适用于文物,一般物体也同样适用,而且对一些传统重建难以处理的物体,比如,刀刃等非常薄的物体等,也能有不错的重建结果。图:玻璃陈列柜中文物图:文物重建结果更多重建结果(上:小刀及木棍等道具;下:电商物品)技术探索0452.自建场景重建算法:更高效率、更高精度场景重建是计算机视觉和摄影测量中的重要研究课题,也在智慧城市、虚拟现实、数字导航与数字遗产保护等方面有着重要的应用。通过视觉进行三维重建具有采集效率高、采集成本低、精度上限高、适应场景广等优点,同时可以避免其他扫描设备对场景带来不必要的损害,但在算法层面面临诸多挑战。对此,火山引擎多媒体实验室结合 AI 技术与多视角几何基本原理,搭建了一套先进的鲁棒、精确完整视觉重建算法框架。重建过程包括三个关键步骤:图像处理、点云优化和网格重建。火山引擎多媒体实验室利用先进的人工智能技术,对图像进行去噪、超分、特征提取与匹配等处理,从而克服了诸多传统方法限制。然后利用 SfM 算法以及捆集约束(Bundle Adjustment,简称 BA)从图像中提取稀疏几何结构和相机参数。同时团队开发了支持全景相机、多相机组、RGBD 相机、激光雷达、GPS/IMU 等多传感器数据输入的位姿估计算法,实现高精度、多模态、自适应的稀疏重建。为了处理大规模数据,团队开发分块重建和地图合并策略,实现分布式集群并行重建,显著提高了重建效率。在完成场景稀疏重建后,通过立体视觉(Multiple View Stereo,简称 MVS)技术将二维图像信息转化为三维点云信息。团队自研基于单目相机、双目相机和多目立体视觉的深度估计算法,通过神经网络进行稠密深度估计,在任意视差、各种纹理环境获得稳定优秀的表现。获得点云信息后,进行点云去噪和补全,并通过点云配准实现场景几何一致性。最后,通过基于 VoxelHash 和图像语义信息的点云融合策略,进一步滤除噪声,生成更加平滑一致的完整场景点云。获得场景点云后,进行 Mesh 重建。火山引擎多媒体实验室自研多种网格优化算法,实现网格平滑、去噪、简化和补洞,获得更加精细、完整的高质量网格模型。得益于图像处理期间高精度的相机位姿估计以及图像超分等画质优化,结合自研贴图算法,获得更高清、拼缝更少的高质量纹理贴图。同时通过纹理重打包算法优化,实现更高的纹理利用率,降低存储资源浪费,提升纹理有效分辨率。TECHNOLOGY EXPLORATION046传统图像配准算法(上)火山引擎视频云算法(下)传统建模算法(上)火山引擎视频云算法建模结果(下)火山引擎多媒体实验室的物品重建技术和场景重建技术可以等比例、高精度的复原不同大小、不同形状的文物。上述的技术可以将线下文物转换到线上,在 PICO、抖音里实现文物的虚拟呈现,用户可以把甲骨文把玩在手里,清晰的看到上面的文字,实现传统参观没有的文物观赏体验,同时也可以跨越空间限制,置身并漫游在敦煌石窟里。另外,该项技术可以将线下珍贵文物转换为线上的永久数字资源,实现文物的数字化保护,可以让后世的人们身临其境体验到文物的全貌。3.自研光场视频技术:平衡成本与精确度之间的难题为了能够在虚拟敦煌石窟内,身临其境地观看一场盛世舞蹈,感受超越现实的体验,火山引擎多媒体实验室自研的光场视频技术,能够对动态人物和场景进行高真实度重建,达到行业先进水平。动态三维网格数据(Dynamic Mesh),可以表示动态人物和场景,但是如何重建出高质量的动态三维网格,并使得新渲染出的图像能够如照片般逼真是一个难题。若通过三维场景设计师对场景进行手工重建,将获得较好的重建质量,但将付出较大的人力成本;若通过 SFM/MVS 等算法自动重建三维场景,则需要重建场景纹理有一定要求,且重建结果可能包含不精确的几何细节和纹理失真。神经辐射场技术,采用神经网络对隐式重建,利用可微渲染模型,从已有视图中学习如何渲染新视角下的图像,从而实现照片级逼真的图像渲染,即神经辐射场(NeRF)技术。可微渲染模型建模了从三维空间模型及纹理到图像的渲染过程,其可微特性使得在已有视角图像的监督下,通过神经网络对三维空间几何及纹理进行学习。在未知新视角下,可以对学习到的三维空间几何进行重新渲染,从而获得新视角下的图像。城市场景建模(上)火山引擎视频云算法(下)技术探索047图:可微渲染模型火山引擎多媒体实验室融合神经辐射场技术与传统的网格建模技术。在具体实践中,首先重建出人物的大致几何轮廓,并改进 NeRF 技术,融入几何轮廓作为先验加入训练指导,隐式学习三维空间几何,并重新渲染出稠密新视角下的图像。在神经辐射场训练过程中,针对动态人物场景,团队通过一些优化策略以提升该场景下的新视角生成效果,如借助基于哈希编码的层次化表达提升模型训练速度,借助流式训练提升动态场景的帧间一致性等。最后采用视频融合技术,能够自动学习背景信息,实现前景的重光照,使得前景演员与背景场景能够无缝融合。同时,火山引擎多媒体实验室的光场视频技术,可以实现 NeRF 的编辑,重建并复现复杂的动态大场景。火山引擎多媒体实验室的光场视频技术,仅仅需要稀疏的多相机输入,就能够生成稠密的光场数据,这主要是采用基于深度学习的新视角生成技术。光场视频数据相对传统视频数据,具有数据量大的特点,团队采用多视角聚合编码技术压缩光场数据,降低传输和存储的压力。结合大规模直播技术以及 RTC 传输技术,能够实现光场视频的点播和直播。随着 3D 技术的不断成熟,火山引擎多媒体实验室的 3D 技术不仅在 VR 领域、自动驾驶、视频直播、游戏等场景落地具体的应用,而且将会在在工业、医疗、建筑家居、航空航天等领域持续探索。火山引擎希望能够将物品重建技术、场景重建技术及光场视频技术广泛应用到各行各业的产品和项目中去,服务于企业客户,为用户带来更高清、更互动、更沉浸的创新体验。总结与展望TECHNOLOGY EXPLORATION048基于深度学习的超分辨率效果优化字节跳动视频业务线上每天都能接收到海量的投稿视频,我们在服务端接收到这些视频时,可以发现由于上传用户的拍摄设备性能层次不齐,存在大量低清低质视频。为了提升这类低清视频的清晰度,我们可以在服务端对其使用超分辨率算法。超分辨率(Super-Resolution),是一种提高图像、影片分辨率的技术。分辨率是一种用于描述影像细节分辨能力的指标,即每个方向上的像素数量,分辨率越高,影像清晰度越高。摘要技术探索049基于神经网络的超分辨率我们以 SRCNN (Super-resolution convolution neural network)为例,简单介绍基于神经网络的超分辨率算法。网络的输入是一个低分辨率的图像,而输出是一个高分辨率的图像。该过程主要分成三个步骤,区块特征抽取与表达(Patch extraction and representation)、非线性对应(non-linear mapping)以及重建(reconstruction)。网络的训练方式一般是使用高分辨率的图片作为标签,并且使用 Bicubic 或者 Bilinear 等退化方式得到低分辨率图片作为网络输入,通常使用 L1 或者 L2 的损失函数进行监督。近年来随着深度神经网络的流行以及发展,相关技术被应用于该场景中,并且其效果大幅领先基于插值的传统算法。Fig 2.SRCNN 示意图 2Fig 3.SRCNN 效果示意 2Fig 1.不同分辨率下的图片 10TECHNOLOGY EXPLORATION050这样训练得到的网络,在客观指标 PSNR 上大幅超过例如 Bicubic 这种基于插值的 Scaling 方法,其中 PSNR 为峰值信号比,是衡量超分辨率算法的重要客观指标。Fig 4.更多超分辨率算法客观数据对比 8MethodScaleSet5Set14B100Urban100Manga109PSNSSIMPSNRSSIMPSNRT SSIMPSNRT SSIMPSNRT SSIMBicubicx233.660.929930.240.868829.560.843126.880.840330.800.9339SRCNN 1x236.660.954232.450.906731.360.887929.500.894635.600.9663FSRCNN 2x237.050.956032.660.909031.530.892029.880.902036.670.9710.VDSR 4x237.530.959033.050.913031.900.896030.770.9140.37.220.9750.LapSRN 6x237.520.959133.080.913031.080.895030.410.910137.270.9740MemNet 9x237.780.959733.280.914232.080.897831.310.9195.37.720.9740EDSR 10 x238.11.0.960233.920.919532.320.901332.930.935139.100.9773.SRMDNF 11x237.790.960133.320.915932.050.898531.330.920438.070.9761D-DBPN 16x238.090.960033.850.919032.270.900032.550.932438.890.9775.RDN 1 7x238.240.961434.010.921232.340.901732.890.935339.180.9780RCAN(ours)x238.270.961434.120.921632.410.902733.340.938439.440.9786RCAN (ours)x238.330.961 734.230.922532.460.903133.540.939939.610.9788在 SRCNN 之后还出现了众多其他的超分辨率网络的研究,比如 EDSR、RCAN 等,但网络框架以及训练方式和 SRCNN 大同小异。实际场景效果不佳超分辨率的主观效果优化我们在实际使用时,往往会发现直接使用以上提到的深度学习超分辨率网络,会出现主观效果不佳的情况。比如对以下表情包的图片使用 pre-trained EDSR 网络,会发现其主观效果和 Bicubic 差不多,对输入的提升效果很有限。我们接下来从几个角度来介绍一些优化超分辨率网络主观效果的方法。Fig 5.网络图片 9 使用 EDSR 和 Bicubic 进行上采样的效果对比基于 GAN 的超分辨率网络首先我们介绍第一个优化手段。超分辨率是一对多的任务,一个低分辨率图可能有无数个高清图相对应,在这种情况下用 L1 或者 L2 作为损失函数训练,就会导致网络学习的结果会指向所有高清可能的平均,主观上看来即是一片模糊。技术探索051基于真实下采样优化训练数据另一个优化点是训练数据。我们以上讨论的超分辨率的训练数据对,往往是通过 Bicubic 或者其他已知下采样方式得到的。然而往往真实场景并不是,从而导致模型训练数据和实际预测数据存在比较大的差距,使得超分算法效果不够理想。我们这里介绍一种同样基于对抗生成网络的真实下采样生成方式。如图 9 所示,对于一张高分辨率图,我们训练下采样生成器 G 和判别器 D,使得 G 生成的低分辨率图和真实低分辨率图接近,从而得到真实下采样 G。为了解决这个问题,我们可以在网络训练的过程中引入 GANloss,即使用对抗生成的方式来对超分辨率网络进行训练,通过 GANloss,我们使得超分辨率网络生成的结果分布在真实、自然的高分辨率图的流形之上,而不是一片模糊的平均结果。图 8 显示的是在 Set14 测试图片上的部分超分辨率网络主客观表现,我们可以发现 PSNR 指标和主观效果并不一致,并且基于 GAN 的超分辨率算法 PSNR 指标甚至低于 Bicubic。Fig 7.基于对抗生成网络的超分辨率 4Fig 8.基于对抗生成网络的主客观表现 4引入先验信息除了以上优化点,另一个比较直接的方法是,在神经网络中加入先验高层语义信息来辅助超分辨率重建。比如在 SFTGAN 中,我们引入一个先验的语义分割网络,以 SFT layer 的形式加入到重建网络中。但是实际场景中,语义信息往往过于复杂,很难用一个网络去进行分析和表达,所以结合通用分割网络的方法也难以明显提升主观效果。但如果局限在部分特殊场景下,这种引入先验知识的方式可以提升超分辨率的效果。Fig 9.基于 KernelGAN 的真实下采样生成方式 6Fig 10.SFTGAN 结构示意图 5Fig 11.DICGAN 结构示意图 1得到了 G 以后我们便可以利用高分辨率图大量生成满足真实下采样退化的训练数据对。在满足真实下采样退化的数据对上进行训练,我们能获得在真实场景下表现较好的超分模型。TECHNOLOGY EXPLORATION052对输入的噪声进行考虑 在真实场景中,低分辨率输入往往存在除了下采样之外的其他退化,比如噪声、压缩失真、模糊等等。我们在训练超分辨率网络的过程中如果不考虑这些因素,也会使得网络的主观效果较差。因此我们在训练过程同时应该根据应用场景,引入对应的退化。我们在服务端实际使用时,需要对输入的图片进行质量分析。依靠我们所建立的服务端无参考质量评价算法,我们对输入视频在多个维度上进行质量估计,并且对其使用相应退化训练的超分模型进行处理。Fig 13.自研无参考视频质量评价体系Fig 12.DICGAN 在 CelebA 和 Helen 数据集上的主客观表现 1如图 11 所示,如果我们将场景限定到人脸区域,将人脸五官的先验知识融合到超分辨率重建网络之中,能够在主观以及客观上均得到较明显的提升。MethodCelebAHelen PSNRSSIMPSNRSSIMBicubic23.580.628523.890.6751SRResNet 2025.820.736925.300.7297URDGN 41 24.630.685124.220.6909RDN 4526.130.741225.340.7249PFSR1524.430.699124.730.7323FSRNet 526.480.771825.900.7759FSRGAN 525.060.731124.990.7424DIC.27.370.796226.690.7933DICGAN26.340.756225.960.7624总结在结合以上所说的优化点后,我们再回顾图 5 中的低分辨率表情包,输入是属于人脸场景,并且存在较强的低质退化问题。我们对其使用上面所讨论的一系列的算法对其进行优化,可以发现处理结果的主观效果得到了极大的提升。本文对基于深度学习的超分辨率算法主观效果优化,从生成式模型、引入语义信息、优化训练数据、考虑输入退化等多个维度展开了讨论。总的来说,随着视频业务不断扩张,我们每天都能接收到源源不断的投稿视频,一方面视频种类繁多,其次视频质量层次不齐,再者用户对视频清晰度的要求越来越高。在提升视频的分辨率这个问题上,我们需要结合多个算法点并且根据具体场景进行优化使用,才能为用户带来更好的体验。Fig 13.左图为 Bicubic 上采样结果,右图为超分优化结果技术探索053火山引擎实时低延时拥塞控制算法的优化实践摘要火山引擎智能拥塞控制算法 VICC(Volcano Intelligent Congestion Control)是一种自适应的拥塞控制算法,旨在解决全球不同网络环境下,不同音视频应用对带宽利用率和延时的差异化要求。它结合了传统拥塞控制算法(如 GCC 和 BBR)的优点,并且能够根据不同的网络条件、业务偏好和码率特征进行自适应调整,包括自适应拥塞响应速度、自适应带宽探测幅度、自适应丢包检测策略、自适应抗抖动能力和自适应 Padding。通过这些自适应调整,VICC 算法能够提升各种复杂弱网下的带宽利用率,同时在满足不同延时的条件下,尽量提升带宽的稳定性,为用户提供更好的音视频体验。TECHNOLOGY EXPLORATION0541.行业现状和挑战实时音视频应用的网络传输面临诸多方面的挑战,其中包括:带宽利用率:为了提供高质量的音视频体验,需要充分利用网络带宽,这就要求网络传输算法具有高效的带宽探测能力。延迟和响应时间:实时音视频应用要求快速的响应时间和超低延迟,这就要求网络传输技术具有快速的传输速度和低延迟的特性。可靠性和稳定性:网络传输过程中可能会出现拥塞、丢包等问题,这会影响到音视频的质量和稳定性,因此要求网络传输技术具有可靠性和稳定性,能够保证数据的正确传输和恢复。公平性和资源分配:在多用户场景下,需要保证网络传输的公平性和资源分配的合理性,以避免某些用户获得过多的资源,导致其他用户的服务质量下降。除了上述挑战,实时音视频传输还需要关注体验指标,如实时性、流畅性、清晰度、音画同步性等,这些指标对于提供高质量的音视频体验至关重要。1.1 现网音视频卡顿归因1.2 rtC 主流拥塞控制算法分析为了快速提升线上用户弱网相关的体验,火山引擎根据抖音集团真实用户的负反馈数据打磨研发了“音视频卡顿归因模型”,它可以对线上音视频卡顿的所有 case 进行自动归因和聚类,为弱网问题的优化和优先级给出有效指导。根据模型对线上用户音视频卡顿反馈的归因和聚类,我们发现,当前引起线上卡顿问题的主要原因是上下行大小缓存问题。自 Google 开源 WebRTC 实时音视频框架以来,GCC 作为默认拥塞控制算法备受行业研究和关注,而 WebRTC 在演进过程中,也在不断演进集成 BBR、PCC 等拥塞控制算法,以期望进一步提升实时音视频的传输性能。下文以 GCC 和 BBR 算法为例,我们来看一看当前主流拥塞控制算法的特性和不足。大小缓存的描述,可以参考:https:/www.ietf.org/archive/id/draft-cardwell-iccrg-bbr-congestion-control-00.txt 大缓存:Deep buffers,at bottleneck links with deep buffers,congestion happens before packet loss.小缓存:shallow buffers,in shallow buffers,packet loss happens before congestion.线上用户视频/音频卡顿归因类型占比技术探索055GCC 算法GCC 算法是专为实时音视频传输设计的拥塞控制算法,但随着网络环境日益复杂、音视频应用场景越来越丰富,GCC 算法难以提升上限以获得更好的音视频传输体验。GCC 算法带宽估计与触发拥塞延时示意图GCC 算法的关键特征GCC 算法存在的问题bbr 算法GCC 算法的发送/接收码率的联动是非连续性的。在检测到拥塞之前,发送码率和接收码率是不联动的;检测到拥塞之后,发送码率和接收码率才开始联动。如果要降低非联动过程中的网络延迟,GCC 算法需要通过降带宽排空非联动过程中网络中堆积的数据。另外,GCC 的网络探测速度也较慢。GCC 算法的几个主要问题中,最核心的问题是带宽估计的准确性(带宽利用率)和拥塞检测的有效性(对网络的冲击)存在很难调和的矛盾,导致这个问题的主要原因是:GCC 算法的带宽估计强依赖拥塞检测,即,只有在算法判断为网络拥塞的情况下,才能进行带宽估计;GCC 算法的拥塞控制灵敏度受到带宽估计的影响很大,意味着当实际发送码率越贴近真实带宽,拥塞检测受到的干扰越大BBR 算法是互联网通用的拥塞控制算法,其设计目标追求高带宽利用率、低拥塞延迟和丢包,BBR 在通用互联网领域具备良好的性能表现,但因其设计目标和算法特性,不适应于实时音视频传输场景。BBR 算法带宽估计与触发拥塞延时示意图TECHNOLOGY EXPLORATION056BBR 算法的关键特征和 GCC 算法不同,BBR 算法的发送/接收码率的联动是连续性的,它实时跟踪接收码率,同时根据拥塞检测的结果,来调整发送窗口(cwnd)的大小,并最终影响发送码率。BBR 算法存在的问题虽然 BBR 在带宽估计准确性上等能力要高于 GCC,但它也存在一些明显的问题:突发拥塞时收敛速度慢;当链路丢包高于一定阈值时,吞吐量断崖式下跌;抗抖动能力一般;反向链路丢包延时影响上行带宽估计;探测最小延迟剧烈降窗不适用实时音视频传输;由于 GCC 和 BBR 等算法在实时音视频传输场景存在一些不足,火山引擎网络传输团队自研了 VICC 算法,旨2.火山引擎智能拥塞控制算法 ViCC 介绍VICC 算法主要通过网络状态统计进行自适应带宽估计决策,并作出带宽评估动作,以提升各种复杂网络下拥塞控制的性能表现。在近一年的实验室和线上业务打磨过程中,我们深入分析了不同算法原理及现网痛点弱网问题,输出了 40 项最佳工作点及 9 篇技术专利,线上业务的各项指标,特别是视频卡顿率、首帧时长等也得到了显著的改善。火山引擎智能拥塞控制算法 VICC 架构图技术探索0572.1 网络状态统计2.2 自适应拥塞控制评估当前网络状态的重要指标之一是网络状态统计参数,而准确的基础网络状态参数是提高带宽估计准确性和带宽利用率的关键基石。VICC 算法提供了多种基础网络状态参数,部分基础网络状态统计参数如下:VICC 算法结合了传统拥塞控制算法的优点,并且能够根据不同的网络条件、业务偏好和码率特征进行自适应调整,包括自适应拥塞响应速度、自适应抗干扰能力、自适应丢包检测、自适应带宽探测幅度、自适应拥塞排空等。自适应拥塞检测VICC 继承并优化了 GCC 和 BBR 拥塞检测能力,通过对发送码率、接收码率及延迟参数的关系进行建模,观察延迟参数变化趋势及其关联性,以及对于延迟参数的容忍程度进行拥塞响应,从而快速排空网络拥塞。和 GCC/BBR 相比,VICC 拥塞响应及收敛速度更快。GCC/BBR/VICC 拥塞响应及收敛速度比较(线上实测)TECHNOLOGY EXPLORATION058灵活可配置的拥塞检测灵敏度自适应抗干扰能力在自适应拥塞检测的基础上,VICC 还会根据业务偏好,提供灵活可配置的拥塞检测灵敏度模式设置,以适用于不同业务场景的诉求,并做好拥塞响应灵敏和抗干扰能力强的 trade-off。以火山引擎 RTC 典型应用场景为例,互娱、企业通讯等场景一般可以容忍 200-300ms 的延时,而远程车控、云游戏等场景只能容忍 50-100ms 的延时。VICC 提供多种模式来适应不同场景的延时需求,在延时容忍度较高的场景,VICC 可以通过延迟拥塞响应时间来获得更高的带宽估计的稳定性,在延时容忍度较低的场景,VICC 可以通过快速拥塞响应来降低网络拥塞延迟。拥塞响应越灵敏,意味着在网络抖动场景下容易误判,导致算法抗干扰能力下降。VICC 使用蚁穴算法来对抗网络抖动和乱序,通过接收码率和发送码率来度量网络透过率,并结合观察延迟参数变化趋势及关联性,提升自适应抗干扰能力。VICC 可以对抗 2000ms 以内的延迟抖动幅度,抗抖动能力显著比 GCC 和 BBR 强。GCC/BBR/VICC 抗抖动能力比较(线上实测)火山引擎 RTC 典型应用场景技术探索059复杂弱网处理能力2.3 自适应 PaddinG 策略考虑实时音视频传输对于延迟的容忍,根据延迟参数的程度、自适应上探幅度及下探幅度,在保留竞争力的同时,VICC 避免了因为频繁探测引入的网络延迟堆积问题。同时,在检测到拥塞缓解后,VICC 通过对发送码率、接收码率及延迟参数的关系进行建模,迅速提升带宽上探幅度和调整时间窗口;在探测到带宽满足音视频传输体验后,再逐步放慢上探幅度和时间间隔。当网络存在瓶颈带宽时,VICC 的带宽探测相对 GCC 和 BBR 更平稳。当瓶颈带宽发生变化时,VICC 可以快速跟踪实际瓶颈带宽。VICC 使用自适应 Padding 策略来解决带宽下溢叠加复杂弱网场景下的带宽估计,在精准探测网络带宽的同时,尽量避免网络冲击和带宽浪费。在决策需要发送 Padding 时,会先根据带宽估计值设定目标发送码率,并实时度量接收码率,同时动态调整目标码率。GCC/BBR/VICC 随机丢包抗性比较(线上实测)GCC/BBR/VICC 带宽探测平稳度比较GCC/BBR/VICC 带宽探测平稳度比较自适应丢包检测能力通过对发送码率、接收码率及丢包参数的关系进行建模,并微幅调整发送码率,检测接收码率和丢包参数之间的关联性,VICC 可以自适应检测出丢包为随机丢包和拥塞丢包。一旦识别出随机丢包后,VICC 可以准确地对随机丢包进行系数补偿,以达到不误降带宽的效果。和 GCC/BBR 相比,VICC 随机丢包抗性可达到 70%以上。TECHNOLOGY EXPLORATION0603.ViCC 表现及收益3.1 算法表现4.未来展望3.2 线上收益通过对拥塞响应速度、带宽探测幅度、丢包检测策略、抗抖动能力等一系列的“自适应调整”,VICC 算法能够提升各种复杂弱网下的带宽利用率,同时在满足不同延时的条件下,尽量提升带宽的稳定性,为用户提供更好的音视频体验。为了更直观地展示 VICC 算法对于用户音视频体验的提升效果,我们在不同类型的弱网环境下进行了音视频通话测试,通过比较对端画面的实时性和流畅性来比较 VICC 算法和市场上同类算法的拥塞控制能力。在上行 70%丢包网络环境下,使用了 VICC 算法的火山引擎 RTC 依然保持稳定传输,几乎没有表现出卡顿。当网络突发上行 300kbps 限速小缓存时,使用了 VICC 算法的火山引擎 RTC 出现了短暂的卡顿,但算法很快进行了对抗,迅速恢复稳定和流畅,对用户的体验影响较小。在网络环境高度复杂的背景下,影响用户体验的因素众多,有时通用算法难以精准匹配所有场景的环境特点,因此,一些特定场景的用户体验难以做到极致,无法实现“个性化场景自适应”的目标。未来,我们将根据线上问题归因聚类建模,对用户网络场景精准识别,提升网络场景识别算法的准度和范围,并以此为驱动,针对不同的弱网场景进行全链路的差异化优化,使算法在各类网络模型下的收敛达到最优,持续提升用户体验。VICC 算法经过了字节内部质量专项评估实验室打磨和验证后,在火山引擎线上业务上也进行了充分的流量验证,在视频通话、屏幕共享等场景中,视频卡顿率和首帧指标得到了显著的改善,其中,视频通话卡顿率下降 27%、首帧延时下降 100ms ;屏幕共享卡顿率下降 15%,首帧延迟下降 200ms。同时,使用自适应 Padding 策略后,现网上下行码率也得到了明显的改善,其中,上行 Padding 码率下降 90%,下行下降 70%。VICC 算法上线后对视频卡顿、首帧和 Padding 码率指标的改善技术探索061智能驾驶技术的不断发展,正在改变着我们的出行方式和交通系统。作为其中的一个关键技术,三维重建在智能驾驶系统中起着重要的作用。除去车端本身的感知、重建算法,自动驾驶技术的落地与发展需要庞大的云端重建能力支撑,火山引擎多媒体实验室通过行业领先的自研三维重建技术,结合强大的云平台资源与能力,助力相关技术在云端大规模重建、自动标注、真实感仿真等场景的落地与应用。本文重点介绍火山引擎多媒体实验室三维重建技术在动态、静态场景的以及结合先进光场重建技术的原理与实践,帮助大家能更好的了解和认识云上智能三维重建如何服务智能驾驶领域,助力行业发展。云上智能驾驶三维重建最佳实践摘要TECHNOLOGY EXPLORATION062技术挑战与难点驾驶场景重建技术介绍驾驶场景重建需要对道路环境做点云级别的三维重建,与传统的三维重建技术应用场景相比,驾驶场景重建技术有以下难点:车辆运行过程中的环境因素复杂且不可控,不同天气、光照、车速、路况等均会对车载传感器采集到的数据造成影响,这对重建技术的鲁棒性带来了挑战。道路场景中经常会出现特征退化和纹理缺失的情况,例如相机获取到视觉特征不丰富的图像信息,或者激光雷达获取到相似性较高的场景结构信息,同时,路面作为重建中的关键要素之一,色彩单一且缺少足够的纹理信息,这对重建技术提出了更高的要求。车载传感器数量较多,常见的有相机、激光雷达、毫米波雷达、惯导、GPS 定位系统、轮速计等等,如何将多传感器的数据融合起来得到更精确的重建结果,对重建技术提出了挑战。道路中存在运动车辆、非机动车、行人等动态物体,会对传统重建算法带来挑战,如何剔除动态物体对静态场景重建带来干扰,同时对动态物体的位置、大小、速度进行估计,也是项目的难点之一。自动驾驶领域的重建算法通常会采用激光雷达、相机为主,GPS、惯导为辅的技术路线。激光雷达可以直接获取高精度的测距信息,能够快速得到场景结构,通过预先进行的激光雷达-相机联合标定,相机获取到的图像能够为激光点云赋予色彩、语义等信息。同时,GPS 和惯导可以进行辅助定位,减少重建过程中因为特征退化而出现的漂移现象。但是,由于多线激光雷达售价较高,通常用于工程车辆,而在量产车上很难得到规模化的使用。对此,火山引擎多媒体实验室自研了一套纯视觉的驾驶场景重建技术,包括静态场景重建、动态物体重建和神经辐射场重建技术,能够区分场景中的动静态物体,还原出静态场景的稠密点云,并突出路面、指示牌、红绿灯等关键要素;能够对场景中运动物体的位置、大小、朝向和速度进行有效的估计,用于后续的4D标注;能够在静态场景重建的基础上,使用神经辐射场对场景进行重建和复现,实现自由视角的漫游,可用于场景编辑和仿真渲染。这套技术解决方案不依赖激光雷达,且能够达到分米级的相对误差,用最小的硬件成本实现接近激光雷达的重建效果。2.1 静态场景重建技术:剔除动态干扰、还原静态场景视觉重建技术以多视角几何作为基础的理论依据,要求待重建的场景或者物体具有帧间一致性,即在不同图像帧中处在静止状态,因此需要在重建过程中剔除动态物体。根据场景中的不同要素的重要性,稠密点云中需要去除无关紧要的点云,而保留一些关键要素点云,因此需要事先对图像进行语义分割。对此,火山引擎 多媒体实验室结合 AI 技术与多视角几何基本原理,搭建了一套先进的鲁棒、精确完整视觉重建算法框架。重建过程包括三个关键步骤:图像预处理、稀疏重建和稠密重建。技术探索063车载相机拍摄过程中处在运动状态,由于曝光时间的存在,采集到的图像中会随着车速提高而出现严重的运动模糊现象。另外,出于节约带宽和存储空间考虑,传输过程中会对图像进行不可逆的有损压缩,造成画质的进一步降低。为此,火山引擎多媒体实验室使用了端到端的神经网络对图像进行去模糊处理,能够在抑制运动模糊现象的同时对图像质量进行提升。去模糊前后的对比如下图所示。去模糊前(左)去模糊后(右)为了区分出动态物体,火山引擎多媒体实验室使用了基于光流的动态物体识别技术,能够得到像素级别的动态物体掩膜。在之后的静态场景重建过程中,落在动态物区域上的特征点将被剔除,只有静态的场景和物体将得到保留。光流(左)运动物体(右)TECHNOLOGY EXPLORATION064稀疏重建过程中需要同时计算相机的位置、朝向和场景点云,常用的有 SLAM 算法(Simultaneous localization and mapping)和 SFM 算法(Structure from Motion,简称 SfM)。在不要求实时性的情况下,SFM 算法能够得到更高的重建精度。但是,传统的 SFM 算法通常将每个相机当作独立相机来进行处理,而车辆上通常会在前后左右不同方向布置多个相机,这些相机之间的相对位置其实是固定不变的(忽略车辆振动带来的细微变化)。如果忽视相机与相机之间的相对位置约束,计算出来的各相机位姿误差会比较大。另外,当遮挡比较严重时,个别相机的位姿会难以计算。对此,火山引擎多媒体实验室自研了基于相机组整体的 SFM 算法,能够利用相机之间的先验相对位姿约束,以相机组作为整体来计算位姿,同时使用了 GPS 加惯导的融合定位结果对相机组中心位置进行约束,可有效地提高位姿估计的成功率和准确率,并能改善不同相机之间的点云不一致现象,减少点云分层现象。平面方程(左)二次曲面方程(右)传统 SFM(左)相机组 SFM(右)将激光点云视作真值,并将视觉重建结果与之叠加,可以直观地衡量重建点云的准确性。从下图中可以看到,重建点云和真值点云贴合度非常高,经过测量得到重建结果的相对误差在15cm左右。火山引擎多媒体实验室重建结果(彩色)与真值点云(白色)技术探索065以下是火山引擎多媒体实验室视觉重建算法和某主流商业重建软件的效果对比。可以看到,和商业软件相比,火山引擎多媒体实验室的自研算法重建效果更好、更完整,场景中的路牌、红绿灯、电线杆,以及路面上车道线、箭头等还原度非常高,而商业软件的重建点云非常稀疏,且路面大范围缺失。某主流商业软件(左)火山引擎多媒体实验室算法(右)动态重建 pipeline2.2 动态重建技术:在图像上对物体进行 3d 标注十分困难,需要借助于点云,当车辆只有视觉传感器时,获取场景中目标物体的完整点云十分困难。特别是动态物体,无法使用传统的三维重建技术获取其稠密点云。为提供运动物体的表达,服务于4d 标注,使用 3d bounding box(以下简称3d bbox)对动态物体进行表示,通过自研动态重建算法获取每一时刻场景中动态物体的3d bbox 姿态、大小、速度等,从而补全动态物体重建能力。对车辆采集的每一帧图像,首先提取场景中的动态目标,生成3d bbox的初始提议,提供两种方式:使用2d目标检测,通过相机位姿估计对应的 3d bbox;直接使用 3d 目标检测。两种方式针对不同数据可以灵活进行选择,2d 检测泛化性好,3d 检测可以获得更好的初值。同时,对图像动态区域内部的特征点进行提取。获取单帧图像初始 3d bbox 提议及特征点后,建立多帧间数据关联:通过自研多目标跟踪算法建立物体匹配,并通过特征匹配技术对图像特征进行匹配。获取匹配关系后,将有共视关系的图像帧创建为局部地图,构建优化问题求解全局一致的目标bbox估计。具体地,通过特征点的匹配以及动态三角化技术,恢复动态 3d 点;对车辆运动建模,联合优化物体、3d 点、相机之间的观测,从而获得最优估计的动态物体 3d bbox。2d 生成 3d(左二)3d 目标检测示例TECHNOLOGY EXPLORATION066动态物/影子剔除,填补2.3 nErF 重建:真实感渲染、自由视角使用神经网络进行隐式重建,利用可微渲染模型,从已有视图中学习如何渲染新视角下的图像,从而实现照片级逼真的图像渲染,即神经辐射场(NeRF)技术。同时,隐式重建具有可编辑、查询连续空间的特性,可以用于自动驾驶场景中自动标注、仿真数据构建等任务。使用 NeRF 技术对场景进行重建是非常有价值的。火山引擎多媒体实验室融合神经辐射场技术与大场景建模技术。在具体实践中,首先针对数据进行处理,场景中的动态物体会使 NeRF 重建出现伪影,借助自研动静态分割、影子检测等算法,对场景中和几何不一致的区域进行提取,生成 mask,同时利用视频 inpainting 算法,对剔除掉的区域进行修复。借助自研三维重建能力,对场景进行高精度的几何重建,包括相机参数估计以及稀疏、稠密点云生成。另外,对场景进行拆分以减小单次训练资源消耗,并可做分布式训练、维护。在神经辐射场训练过程中,针对室外无边界大场景,团队通过一些优化策略以提升该场景下的新视角生成效果,如通过在训练中同时优化位姿提高重建精度,基于哈希编码的层次化表达提升模型训练速度,借助外观编码提升不同时间采集场景的外观一致性等,借助 mvs 稠密深度信息提升几何精度等。团队同毫末智行合作,完成单路采集以及多路合并的 NeRF 重建,相关成果已在毫末 AI Day 发布。体验优化067体验优化03EXPERIENCE OPTIMIZATION体验优化069如何利用播放器节省 20%点播成本?点播成本节省的点其实涉及诸多内容,例如 CDN、转码、存储等,而利用播放器降本却是很多客户比较陌生的部分。火山引擎基于内部支撑抖音集团相关业务的实践,播放器恰恰是成本优化中最重要和最为依赖的部分。火山引擎的视频团队做了份数据统计,在一个很经典的视频业务中,我们在 2022 年至 2023 年大约 1 年半的时间里,针对这个业务进行了 33 次成本优化点,其中 13 次是播放器主导的优化,其余的有 12 次也是需要播放器强配合的优化,也就是说在这个业务里,75%的成本优化是直接或间接由播放器参与,可见客户端对成本优化的关键作用。最终我们在很多实践中也发现,通过播放器的优化可以为点播业务节省 20%甚至更多的成本,本篇内容便将聚焦在播放器层面如何节省成本这一主题上。摘要EXPERIENCE OPTIMIZATION070在视频点播的成本构成中,有很明显的二八原则:CDN 带宽成本占绝对的大头,80%都是带宽成本;其次是存储和转码成本,二者占不到 20%;额外还有一些其他的周边的成本,比如日志处理的数据成本、AI 处理的成本。我们可以将成本的优化理解成“置换”,在点播的成本优化中,就存在 2 种“置换关系”:第 1 种置换关系是“成本项之间的置换”,指的是 带宽-转码-存储之间的置换。在过去,“单价”是非常明显的因素,大家往往选择在采购环节尽量的压低单价;而“用量”上通常会被认为是无法改变的业务因素。但“用量”实际上是包含 2 类,一类是正常用量,确实是比较难改变的业务因素,但另一类是“浪费”,是可以被优化的。所以如何识别出浪费、降低浪费,是播放器降本的关键点。那么造成浪费的因素有哪些呢?例如:我们增大缓存时长,对应体验上卡顿率就会降低,但是成本会增加;抖音小视频 feed 流场景,我们做预加载,这时候首屏感会更顺滑,但对应的成本是增加的;降低码率,那么体验上感到清晰度变差了,而成本就是减少的;跷跷板中间支点是技术,我们通常是希望固定体验、降低成本,依靠技术来支撑。所以我们总在说降成本,那降的到底是什么呢?我们这里用一个很简单的乘法公式来表示:第 2 种置换是“成本和体验的置换”,我们一般说是“跷跷板效应:上图是 H.264 升级到 H.265 编码格式的例子,265 的压缩率相对比 264 要优 20%-40%,所以带宽、存储上 265 是大幅度减少;但是 265 的计算复杂度要复杂很多,所以转码成本大幅度升高。而这个图不是一个等边三角形,带宽成本要远大于转码和存储成本,所以这个置换是非常划算的。点播成本构成体验优化071例如在视频播放过程中,会包括“已播放的数据”,和“未播放但已经缓存的数据”,如果用户中途离开播放,那其中“已缓存的数据”都是浪费了。所以我们定义“浪费”是“已经缓存了、但不需要的字节数”。Range 是 http 协议的一个请求头,默认是“0-请求”,表示请求完整文件。左侧的图示意,如果是单独发一个“0-请求”,那么 CDN 服务端就会持续的返回整个文件,如果在中途断开,从服务端视角来说,这些数据已经发送过去了,无论客户端是否需要,都已经计费了,就构成了浪费。播放器的成本优化方法从理想上来说,没有浪费是最好的;但往往业务中,浪费是非常大的,大于 30%是很常见的。常见的可能带来的浪费包括了:未播放离开 向后拖拽 切换档位 清晰度溢出(举例:很小的手机屏幕播放 4K 的内容,肉眼感知不到清晰度的区别)针对上述的浪费我们进行了如下的具体优化方法:承接上图的播放器缓存示意图,如果用户播放过程中离开了,那么深灰色是浪费部分。很容易就想到我们减少深灰色的部分的大小,比如把播放水位降低 1/3(也就是图中浅黄色的部分减少掉),不去缓存,那么浪费就明显的减少了。这个就是静态水位的思路,通过减少缓存水位来减少浪费。但是,静态水位是很难抉择的,水位大了浪费多,但是水位太小了,卡顿就会明显的增加。播放器缓存进度示例(一)缓存的浪费这里有个马太效应,从原理上,缓存的本质是为了对抗网络的抖动的。网络稳定好时,只需要很少的缓存就足够了,但是网络好时缓存会填充的很快,大部分时间都是饱和的。反之,波动大的网络,需要更多的水位,但总的上限也有限,无法提供有效的缓存。为此我们实现了的动态水位算法,我们根据一些因素来动态的决策缓存水位的大小:探测用户的网络速度和稳定性,对稳定性高、速度快的,我们减少缓存;对网络速度差、稳定性差的网络,就增大缓存,这样在网络抖动时就能够有更大的缓存空间使用;根据用户的播放行为,通过数据分析道,视频观看的前期,用户离开的比例会更高,观看的后期,离开的比例就会降低,所以前期的缓存水位小一些,后期的缓存水位大一些;一些其他的因素,但目的是在每次播放时决策出一个尽量合理的缓存水位,来平衡卡顿和浪费。决定了缓存水位大小之后,还有个细节点就是 Range 请求。EXPERIENCE OPTIMIZATION072上图是动态水位算法 动态 Range 拆分的效果示意图:横轴代表时间线。纵轴上图是视频下载的大小,蓝色块代表一个 Range 请求;下图是缓存的大小,橙色的折线表示缓存随着视频文件下载和播放时间的波动情况,横着的虚线是目标水位。我们从左到右,分析下目标水位和 Range 的关系:第 1 条竖红线,决策出来第一条目标水位 1,是启播水位,启播时的 Range 会略大于后面的 2 个 Range;第 2 条竖红线,是判断出一次水位提升,有可能是检测到网络波动,会提高目标水位到水位 2,同时做一次略大的 Range 请求来达到目标水位;第 3 条竖红线,是再次提升目标水位,到水位 3,有可能是因为观看时长增加到阈值,判断离开概率较小,所以保持高水位;后续的播放,在目标水位 3 随着时间波动,Range 大小也会稳定些。在上图,我们分成 3 段来发 Range 请求,中途断开时,是可以停止掉最后一段,那么浪费就大幅度减少了。同样,静态的 Range 是很难抉择的,Range 拆分的太细会引起卡顿的提升;Range 过大了成本节省的效果又不够了。这里我们引入目标水位的概念,就是刚刚讲的动态水位算法所决策出来的水位大小。播放器 Range 请求的应遵循两个原则:将当前视频尽快缓存到目标水位。控制 Range 拆分的大小,避免太小的 Range 拆分。从最终效果上看,在任意一个时间点离开,都能够保障相对合理的浪费。我们在不同业务上实践了很多次动态水位 动态 range 的 AB 实验,在体验指标持平或更优的前提下,带宽降低 8%。我们做的“精准预加载策略”,在“时机、大小、个数”上做精细化的优化:时机上:对预加载也进行切片,这样可以区分出来一部分是紧急的,其他是不紧急的。比如图里,标记 P0 的是要最优先下载的,然后可以做预加载,预加载标记 P1 的部分,然后是当前视频的缓存水位,之后可以选择是否要预加载 P3 的部分。大小上:每个视频也会结合视频的长度、头大小、码率等因素计算出来需要预加载的大小 个数上:按照 feed list 中的优先级依次预加载后续 N 个视频(动态计算),也会结合用户本身的行为(比如快速滑动)来动态决策。AB 实验证明,能够提升预加载利用率 5%,对应流量成本降低约 0.8%。在类似于抖音这种 feed 流下滑的场景,会提前加载好下面的视频,能够使滑动更顺畅,我们 叫“零首帧”效果,里面作用最大的就是预加载。一般的预加载是固定几个视频,每个视频固定的大小。为了得到更好的预加载效果,会尽量多、尽量大的做预加载,也就构成了浪费。(二)预加载的浪费体验优化073(三)清晰度的浪费(四)异常流量的浪费数据挖掘成本优化空间现在的主干场景是在移动端看视频,大家都会有启播选档的策略,就是在播放启动时,决定所需要的清晰度,一般是跟随网速、码率来决策的。经常大家面临的场景是,在竖屏里播放横屏视频时,实际上在很窄的一个空间里进行播放,这个时候,如果依然使用完整的清晰度,那么肉眼是看不出来的清晰的。而且,通常情况下小窗播放时用户的主要关注度也并不是画面清晰度,所以就产生了实际上的清晰度浪费。我们对应的解决策略叫“窄屏低清”,就是识别出来显示区域很窄时,播放低清晰度的视频(比如 360P),当需要横屏时,再快速的切换为正常的清晰度。这里如果是 mp4 格式播放,需要转码也做些配合,支持 mp4 的帧对齐和平滑切换。在很多应用中都是很常见的,也有常见的小窗播放,多个业务的 AB 实验都能有 3%以上的成本收益;另外清晰度上还有个很棒的能力,是客户端超分。随着客户端超分能力的优化,现在很大一部分机型在客户端向上超分一个档位是完全没问题的,耗电可以忽略。对应节省成本的策略是“降档超分”,就是分发的清晰度向下降一档,然后再通过客户端超分降主观清晰度补回来。在国内当前的机型条件下,大部分业务能够有 68%左右的成本收益。在非常多的业务中会发现第三种情况:流量有异常浪费,比如有部分视频码率过高,可能是没转码,或者转码模版用错了。我们开始时会认为“这些都是很明显的失误,业务层小心点不就行了么?”,但后来我们做成了单独的异常流量分析模块。我们跟业务尝试分析原因,发现业务总是复杂的:业务场景很复杂,包括短视频、长视频、主页视频、广告视频等;研发的迭代通常会带来些历史问题;并不是所有的人员都需要持续的感知成本,只要有一个环节漏掉了,那么就可能会造成很大浪费。这里还有个问题点,如果是体验问题或者 bug,总会有用户保障,来及时发现。但成本问题,用户基本是无法发现的,发现时就比较晚了。我们是通过端到端的日志分析来发现和避免这些浪费的。原理很简单:在客户端对日志染色;cdn 日志里记录的,区分是否是播放器产生的、是否是我们点播的域名;对两头的日志进行比对和分析。不仅如此,这里还有个副产物,是通过这些日志分析,识别到业务真实是被盗链了,然后做盗链的治理。我们根据 播放器日志是否可以识别、是否是正常流量把流量分成了 4 类。以上是火山引擎是实际业务服务过程中探索出的优化方案,但优化是不是有上限的,优化到什么水平可以达到成本和体验的平衡,更多的能力是通过数据能力持续的挖掘出来的。先从结果上来看,我们成本优化后通常会有 2 个报告:AB 实验报告,里面会分析对 QoE 的体验影响多少,对成本优化的影响多少,比如图中的人均播放时长增加多少,成本降低多少;做成本的 AB 实验,依赖一个工具客户端成本指标。EXPERIENCE OPTIMIZATION074(一)客户端成本指标(二)成本评估公式这张图从左往右是视频点播的数据流向。想要建设好成本埋点,有 2 个难点:成本拟合。因为真实的计费数据是左侧 CDN 的计费日志,在右侧的客户端侧实际上是没有成本数据的,所以我们需要把数据缓存层的对成本的埋点尽量的拟合,使之尽量的对应到 CDN 的计费日志。这个过程是非常艰难的,我们通过了大量的离线校验。提升可解释率。业务动作比较复杂(播放、预加载、拖拽、重播等等),举个例子,重复播放,播放层是记录 2 遍播放时长的,但是因为有缓存,真实的网络请求只有 1 遍。我们想要两份数据尽量对齐、可解释,就需要涵盖住尽量所有的业务场景。我们当前达到了“可解释率达到 95%”,也就是说比如服务端 CDN 产生了 100Gbps 的带宽,客户端的日志能够拟合解释清楚 95%。虽然还不到 100%,但日常来做成本优化、成本归因已经足够了。下图是成本指标进入 AB 实验后的结果:“成本评估公式”,本质是一种单位成本的衡量方法。下图是成本指标进入 AB 实验后的结果:成本数据进入 AB 实验有什么用呢?有 2 点:快速判断客户端的成本变化结果。大部分成本优化的能力都是伴随着策略的,不同策略有不同的结果置换关系,我们需要通过实验来确定效果。假设没有客户端的成本数据的话,我们就需要用不同的 CDN 域名来实验,这是很低效的,并且域名带宽的波动也会引起成本的波动。而在客户端成本指标进入了 AB 实验之后,大部分场景都直接看报表数字就可以了。机制上可以防蜕化。业务的产品经理、分析师等角色也日常会关注到实验数据的,当成本数据也进入实验后,这些角色也可以关注到成本的变化,这样就能够防退化了。举个例子,版本升级时,只要经历了 AB 实验,就很难有成本退化的问题。图:核心指标图:归因指标 价值回溯文档,用于核算真实收益有多少,一般发生在完整上量之后,比如 1 个月或 2 个月后。关键结果叫“万分钟播放成本”,这个对应的依赖的工具是“成本评估公式”。体验优化075我们叫“万分钟播放成本”,分子是点播的 IT 成本,分母是点播视频消费时长。从技术侧来看,分子是“CDN、存储、转码等各种成本的加和”,分子是播放的时长。这个公式很简单,但为什么要这么做呢?因为涉及到成本优化,就会跟采购、财务团队打交道,采购、财务看到的都是每月的账单,业务用量每个月都在上下波动,导致账单每个月也都在波动。万分钟播放成本是单位成本,就可以刨除掉业务用量的影响因素,来衡量成本是否真的优化了。拿其中的万分钟 CDN 成本来举例:万分钟 CDN 成本的影响因子会涉及到价格、码率、浪费率、带宽流量比。举一个真实的例子:有个客户反馈成本增加了,但是客户自己的业务用量在波动,不太好判断是什么情况。我们拆解分析万分钟 CDN 成本的具体影响因子,就发现了万分钟 CDN 成本确实是涨了 11%,主因是“码率”涨了 8%,“浪费率”增加了 5%。在服务业务的过程中,大家经常会面临一个问题,还能再降多少?极限是多少?解决方法是做顾问。如上图所示,其是我们的一个万分钟 CDN 成本与理想万分钟成本的一个差异分析表,我们给计算出了对应的差异,然后再给出可以补足差异的策略或功能推荐。当然,这个表只是一个总结概览,更多的内容我们会整理成“顾问服务报告”,把各个点的差异、业务分析、解决方法与业务逐一的讨论分析。总之,万分钟播放成本是一个非常简单、容易落地、价值很大的工具,大家计算下万分钟播放成本,如有调优的诉求,非常欢迎来与火山引擎交流。火山引擎视频点播 https:/ 3 种方式来建设标准:通过排名获取标杆:将类似场景的业务进行排名,对齐当前技术做的最好的,可以作为一种标准;离线的实验来模拟:我们做了成本的自动化测试平台,设计测试 case,测试出来不同的参数的成本结果是多少,最后总结分析出来极限是多少;通过“理论公式”来推算“标准”:举例通过“视频播放时长、中途离开比例”的关系,然后推算出理论的优化空间有多少。EXPERIENCE OPTIMIZATION076深度解读字节跳动的画质评估工具抖音也在用画质评估体系建设历程(一)为何评测画质如此重要?我们通过线上业务大量实验发现,图片画质优劣对点击率、停留时长等消费类指标有正相关影响,间接影响用户收益指标。因此,建设一套行之有效的画质评估体系,保障用户的画质体验是非常有必要性的。直观来讲,画质提升能够为带来更好的观感体验,但 QoE 综合体验也需要考虑其他方面如用户设备、网络状况、观看环境等多方面因素,不计成本地提升画质是否能持续为用户带来 QoE 的收益需要在业务场景中通过严谨的实验方案来验证效果的。在低质图像打压和基于画质的推荐优化等多项业务中的数据分析积累沉淀,我们获取画质评分与用户主观体验之间的明确关系,数据统计显示用户对不同画质内容的敏感程度有着不同趋势,在中档画质分区间持续提升画质,用户的 QoE 体验也会显著提升,但当画质低于或者高于某个阈值时,用户对于画质将变得不再敏感,提升/降低画质对用户的影响均会降低。本文从抖音集团内部画质评估体系的建设历程着笔,主要分享画质评测对于业务的重要性、主要应用场景和内部产品的一些典型实践案例,希望通过分享业务视角遇到的一些问题和解决思路,能够为遇到类似困扰的伙伴提供有价值的参考。典型场景画质评估体系提供的价值通过转码、压缩或其他手段实现图片降本,可能损害画质提供客观标准,用于平衡压缩效果和画质体验通过画质增强、打压低质图片等手段提升用户画质体验提供量化指标,用于分析现状、评估优化效果和辅助调整优化策略摘要体验优化077期望中的画质甜点关系,中段区间的画质提升会持续带来 QoE 收益:实际业务场景中,分析画质与用户平均观看时长的关系,中高画质可以带来持续的看播收益。下图具体描述了两类典型应用场景下,画质评估体系在业务实践中发挥的主要价值:典型应用场景转码优化推荐打压业务实践经验基于 QoE 画质的关联因素,高画质和低画质区间会存在饱和趋势,最佳策略为根据源内容画质对编码策略分类调控:1.对低画质区间使用更激进的编码参数,在轻微 QoE 损失的前提下节省带宽成本2.在中间画质区间适当提升编码质量,用较低的带宽成本换取更好的 QoE 体验大多数业务中基于用户画像的推荐系统中,模型的隐藏参数维度会隐式地包含一定画质层面因素,比如画质敏感用户会不喜欢低画质推送内容等,针对不同模型系统画质指标会有不同的优化策略。常见地,画质&QoE 优化推荐策略可以分为两个层面:通降策略和特征融合策略。1.通降策略一 般直接使用画质多维度分数,设计不同的推荐打压或提高触发策略,直接作用于移除推荐候选组低画质内容,或者降低低画质内容推荐权重,实现低清打压的后处理逻辑来提升用户的画质观感。2.特征融合策略则是补充画质多维度的特征作为模型训练的权重,提升推荐模型的 CTR 等关键指标效果,在实际业务中会有更好的效果。(二)我们为何自研画质评估体系?图像服务的最终用户是人类,图像质量评价致力于成为可衡量图像的人眼感知质量需求的客观计算方法。1、行业现状 主观质量评估:最准确,但费时费力费钱,难以批量应用。例如专家评测、众包测试等。客观评估算法:省时省力可大规模应用,但无论全参/无参考算法与主观评测均存在一定 GAP,在 UGC 场景,差距会更加明显。EXPERIENCE OPTIMIZATION078业界常用的有参画质评估算法,主要包括 PSNR、SSIM、VMAF 3 种:算法名称转码优化推荐打压PSNRPSNR(Peak signal-to-noise ratio)是峰值信噪比,是一个表示信号最大可能功率(视频像素值最大值)和影响它的表示精度的破坏性噪声功率(测试视频与参考视频之间的误差)的比值。本质上就是表示两个信号的相似程度。当两个视频其中-一个为无失真视频,另一个为失真后的视频,二者的 PSNR 可以看成是失真视频的质量衡量指标。它是当前业界最常用的有参客观质量指标,最常用的用于评价压缩失真的画质指标之一。45:非常好SSIMSSIM(structural similarity index)是-种用以衡量两个图像或视频结构相似性的指标,该指标主要从亮度(luminance).对比度(contrast)和结构(structure)三个方面来衡量两个图像/视频之间的区别。当两个视频其中一个为无失真视频,另-个为失真后的视频,二者的 SSIM 可以看成是失真视频的质量衡量指标。0.98:好VMAFVMAF(Video Multi-Method Assessment Fusion)是由 Netflix 提出的一个客观有参考视频质量指标,它也是当前业界广泛认可的有参画质指标。它主要使用了 3 种基础指标:visual quality fidelity(VIF)、detail loss measure(DLM)、temporal information(TI),其中 VIF 和 DLM 是空间域的也即一帧画面之内的特征,TI 是时间域的也即多帧画面之间相关性的特征。最终使用机器学习算法(SVM)将三个基础指标融合成最终的画质分数。97:非常好2、痛点3、我们如何建设画质评估体系?难以量化画质增强效果:行业通用指标(PSNR、SSIM、VMAF 等)均为有参考画质指标,主要适用于压缩失真的画质评估,难以量化评估画质增强效果。不适合 UGC 场景的评分:行业通用指标适用场景存在一定局限性,其训练数据集主要为 PGC 内容,在 UGC 场景的泛化效果较差。评估维度有限:UGC 场景下,图片内容复杂且画质影响因素多样,需要更多维度评估指标用于画质分析和指导优化。根据点播、直播和图片等不同形态业务需求,火山引擎多媒体实验室自研的 VQScore 画质体系提供配套最优的全链路画质打分能力,提供异步或实时画质打分数据,为后续转码、增强、推荐策略和大盘监控提供能力支持。具体画质分析打分能力分为两个部分:内容分析理解:主要包含 ROI 检测、CG 内容检测、人脸检测、内容分类等基础分类和检测的能力,为后续画质打分和增强转码提供细分的维度拆解能力和关键内容识别能力,实现精细准确的端到端自适应增强转码组合能力 画质打分能力:主要包含通用清晰度打分算法、美学指标、高阶色彩指标、人像画质等评估指标,噪声、块效应、过曝、脏镜头、模糊和伪高清等细分归因指标,以及超分质量、锐化质量和增强组合评估等前处理画质提升能力评估指标,通用 归因 增强多个维度组合,为不同的业务场景的画质优化需求提供集监控、分析、策略推荐等全方位画质打分能力。体验优化079通用的画质清晰度评估算法基于多样化多业务场景主观标注样本、开源数据集和多样化失真合成数据集,驱动的轻量 transformer-based 深度学习的方案,在 UGC 视频/图像场景提供更稳定准确的客观清晰度预测能力。在多种业务场景下,根据点播、直播和图片不同形态业务需求,支持最高 4K 分辨率内不同投稿内容的源画质分析,结合业务属性维度提供深入细化的画质维度分析,为自适应转码提供编码优化对比和不同时间尺度的画质监控,为 AB 实验和版本迭代等业务流程提供有效的 QoE 维度数据,同时也可以为多分辨率/码率档位播放下发提供画质与 QoS 网络、设备等因素组合组合的自适应播放分发优化能力。(三)抖音画质评估体系有哪些优势?1、适用范围广泛 高质量且规模庞大的训练数据集,覆盖 PGC 和 UGC 内容,适用范围广泛(特别针对 UGC 场景)。算法模型历经亿级 DAU 产品持续打磨优化,泛化能力强。EXPERIENCE OPTIMIZATION080以瘦身计划和体重秤之间的关系做个简单类比,画质评估体系作为一套相对客观且行之有效的评测工具,在帮助产品了解业务画质现状、了解行业和市场现状、监测线上画质变化和支持提升用户体验等方面都有非常广泛的应用。画质评估主要应用在哪些场景?2、评估维度多元包含主观清晰度、大众美学质量等两类综合指标和噪声、亮度等十余类细分指标,支持更多维度、更细粒度地分析画质问题,便于业务有针对性地进行优化和调整策略。3、多业务线上验证收益显著历经抖音、头条、番茄小说等数十个大体量业务线上验证,评估效果可靠,能有效支持业务进行画质体验提升,进而带来用户消费指标提升,收益显著。4、算法能力业内领先画质评估体系涉及的算法模型已申请多项专利。eg.一种检测伪高清视频的方法,一种基于多任务孪生神经网络的高阶视频色彩质量评价模型,一种三明治视频自适应播放方法等。在 ICME 2021 的压缩 UGC 视频质量评估比赛中,火山引擎-多媒体实验室凭借自研的 VQScore 算法斩获无参考视频质量评价(NR-VQA)MOS 赛道第一名。该比赛主要针对 UGC 源视频画质和 H.264/AVC 压缩失真对视频主观画质的影响的研究。了解业务画质现状业务团队可以借助 veImageX 提供的画质评估工具,通过离线测评和在线评估等手段高效完成业务产品的画质摸底;同时,画质评估体系包含丰富的评测维度(例如噪声强度、色彩质量、块效应检测、过曝光检测等),数十项细分评测指标可高效帮助业务团队完成低质图像归因分析,快速锁定问题所在。了解行业/市场现状借助画质评估工具,可以帮助业务团队对市场主流产品或同类业务进行画质评测,以便制定合理的画质提升目标;同时,综合用户主观评测和客观指标的对应关系,高效帮助业务团队确定适合自身业务的画质评估标准。监测线上画质变化对于一款关注用户画质体验的产品来说,线上画质监测工具必不可少。而 veImageX 提供端到端的画质指标监测工具,可帮助业务团队长期高效监测线上画质变化;通过前后数据对比分析,帮助业务有效验证画质优化举措的效果;同时,线上低质问题告警也可帮助业务团队及时发现问题,保障线上用户浏览体验。支持提升用户体验借助画质评估体系提供的评测结果,业务团队可以通过对低质图片进行搜索/推荐降权等方式打压低质内容,或借助画质增强能力提升画质,有效提升用户的浏览体验,进而带来点击率、人均阅读/消费时长、用户留存等业务指标正向提升。体验优化081目前,由火山引擎 veImageX 提供的画质评估工具已服务于抖音、头条、西瓜、番茄小说、懂车帝等数十条业务线,在保障用户的画质体验方面发挥着重要作用。接下来,我们选取了几个典型案例为大家简要分享我们的实践经验。典型案例实践分享(一)某短视频/社区平台需求背景某短视频/社区平台的主要用户分布在多个国家和地区,发布内容覆盖多个细分垂类。业务团队收到部分用户反馈关注到不同国家和内容垂类间的画质存在一定差异,影响了用户的浏览体验,从而设立专项进行问题解决。实践方案业务团队首先使用画质评估工具对全地区的图片画质进行了离线摸底分析,发现部分国家间、某些重点垂类间的图片画质有较大差异,故使用自适应增强模型,针对性进行画质提升的同时尽可能节省码率。整体收益优化后,该平台各地区间、重点垂类间的画质基本拉齐且均达到【良好】及以上水平,图片大小显著降低,人均停留时长、人均互动、人均阅读时长、人均 session 次数等消费指标均显著正向。(二)番茄小说需求背景相比于网文,漫画的书封更加精美,信息量也更多,因此在产品形态上,番茄小说频道采用了大屏的展现形式。然而,在漫画功能上线后,业务团队发现,有部分漫画的原始书封比较模糊,严重影响用户浏览体验。如下图所示:为了提升这部分图片的画质,业务团队想到了通过画质评估筛查低质图片,使用画质增强能力搭建自动化处理流程,针对性处理低质图片,得到高清图,以提升整体观感。业务团队使用 veImageX 画质评估工具,针对出版物(如小说封面、插图、电子书书封、有声播放器封面等)和漫画(漫画封面、横图等)等场景进行离线画质测评,对不同分辨率图片进行画质摸底。根据对低质原因的分析和增强算法对主观画质提升的收益大小综合评估,明确差异化的处理方案。最终业务团队选择搭建自动化处理流程,根据评估结果对不同画质等级的图片进行如自适应增强、超分等优化处理,针对性提升用户的画质浏览体验。实践方案EXPERIENCE OPTIMIZATION082番茄小说团队借助 veImageX 画质评估和画质增强能力,有的放矢的提升画质,有效提升了用户画质体验和点击率、人均阅读/消费时长、留存等用户消费指标。整体收益低质图片优化前后对比如下:场景画质收益业务收益出版物评估建议:低质增强算法整体效果较稳定,在整个数据集上有 34 分 vqscore 的收益,在中高分辨率且低质量图片上收益较高。2 倍和 4 倍超分算法分别有约 6.1 和 6.8 分的 vqscore 收益,但在部分图片上细节保留较差,在中低分辨率图片上收益较高画质收益:针对不同分辨率图片采用不同的画质增强模型,整体带来约 5 分 vqscore 收益出版物人均阅读时长指标持续正向提升 x%漫画评估建议:低画质和中低画质占比约 x%,此部分部分图片建议开启增强。中高画质和高画质经增强处理后,大图和小图 vqscore 均有提升,主观画质提升不明显,此部分可暂不开启增强画质收益:低画质经增强处理后,大图 vqscore 提升约 21 分,小图 vqscore 提升约 9 分,主观画质明显提升 中低画质经增强处理后,大图 vqscore 提升约 15 分,小图 vqscore 提升约 6 分,主观画质明显提升 漫画渗透、消费时长和点击率等均正向 漫画功能回访、5 日留存多天显著正向体验优化083(三)今日头条(四)幸福里 Vr需求背景头条小视频频道主要以双列展示为主,而双列流频道展现形式又以封面图为主。综合线上实验结果和实践经验发现,封面图的画质质量不仅会影响用户浏览体验,也会影响点击转化率和用户留存等业务指标,如何有效识别封面模糊的内容并进行打压调控成为一项较为棘手的工作。实践方案借助画质评估工具,业务团队对封面图进行画质打分,高效识别出低质封面(blockiness X 且 vqscore 8s随着卡顿加大到 12s100s 音频渲染卡顿次数、时长01,6389ms100s 视频渲染卡顿次数、时长18,85710ms6,13272ms上下行带宽 3Mbps上下行延迟 150ms上下行丢包 5%推流编码码率1833kbps440kbps拉流 demo 计算 delay视频基本完全卡死随着卡顿加大到 40s100s 音频渲染卡顿次数、时长3,31480ms100s 视频渲染卡顿次数、时长18,83998ms体验优化0915%丢包 150ms rtt 的情况,RTM 推流就已经卡得无法播放了(表格中的-表示基本无法播放,数据无法统计)。经过和各家 CDN 服务端的联合分析,我们发现了几个问题:某云 CDN 发送的音频 NACK 包没有携带正确的 sender ssrc,导致丢失的音频包没有重传;VolcEngineRTC 发送 RTCP XR 报文时 DLRR block 有问题,导致 CDN 无法正常估算网络 rtt,视频重传次数很快用完,进而导致视频重传也基本无效;CDN 推流边缘节点视频组帧之前的 buffer 过小,导致客户端重传的视频包也基本没有生效;CDN 没有启用 TCC 算法(之前用的 REMB 算法),推流端对网络状态的适应能力差;在技术架构上,火山引擎直播 CDN 采用的是上文介绍的第一种技术架构,即边缘的收流节点会把 RTP 组帧,转换成 RTMP/FLV 流推到源站,这里我们展开介绍火山引擎直播 CDN 在组帧环节做的两个优化。组帧 jitter buffer:针对抖动、乱序、丢包重传场景,如果 CDN 接收组帧 buffer 设置得太小,就会导致帧丢失和 GOP 丢失,从而影响用户观看直播的流畅度并引起卡顿感;如果 CDN 接收组帧 buffer 设置太大,则由于组帧引入的延迟就很大,降低直播的交互性。为了解决这个问题,我们参考 WebRTC 的 NetEQ,引入了网络自适应的 buffer,即通过估算推流侧的网络抖动设置接收组帧 buffer 大小。对于大部分网络较好的推流,组帧 buffer 引入的延时极小;对于抖动、乱序、丢包重传的推流,又可以保障流畅性同时尽可能少引入延时。组帧交织:UDP 数据包不保证到达顺序、视频组帧抖动等因素,会引起转换出 RTMP/FLV 流中的音视频不严格交织,有的视频连续 34s 都没有音频(或反过来)。在拉流端到端延时低至 23s 的背景下,播放端会因为音画同步机制引入卡顿,影响用户看播体验。对于这个问题,我们在 CDN 接收组帧的 jitter buffer 出帧时,结合音视频 jitter buffer 的长度,做了音视频交织,确保音视频帧尽量均匀,dts 差距不能过大。经过线上验证,不交织引起的播放卡顿显著下降。上述问题都解决之后,再次进行模拟弱网测试,结果有了很大的改善:推流端 ByNet 配置(拉流端不设置弱网)RTM 推流RTMP 推流上下行带宽 3Mbps上下行延迟 70ms上下行丢包 5%推流编码码率1833kbps440kbps拉流 demo 计算 delay2.7s随卡顿增加到 20 s100s 音频渲染卡顿05,6248ms100s 视频渲染卡顿035,87983ms上下行带宽 3Mbps上下行延迟 150ms上下行丢包 5%推流编码码率1833kbps-拉流 demo 计算 delay2.9s-100s 音频渲染卡顿0-100s 视频渲染卡顿0-EXPERIENCE OPTIMIZATION092可以看到在 10%丢包 150ms rtt 时,推流仍保持在自适应的最高码率进行推流,并且拉流也没有任何卡顿。不过在丢包率增加到 15%甚至 20%时,RTM 推流的效果也基本就不行了,但我们分析线上数据发现,丢包率超过 10%的情况占比很少,所以就没有继续优化了。最后我们请视频云团队的音视频实验室对 RTM 推流和 RTMP 推流在抖音上进行了权威的测评,测评结果为:抖音推流RTM vs RTMP 评测报告 弱网下:各指标均优于 RTMP 正常网络下:视频首帧、视频延时、音频延时优于 RTMP,视频卡顿、音频卡顿、音画同步和画质基本持平 RTMP推流端 ByNet 配置(拉流端不设置弱网)RTM 推流RTMP 推流上下行带宽 3Mbps 上下行延迟 150ms上下行丢包 10%推流编码码率1833kbps-拉流 demo 计算 delay3.8s-100s 音频渲染卡顿0-100s 视频渲染卡顿0-上下行带宽 3Mbps上下行延迟 150ms上下行丢包 15%推流编码码率440kbps-拉流 demo 计算 delay4.9s-100s 音频渲染卡顿0-100s 视频渲染卡顿5,18816ms-上下行带宽 3Mbps上下行延迟 150ms上下行丢包 20%推流编码码率440kbps-拉流 demo 计算 delay78s-100s 音频渲染卡顿0-100s 视频渲染卡顿21,67908ms-经过上述一系列工程优化,最后开启线上 AB 实验,相比基线算法 RTMP,结果却不如预期:QoE 开播场次无明显趋势,开播时长稳定偏负,被看播指标无明显趋势,QoS 音频渲染百秒卡顿时长/次数-3.641%/-4.649%,视频渲染百秒卡顿时长/次数-2.926%/-8.044%。直观的疑问是:为什么 QoS 卡顿有收益了却没有 QoE 收益,甚至 QoE 还是负向?为了探寻原因和更好的进行下一步迭代优化,我们开始深入到 RTM 算法部分进行研究。算法优化体验优化093黑盒测评分析基于抖音 app 测试推流,拉流影响则使用了拉流 demo无网损场景、相同直播推流内容下,测试发现,RTM 比 RTMP 目标码率更加保守。e.g.图:(左)RTM(TCC 开启)的 2Mbps 网损下画面质量;(右)无网损画面质量2Mbps 网损下,RTM 带宽利用率仅 50%,对于拉流侧的影响则是画质损伤严重,e.g.这意味着 RTM 在部分场景下通过牺牲画质体验置换来了卡顿收益。问题分析我们基于抖音的数据集,分析出了以下 3 类关键问题:1、bwe 周期性震荡问题红色线 bwe 震荡波动,大概率会导致黄色线目标码率震荡波动;bwe 的波动不是因为高丢包率,rtt 也是在绝对值较小(100ms 以内)范围内波动。基于线上大规模数据分析EXPERIENCE OPTIMIZATION094我们选取了 典型的非稳态网络场景进行上述问题复现实验,并对算法内部原理进行分析,发现:在非弱网比如只是 rtt 较小范围(150 以内)抖动的网络场景下,VolcEngineRTC TCC 带宽估计算法中,delay_based_bwe 部分,trendline estimator 对时延信号太过敏感,经常误判弱网,导致周期性下调估计的带宽值,从而降低了带宽利用率。白盒测试复现问题及根因分析2、目标码率周期性震荡问题3、传输能力足够,固定式码表限制了画质提升bwe 高达 8Mbps 以上,而 max bitrate 才 3Mbps 左右我们还量化识别了问题类型在全部数据集中的重要程度情况:bwe 波动较普遍(19.7%),且 bwe 波动几乎都会引起目标码率波动 目标码率波动更普遍(28.3%),但不一定是由 bwe 波动引起的 在低带宽场景下更容易产生 bwe 波动目标码率自身震荡波动,不是受 bwe 影响的(bwe 是稳态的)体验优化095具体分析过程如下:首先是复现问题场景,这里举例 2 个场景来说明。4Mbps 带宽 时延波动场景(左图)的实验表现和前面线上埋点(5 秒级别)的波动现象吻合,当 bwe 波动在码表范围内,该测试场景复现了线上 bwe 波动的问题场景;带宽泊松波动场景(右图)周期性波动问题复现更加明显。其次,进行问题根因定位。bwe 波动的根因在于算法频繁置位 overuse(左图)来降低所估计的带宽,而 overuse 的判别逻辑在 delay_based_bwe 部分,trendline estimator(基于趋势线的时延估计器)这里把时延抖动误判成了弱网(注:误判是指实际的 rtt 和丢包情况均不表现为弱网特征,如右图的子图 4 和子 5)。2 张图合二为一:2 张图合二为一:1、调优已有 VolcEngineRTC bwe 算法模型参数无须写代码、等待发版周期,以最快速度缓解问题我们梳理了 VolcEngineRTC 代码逻辑以及 bwe 算法参数。好处是可以很方便的通过线上配置直接修改做实验,但是缺点是参数太多、调参太耗费精力且很大可能是收益非常有限(理论上参数的默认值应该就是一个推荐的最优值了),最终我们决定先凭借经验挑选了几个关键参数作为一期方案优化,离线验证调参的收益后就开展一期方案线上 AB 实验,期间也为我们留下了相对充足的时间去做后期优化。解决方案带宽估计算法参数改动改动理由overusing_time_ threshold从 10ms 改到了 100ms降低 bwe 算法对时延波动的敏感度,提升带宽利用率pacer_ times从 4.5 改到了 2.5标准的 gcc/tcc 算法下该参数为 1,谷歌 bbr 算法pacing_ gain 都没有 4.5 这么激进,而且在这么激进的参数下并没有提高 bwe 带宽估计的准确性/带宽利用率tcc_ min_ bwe 从 200 改到了与直播推流码表 min bitrate 想同传输层最小传输能力适配应用层需求,提升码率EXPERIENCE OPTIMIZATION0962、Beyond VolcEngineRTC bwe 算法,进行线上问题模式检测与 bwe 模型纠正最小化对 VolcEngineRTC 代码/bwe 算法模型的入侵修改,同时达到解决问题的目的我们在 bwe 算法之上,引入周期性震荡场景识别及平滑策略,以改善带宽估计的准确性、提升带宽利用率,进而提升视频画质。1、解耦码控算法与带宽估计算法在原来 RTM 推流的架构下,没有单独的码率控制算法,码控的上下界由 LiveCore 的码表决定,在上下界之间如何变化则完全是由 VolcEngineRTC bwe 算法决定。上述架构存在以下 2 个问题:A.bwe 算法的问题会直接体现在码控层面,e.g.前面的问题类型(bwe 震荡波动几乎一定会引起码率震荡波动,进而导致画质问题,e.g.业务方反馈的推流码率突降导致画面模糊的问题)B.码控算法很好地利用了 VolcEngineRTC 弱网感知优势,却忘记了利用 VolcEngineRTC 的强网感知优势,e.g.当带宽估计值超过码表码率上界时,还可以超越码表上界再进一步提升码率(非中国区码表上界比中国区低很多),从而提升画质。因此,我们将传输层的 bwe 算法和应用层的码控算法进行了解耦。在 RTM SDK 层面设计实现单独的码控算法,可以更加灵活的根据业务场景/需求设计码控策略。2、目标码率波动在线识别和平滑策略与 bwe 算法的震荡波动识别和平滑思路类似,设计在线检测算法识别码率周期性波动并进行码率平滑。码控算法不一定要听从 bwe 算法,因为 bwe 算法也可能误判,此外,非实时通讯的直播场景下,秒级的端到端延时、推流拉流均有 buffer 情况下,不一定要立即响应带宽的波动,码控算法可以选择性的在清晰度和流畅度(卡顿)之间平衡,根据线上实验用户体验偏好进行迭代。码控算法体验优化097在有限的测试场景下:弱网场景 bwe 波动识别与平滑方案开启 vs 该方案关闭bwe 波动识别与平滑方案对 bw、rtt 抖动场景的 bwe 进行了有效的平滑,特别是 rtt jitter 场景下有效去除了部分不必要的码率下调,有约 10%的码率收益;码控码率波动识别与平滑开启 vs 该方案关闭码控优化点 2 即使在 bwe 波动识别与平滑方案关闭的情况下也可平滑一定的网络震荡(特别是 bwe 波动场景下);码控优化方案整体在强网下 PSNR 有约 6%的收益(720p);bwe 波动识别与平滑方案叠加码率波动识别与平滑效果两者无冲突,在带宽剧烈波动场景下叠加生效有带宽利用收益;强网场景相比对照组无负向效果,以上实验中拉流侧均未出现卡顿。综上,在有限测试场景下,bwe 波动识别与平滑方案在 rtt jitter 场景有更明显的码率收益,而码率波动识别与平滑方案在 bwe jitter 场景有明显的画质收益,两者叠加在两种场景下均有较好的码率收益。算法优化离线效果评估目前为止,我们的 RTM 方案在抖音已经落地以及完成放量,在抖音的指标收益主要在主播人均被看播时长/被关注/被评论显著正向,拉流音频/视频卡顿-22.2%/-7.8%,端到端延迟-1.6%。优化结果EXPERIENCE OPTIMIZATION098超低延时直播技术演进之路据中国互联网络信息中心发布的中国互联网络发展状况统计报告显示,截止到 2022 年 6 月我国网络直播用户规模达到了 7.16 亿,占网民整体的 68.1%。最主要原因是 2020 年度疫情期间导致居家办公和休闲娱乐的人数呈现激增,新媒体互动直播成为了广大网民最重要的休闲娱乐方式之一。随着直播产业链的不断扩展完备升级,相关产业链各个环节分工逐渐明确且各环节参与人数逐步增多;为了满足不同的就业需求,引发相关就业人数提升,通过直播形式赋能传统产业升级转型,并与高新技术融合创新,优化传统行业商业模式,如直播带货、新媒体广告传媒转型等。丰富的传统文化、新闻、竞技体育、法律、知识共享等内容,通过移动端互动直播的形式得以更加高效的展现传播,既让优质的直播内容可以实现爆发式传播扩散,又可以让用户有更多的机会感受,学习甚至主动参与直播互动,实现内容供给侧和需求传播的多方共赢。可以说,超低延时直播技术正在走上一条全新的发展之路。InfoQ 将联合火山引擎视频直播团队推出超低延时直播技术演进之路系列,带您探索超低延时直播技术的演进历程,揭示背后的挑战和突破,以及对未来直播行业的影响。摘要体验优化0991.RTMP 协议的延迟问题RTMP 协议是最传统的直播协议,主播端采用 RTMP 协议推送 H.264/5 和 AAC 编码的视音频数据到云厂商 CDN 服务器进行转封装分发,端到端延迟一般控制在 3 到 7 秒。问题是 RTMP 的可扩展性存在缺陷,同时对于延迟的进一步下探存在一定的技术困难。RTMP 协议情况下:为了满足延时降低必然压缩播放器的下载缓冲区,这样会引发显著的卡顿问题,使得播放的观感产生不舒适的感受(延时下探至 2 秒以下)。(一)传统标准直播技术的局限性网络基础设施升级、音视频传输技术迭代、WebRTC 开源等因素,驱动音视频服务时延逐渐降低,使超低延时直播技术成为炙手可热的研究方向。实时音视频业务在消费互联网领域蓬勃发展,并逐渐向产业互联网领域加速渗透。经历了行业第一轮的红利爆发期,我国实时音视频行业的场景效能逐渐深化,步入到理性增长阶段。延时的指标选择很大程度上取决于用户与内容制作方的交互耦合程度,场景丰富多样。第一篇 进化篇-超低延时直播技术的前世今生在这些极端场景下,延时在用户侧希望越小越好,接近于实时通信的低延迟模式可以最大化地激发用户的参与感,无缝地与内容生产方产生互动效应,调动用户所见即所得的积极性。比如在主播秀场的 PK、送礼、工会冲榜、打赏的活动关键环节,竞争双方的储值大户都希望实时地观察到自身主播在礼物刷榜后的反应,为后台运营决策团队或者后续活动策略提供第一时间的信息反馈。下图体现了从技术/产品/运营的三方角度来综合思考低延时直播技术的作用;从外部-内部综合因素考虑技术的变迁对整个生态正向循环的影响。EXPERIENCE OPTIMIZATION1002.观众与主播互动形式单一,是单向内容传导无法做到双向 (在 RTC 技术引入之前无法显著解决)。3.单向传导的局限第一个方面表现在:观众端拉流传输无法做到根据网络情况自适应调节。用户只能以固定的码率进行流媒体传输无法做到动态感知,在网络情况实时变化的场景(比如弱网,移动基站切换等)固定单向码率传输有较大概率造成丢帧卡顿等因素影响观播体验;另一方面在网络条件更好时,固定码率传输无法动态提升视频传输码率(更高的画质带来更加舒适的体验)。4.在直播和连麦场景共存的互动直播场景下,主播采用传统 RTMP 推流在遇到连麦 PK 场景时,会产生推流/本地连麦合流/服务器连麦合流的切换问题 这种场景变换的切换会使得观众端产生瞬间的卡顿问题;如果采用基于 webRTC 直播技术的超低延时直播方案,这种推流-连麦逻辑的合流切换问题可以得到比较友好的解决(只需要改变服务器转发-订阅流通道的分发逻辑,不涉及推流媒体数据流的旁路调度切换)。体验优化1011.超低延时直播是近年来新兴起的一类应用。如电商直播、赛事直播等场景,兼具高并发与低延时的特性,传统直播 3-20s 的时延难以满足其需求,但对实时互动的要求又不及视频会议等典型的实时音视频应用,无需将时延降低至 400ms 以下。为此,超低延时直播融合了传统直播与实时音视频的技术架构,通过取长补短的方式实现了介于二者之间的端到端时延。尽管针对超低延时直播厂商尚无一套标准的技术路径,但大体可以归纳为拉流协议、网络架构和推流协议三个方面的改造,在实际应用过程中,厂商会平衡成本及性能指标等因素,在不同的协议和网络架构之间进行选择。2.传输层协议的差异(基于 UDP 协议的可靠性优化,为弱网对抗策略提供依据)传统直播 FLV/RTMP 等采用的是 TCP 协议(或者 QUIC 协议)TCP 是牺牲传输实时性来换取数据完整性的可靠传输协议。弱网环境下,其在数据传输前的“三次 握手”连接会带来较大延时。而 UDP 作为不可靠的传输协议,其最大的优点为高实时性,但不保证数据的到达和排序。实时音视频产品(如 RTM 超低延时直播)往往采用 UDP 协议,并在此之上进行协议层与算法层的优化,来提高传输的可靠性与逻辑性。3.UDP 协议的优化UDP 协议往往和 RTP/RTCP 协议一起在实际应用中出现。RTP 负责数据传输,其协议头中的序列号、端口类型、时间戳等字段,可为数据包的分组、组装、排序提供逻辑依据;RTCP 作为 RTP 的控制协议,负责对 RTP 的传输质量进行统计反馈,并为弱网对抗策略提供控制参数。3、超低延时直播与标准直播的区别(1)基于业务场景发展的直播技术演进过程(延迟主线)(2)RTM 协议本身的演进历程 miniSDP 信令标准实现部分(抖音)CDN 信令异步回源 RTP 携带扩展头组成部分(二)超低延时直播技术的演进历程1.a=extmap:18 http:/www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp 2.a=extmap:19 uri:webrtc:rtc:rtp-hdrext:video:CompositionTime 3.a=extmap:21 uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range 4.a=extmap:22 uri:webrtc:rtc:rtp-hdrext:video:frame-type 5.a=extmap:23 uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp 6.a=extmap:27 uri:webrtc:rtc:rtp-hdrext:audio:aac-configEXPERIENCE OPTIMIZATION102 a=extmap:18 http:/www.webrtc.org/experiments/rtp-hdrext/decoding-timestamp a=extmap:19 uri:webrtc:rtc:rtp-hdrext:video:CompositionTimeRTP 使用 RTP 私有扩展头携带 DTS/CTS 值,每一帧 RTP 数据包通过 RFC5285-Header-Extension 扩展头携带该帧的 DTS 值,每一帧首个 RTP 包和 VPS/SPS/PPS 包通过 RFC5285-Header-Extension 扩展头携带该帧的 CTS 值,通过 PTS=DTS CTS 计算当前帧的时间戳。用于启播快速音画同步和播放器播控逻辑精准音画同步。a=extmap:21 uri:webrtc:rtc:rtp-hdrext:video:frame-seq-range扩展头携带帧的起始/结束序号:如果首帧的前几个包丢失,那么可根据起始序号快速发起重传加快首帧;如果当前帧的后几个包丢失,那么可根据该帧的结束序号快速发起重传,降低延时,减少卡顿。a=extmap:22 uri:webrtc:rtc:rtp-hdrext:video:frame-type扩展头携带帧的类型:如果携带并解析了正确的帧类型,客户端可以不用解析 metadata;同时在弱网情形,客户端可以跳过 B 帧直接解码 P 帧,加速出帧并减少潜在卡顿。a=extmap:23 uri:webrtc:rtc:rtp-hdrext:video:reference-frame-timestamp扩展头携带 P 帧的参考帧信息:如果发生弱网情形,那么客户端可以依照扩展头指定的参考帧关系及其对应时间戳,跳过 B 帧解码,减少卡顿发生。a=extmap:27 uri:webrtc:rtc:rtp-hdrext:audio:aac-config为了加速信令交互的速度,CDN 可以在某些条件下不去查询媒体信息,直接向客户端返回支持的音视频能力;此时 SDP 的媒体描述中将不包含有具体的音视频配置详细信息。在音频层面,此时 AnswerSDP 中不包含 aac 解码所需的头信息;此时我们需要采取 RTP 扩展头模式携带 AAC-Config 供客户端在 RTP 收包时刻自行解析处理完成解码动作,作用是减少信令交互时间,提升拉流成功率。RTM 低延时直播基于 WebRTC 技术衍生,基于 WebRTC 标准构建点到点传输一般有如下几个步骤:(1)通信双方要进行媒体协商,会话详细规范即 SDP(Session Description Protocol)交互;(2)随后进行交互式网络地址协商(查询对端真实 IP 地址)准备构建媒体传输通道;(3)当上述条件准备完毕即进入最终的 Peer to Peer 点对点媒体数据传输。信令部分客户端-服务器单独开发,利用了 SDP 标准报文模式;媒体传输部分采用开源的 WebRTC 框架和自截自研的实时音视频媒体引擎进行媒体传输。1、WebRTC 协议在直播播放器的移植体验优化103标准 SDP 比较冗长(5-10KB 左右),不利于快速高效传输。在直播场景下,会尤其影响首帧时间。MiniSDP 对标准 SDP 文本协议进行高效能压缩,将原生 SDP 转换成更小的二进制格式,使其能够通过一个 UDP 包来传输。降低信令交互时间,提高网络传输效能,降低直播拉流首帧渲染时间,提高拉流秒开率/成功率等 QoS 统计指标。2、RTC 信令协议的改造升级(MiniSDP 压缩协议)播放协议RTM-HTTP 信令RTM-MiniSDP 信令FLV首帧时间(预览)600ms510ms350ms拉流成功率(预览)97.50.00.70%降低 RTM 信令交互时间,降低 RTM 拉流首帧渲染时间。原来的流程在服务端缓存不命中时需要等待回源拿到数据,才能返回带有 AacConfig 信息的 AnswerSDP。客户端收到 AnswerSDP 后发送 STUN,而服务端只能在收到 STUN 才能开始下发数据。(如下图左);当异步回源情况下:服务端不再等待回源结果直接返回 AnswerSDP,之后回源和 WebRTC 建连流程同步进行。等到 WebRTC 建连成功且回源拿到数据立即下发 RTP 数据。(如图右)3、CDN 对 RTM 信令的异步回源优化 改善人均看播时长,改变 RTC 引擎的组帧/解码策略;禁止 RTC 在低延时模式下的丢帧,改善直播的视频渲染卡顿。4、视频渲染卡顿的优化(百秒卡顿平均降低 4 秒)实验组视频渲染百秒卡顿(直播间场景)RTM 默认 JitterBuffer 策略8.3sRTM 改进的 JitterBuffer 非丢帧策略3.6sEXPERIENCE OPTIMIZATION104 传统的 RTC 场景优先保时延,全链路会触发各种丢帧(包括但不限于解码模块,网络模块),FLV 直播场景会优先保证观播体验(不丢帧,良好的音画同步效果)。RTM 要想减少卡顿,取得 qoe 的收益,播控策略需进行定制化,定制逻辑修改点:a.确保不会由于软解的解码耗时或者硬解的 dequeuinputbuffer 等其它 api 操作阻塞 jitterbuffer,内核层有一层强制的音画同步逻辑,可以确保音视频的播放体验;b.同时上层在监控网络模块和解码模块的缓存长度,有相应的兜底逻辑:(1)判断硬解确实解不过来,dec_cache_frames 过多,上报错误,会降级到软解;(2)jitterbuffer 异常,缓存的 frame_list 过多,触发播放器异常逻辑,上报错误,重新拉流。改善移动端看播渗透,RTC 统一内核方案天生存在缺陷(MediaCodec 硬件解码器初始化耗时久);将 RTM 视频解码模块从 RTC 内核中迁移至 TTMP 播放内核,复用了 FLV 的视频解码模块(MediaCodec 避免重新初始化);显著的降低了安卓平台的首帧渲染时间,提升了拉流的成功率。RTC 内核通用逻辑5、RTM 播控逻辑的优化 改进的 RTM 内核播控逻辑以上为超低延时直播技术演进之路进化篇的所有内容,第二篇实战篇我们将聚焦于超低延时直播技术如何大规模落地实践,请大家持续关注 体验优化105WebTransport开播的应用实践之路不管是本地软件推流还是 Web 推流,需要解决的技术问题都是一样的,如何稳定地把高质量的音视频流呈现给更多用户,只不过 Web 开播的话,需要一个限定,就是在现有的 Web 技术范围内。从技术角度来解读一下这里的几个关键词:稳定性:传输协议本身的稳定性是需要保障的,优先会选择使用可靠传输,防止网损带来的花屏、杂音等问题,更重要的是,在服务链路不可用的情况下能够迅速切换服务线路。因此在推流场景下需要提供多线路备份的能力。高质量:在一些场景下,比如医疗医美营销的场景、带货的场景,要对商品细节做展示,这就要求技术方案在带宽允许的前提下,尽可能选用对画面细节损失更少的编码方案大规模用户:要分发给更多用户,那技术方案设计肯定会引入直播 CDN 服务,但是推流协议是不是能够被直播 CDN 支持,这就是一个考量的点,也是做私有协议无法满足的点。Web 开播的业务挑战摘要EXPERIENCE OPTIMIZATION106首先我们简单来了解一下 WebTransport 这个传输协议基本的技术原理。WebTransport 是基于 HTTP3 的应用层传输协议,HTTP3 的底层又基于 quic 协议,quic 协议是基于 UDP 协议实现的一套传输协议,支持可靠与非可靠传输两种形式。WebTransport 的技术原理WebTransport 对于 Web 应用的意义并不止于一个更好的传输协议,它更多的还是带来了一个更加丰富的技术栈,能够根据实际场景,结合 WebCodecs、WebAssembly 和 WebNN 等能力实现更好的应用体验。相较于 WebRTC 相对中心化的技术栈,这种方式显然是更加灵活的,易于做出更多灵活的技术组合。WebTransport 的技术优势另一个明显的优势在于 WebTransport 可以发挥页面多线程的优势,使用 WebRTC 协议,大量的逻辑只能放在主线程执行,而使用 WebTransport 就可以将整个音视频的处理流程放在 WebWorker 中,降低对主线程的占用,提升页面流畅度。同时使用多线程能够提升应用的扩展性,在面对更多的音视频任务时可以用线程来进行抽象和隔离。充分利用多线程机制降低主线程负担利用多线程机制提升应用的可拓展性从传输协议的特性上来说,它的建联速度更快,首次建联只需要 1 个 RTT,相比之下,TCP 则需要 23 个 RTT。针对已经建立过的连接,超时时间内再次建联可以实现 0RTT。在网络拥塞的情况下,减 少 RTT 次数对速度的优化是非常明显的。可以到几十 ms。最后一个体验优化107基 于 这 些 优 势,火 山 引 擎 直 播 团 队 选 择 使 用 WebTransport 优化直播推流。设计的方案是基于单向流的稳定传输,从传输格式上对标 RTMP,这样直播 CDN 的支持成本会相对较小,比较好复用目前的 RTMP 收流逻辑。由于这个技术栈较新也需要解决过程中的一些问题:虽然 W3C 定义了 AAC 的编码能力,但是 Chrome 没有提供 AAC 编码的实现,可以将 libFaaC 编译成 wasm 库来实现,另外浏览器没有针对 flv 容器的封装,需要额外支持该部分能力。那么相比于 WebRTC 推流,WebTransport 推流的实际应用效果如何呢?首次连接比 TCP 快 1 2RTT对有缓存的连接支持 0RTT特性是连接迁移,在直播过程中如果 WIFI 网络不好。切到手机热点也可以实现 0RTT,相比之下,TCP、RTC 都需要重新建立连接,恢复的速度会慢很多。为什么 WebTransport 能够比 WebRTC 推流获得更好的效果:网络传输(画质与稳定性):WebRTC 是面向实时通信的传输协议,对网络延时的变化敏感。使用 WebRTC 协议推流时,它受到网络抖动的影响较大,当网络延时的抖动发生时,RTC 的带宽估计模块会认为当前网络处于拥塞状态,需要降低发送码率以避免拥塞,码率的降低对视频画质的影响是非常大的,直观感受就会出现局部的马赛克。当使用 WebTransport 基于 Quic 可靠传输时,其拥塞控制算法对网络抖动的敏感度相对较低,可以通过牺牲一定的延迟保证发送可靠性,因此不容易出现大幅降低发送带宽的行为,画质相对有保障。编码优化(画质):WebTransport 在 Web 规范中提供了网络传输的能力,并且可以与现有的 Web 端多媒体能力进行深度集成,例如 WebCodecs、WebGPU 等。给应用的优化提供了更多编码格式、参数选择方面的空间。易于集成到直播 CDN(大规模分发):WebTransport 基于已经定稿的 HTTP3 规范,易于被直播 CDN 集成支持,应用复杂度相较于 WebRTC 更低,同时省去了 RTC 推流建连过程中的信令环节,可以加快首帧推送的速度,方便部署到更多的直播 CDN。首先在网络抖动的场景下,同样加入 100ms 延迟抖动,WebTransport 推流的画面会明显比 RTC 推流要清晰。在网络抢占的场景下,固定一个较低的带宽,使用 GCC 拥塞控制算法的数据流,面对使用 TCP 协议的数据传输,它能够分到的带宽资源是非常小的。WebTransport 推流与 WebRTC 推流效果对比EXPERIENCE OPTIMIZATION108另外,在固定 3Mbps 上行带宽的网络下,同时使用 WebTransport 和 RTC 推流,设定的目标码率都是 1.5M,过程中 RTC 推流的码率会受到严重的影响,码WebRTC 推流 100ms 延迟抖动WebTransport 推流 100ms 延迟抖动WebTransport 推流WebRTC 推流率大幅下降,不能保证画质。WebTransport 推流在不同网络状态下的流畅度表现,除了大量丢包的情况下,其余的场景都能够达到与 RTC 推流基本持平。体验优化109不同的推流协议之间各有优缺点,目前没有一个完美的解决方案,需要根据实际的场景来做选择,比如连麦场景一般需要用 WebRTC 转推,更适合低延迟互动的场景,WebTransport 方案则更适合高画质需求的场景。总的来说,WebTransport 推流的方案在解决“如何稳定地将高质量的音视频传递给大量的用户”的问题上,即实现了可靠的传输,连接稳定性有保障,并且在遭遇网损的场景,可以通过牺牲部分延迟保障音视频质量,给出了一份令人较为满意的答卷。如果想要体验 WebTransport 的开播效果,可进入火山引擎控制台进行在线 demo 体验。总结与展望EXPERIENCE OPTIMIZATION110图片在业务应用场景是一个常见的元素,veImageX(简称 ImageX)为业务提供了灵活、高效的一站式图片处理解决方案,包括了服务端 SDK、上传 SDK 和客户端图片加载 SDK。本文就来介绍下 iOS 客户端图片加载 SDK(下文中简称 SDK),SDK 主要提供图片网络加载、图像解码、图片基础处理与变换以及图片服务质量监控上报等能力。veImageX 演进之路:iOS 高性能图片加载 SDK摘要体验优化111图片在业务应用场景是一个常见的元素,veImageX(简称 ImageX)为业务提供了灵活、高效的一站式图片处理解决方案,包括了服务端 SDK、上传 SDK 和客户端图片加载 SDK。本文就来介绍下 iOS 客户端图片加载 SDK(下文中简称 SDK),SDK 主要提供图片网络加载、图像解码、图片基础处理与变换以及图片服务质量监控上报等能力。SDK 简介随着时间的推移,SDK 的功能越来越多,各种业务对 SDK 的功能选择也开始多样化起来,特别是在 App 包体积日益增长需要降低的大背景下,SDK 也需要做包体积瘦身,面对以上种种问题,SDK 对功能的模块化/插件化能力的要求也越来越高,SDK 的架构也就随之演变成下图的样子。SDK 架构在介绍 veImageX 图片加载 SDK 之前先看看业内目前有哪些主流的图片加载 SDK,veImageX 图片加载 SDK 是使用 Objective-C 语言开发的,业内使用 Objective-C 语言实现的主流开源图片加载 SDK 有 YYWebImage,SDWebImage 等。YYWebImage:一个异步图片加载框架(YYKit 的 一 个 组 件)。它 是 作 为 SDWebImage、PINRemoteImage 和 FLAnimatedImage 的改进替代品而创建的。它使用 YYCache 支持内存和磁盘缓存,使用 YYImage 支持 WebP/APNG/GIF 图片解码,但可惜的是此优秀的框架于 2017 年左右已停止更新;SDWebImage:目前使用较广泛的一个图片处理框架,可以异步加载网络图片,并支持图片本地缓存等特性,也是一款优秀的图片加载框架。业内主流开源图片加载 SDKveImageX 图片加载 SDK 也是借鉴各家之所长,基于一些业务实际线上应用的属性自研了一套图片加载 SDK,相比于这些开源图片加载 SDK,主要有以下特性:采用分层与模块化架构设计,根据业务需要选择相应功能模块,最大程度精简包大小;支持 WebP、AVIF、HEIF 这种高压缩率图片格式,特别是在自研的高性能 HEIF 软件解码库支持下,能够高效解码 HEIF 格式,并摆脱 HEIF 原生 iOS 系统版本的限制;veImaegX 的 SDK 优势 接口层,也是最上层,这一层提供图片加载与处理的各种接口,接口设计与主流开源图片加载 SDK 保持一致,在这一层提供适配器,提供了开源图片加载 SDK(如 YYWebImage,SDWebImage 等)的适配层,方便业务快速上手与无缝切换;管理层,作为中间层负责各种模块的交互管理,也包括云控配置管理和授权管理等;模块层,这一层包含了图片加载流程的各个模块:下载模块,缓存模块,解码模块,日志上报模块等,业务可以根据自身需求来选择性依赖这些模块的各种功能,达到最小化依赖的原则。SDK 主要分为三层 支持云端加密、客户端解密,保障图片隐私安全;SDK 的网络库支持 HTTPDNS,可以高效防止内容劫持及域名劫持,能够有效降低图片解码失败率,提升客户端图片加载体验;支持采集各项图片相关数据并上报,配合 veImageX 控制台实时大盘数据查看,可以为业务的运营及产品的体验提升提供全面的从数据发现、数据分析、数据监控、数据诊断、数据追踪等全链路支持。EXPERIENCE OPTIMIZATION112业务上图片的主流应用场景就是加载网络图片,以 iOS 原生系统控件 UIImageView 为例,通过 SDK 加载一张网络图片的完整流程如下:发起图片请求-查询内存缓存-查询磁盘缓存-加入下载队列-开始下载-获取到服务端图片未解码数UIImageView 如何通过 SDK 渲染出一张网络图片据-从图片未解码数据中解码后得到可以渲染的图片-将解码后的图片和图片未解码数据分别缓存进内存和磁盘-UIImageView 渲染解码后的图片,至此,一张网络图片被成功加载并展示给用户。在了解完 SDK 的主流场景中网络图片的完整加载流程后,下面分别介绍一下 SDK 加载流程中的下载、缓存、解码、日志上报与图片后处理这五大主要模块。SDK 模块介绍体验优化113下载模块的主要任务是通过网络库把网络图片从服务端下载到客户端,这个过程对图片加载来讲是非常重要的一环,下载的成功与否直接决定了图片能否正确展示,而网络库的性能也决定了图片下载的快慢,最终反映到用户的感受体验上。所以,下载模块中的下载任务除了支持苹果原生系统的网络库实现外,也支持字节内部强大的自研网络库 TTNetwork 实现,该库不仅做了一些网络相关优化,例如 HTTPDNS,HTTP2 HTTPS 连接复用优化、链路选择、动态策略等,支持最新的网络协议 QUIC,也提供了更为细粒度的网络监控,为 SDK 的图片下载提供了高效的支持。SDK 默认支持原生网络库与自研网络库,如果业务有自己的网络库,也可以通过插件化的形式集成进来。业务上一般会并发下载多张图片,在 Feed 流场景中如果用户来回滑动图片,同样的图片会发生多次请求,如果相同图片的多个请求都去反复下载图片,这样显然会浪费用户流量,也会增加带宽成本。SDK 会管理这些并发的下载任务,并标记相同的图片请求,避免这种问题的发生。下载任务的管理与调度通过 iOS 系统原生的 NSOperation 与 NSOperationQueue 实现,同时会根据请求参数生成一个 Identifier,用来唯一标识一个下载任务,交由下载管理器去管理,这样就能避免在同一个时间段内重复多次下载相同的图片。下载模块缓存模块由内存和磁盘共同组成一个二级缓存结构,当一张图片被下载到客户端上时,会被缓存进内存和磁盘缓存,如果 App 生命周期内再请求这张图片,则可以从内存缓存中查到,如果冷启动 App 后再请求这张图片,则可以从磁盘缓存中查到。这样不仅可以加快图片的加载速度,提升用户体验,也可以降低用户流量,节省带宽成本。再对缓存加上过期时间限制,就可以解决图片的时效性问题。内存缓存方面除了支持 iOS 原生的 NSCache 外,还支持 Strong-Weak 的弱引用缓存,当缓存对象无人持有时会被及时释放掉,降低内存占用,同时也支持 LRU 缓存。在收到内存不足的通知时会主动释放内存,缓解内存压力,同时保证线程安全。磁盘缓存方面除了支持最基本的 iOS 系统文件管理 NSFileManager,还支持 LRU 缓存,同时保证线程安全。整体看,如果 App 内只使用同一种固定的缓存算法的话,由于图片使用场景各不相同,同一种缓存算法无法满足所有场景,缓存命中率就会偏低。除了 SDK 默认支持的缓存算法外,由于内存和磁盘缓存都是由协议定义的,业务也可以根据需求去自定义缓存,在不同场景下使用不同的缓存模块EXPERIENCE OPTIMIZATION114缓存算法,这样可以极大的提高缓存命中率。在一些业务特定场景上 SDK 的缓存命中率能够达到 80%左右,随着缓存命中率的提升,带来的带宽成本节省收益也越大。图片下载到客户端上后都是未经过解码前的数据,想要把图片正确展示给用户,就必须对它进行解码。图片解码上支持通过 iOS 原生系统的解码框架 ImageIO 进行解码,即苹果原生能支持的格式,SDK 也能支持。除此之外,像 WebP、AVIF、VVIC(字节基于 BVC 算法自研的图片格式)等原生不支持的图片格式,SDK 通过自研解码器或者开源解码器的支持,也都能解码这些格式的图片。当有新格式的图片要支持时,只需实现对应格式的动静图协议就能以插件化的形式集成进 SDK,达到支持新格式图片的目的。HEIF 这种高压缩率格式的图片在字节跳动公司内部的应用已经比较成熟了。带宽节省方面,相比 WebP,在同质量下还能再节约 30%的带宽成本,为公司节省了大量的带宽成本。加载优化方面,HEIF 支持渐进式加载,可以先加载 HEIF 缩略图,再加载 HEIF 原图,在网络质量不好的场景下也能有不错的图片加载体验。SDK 有了公司内部自研的高性能 HEIF 软件解码库的支持,让 HEIF 格式图片的解码支持摆脱了 iOS 系统的限制,不再局限在 iOS 11 及以上才能使用 HEIF 静图,iOS 13 及以上才能使用 HEIF 动图,在低版本 iOS 上也能支持 HEIF 动静图,极大的提升了 HEIF 的应用范围,收获了大量的带宽成本节省收益。解码模块SDK 特色能力:iOS 全系统支持 HEIF在图片加载完后,业务也可以根据需要再次对图片进行各种实时转换,比如说加圆角、超分等,这些都是通过图片后处理来完成。下面介绍下 SDK 的一个特色能力:超分。SDK 特色能力:超分超分,即超分辨率,指的是基于机器学习/深度学习方法,从给定的低分辨率图片中恢复高分辨率的图片,借助图片后处理,可以在移动端上做到图片实时超分。一般可以用于两种场景,一是用于提升用户体验,当原图片分辨率低、清晰度低时,对其进行超分后,可以用来提升清晰度,以达到提升用户观看体验的目的;二是用于降档超分,用户在请求高分辨率的图片时,可以在传输过程中降低图片的分辨率,然后在客户端上进行超分,提升到原请求的分辨率,以达到节省带宽成本的目的。图片后处理模块SDK 包含了三大日志模块,图片性能日志、用户感知日志,大图监控日志,为业务的运营及产品的体验提升提供了全面的数据支持。配合火山引擎 veImageX 的控制台,可以实时查看各项可视化大盘数据,全方位的监控图片的各项指标。日志上报模块体验优化115SDK 致力于极致的图片加载用户体验,为此,SDK 做了很多相关性能优化,下面主要介绍下 SDK 如何提升图片加载体验、降低内存占用、优化动图播放。图片加载的快慢直接影响到用户的使用体验,高效的图片加载是 SDK 不可或缺的能力。渐进式加载加载静图大图,或者加载多帧数动图,亦或者在弱网场景下,都可以开启图片渐进式加载来提升图片的加载体验。SDK 支持传统的 PNG、JPEG 静图渐进式加载,也支持 HEIF 静图渐进式加载,先加载 HEIF 缩略图,再加载 HEIF 原图。SDK 同时也支持动图的渐进式加载,动图可以边下载边播放,在正常网络下,可以提高首帧的加载速度,在弱网下,类似于视频播放的缓冲机制,也可以提升动图的播放体验。演进:性能优化提升图片加载体验通常情况下,App 内图片的场景还是很多的,当加载大量图片时,图片所占的内存可能会很大,如果内存占用过高,会带来 OOM 问题,给用户的感受跟 Crash 一样,都是应用突然闪退。SDK 有如下的几种方案来降低图片内存占用:释放内存缓存当系统内存紧张,收到内存不足通知时,缓存模块会及时释放内存缓存,同时也提供接口,由业务在适当时机主动释放内存缓存。全局图片降采样图片在内存中的占用大小可以简单用如下公式来估算:memoryCost(单位:字节)=imageWidth(单位:像素)*imageHeight(单位:像素)*4由公式可以看出,如果想要降低内存,那么就要想办法在不影响功能和体验的前提下尽量降低图片的宽高,由此,当不能明确下载后的图片大小是否会远大于需要展示的 ImageView 的大小时,可以使用全局图片降采样功能。全局图片降采样分为以尺寸大小限制进行降采样和以内存大小限制进行降采样。以尺寸大小限制进行降采样:如果当前图片的长宽都大于降采样的长宽,那么把原图片长宽等比例缩放到恰好能贴到降采样尺寸的轮廓优雅的内存控制其中,图片性能日志包括了图片 URL、下载耗时、解码耗时、错误码、图片来源等数据,用来监控图片各项性能指标;用户感知日志包括了图片 URL、ImageView 的 Size、ImageView 展示图片耗时等数据,用来监控用户体验各项指标;大图监控日志则包含了大图 URL、内存占用大小、图片文件体积、图片分辨率大小等数据,可以全面的监控异常大图情况。Force Decode在图片解码方面,SDK 支持 Force Decode,能够提前把 Bitmap Buffer 转移到渲染进程,减少了未来渲染时再去拷贝的耗时,如果原始解码出来的 Bitmap Buffer,iOS 硬件屏幕不直接支持,会提前转换好,避免渲染时在主线程的转换开销,提高图片的加载帧率。EXPERIENCE OPTIMIZATION116以内存大小限制进行降采样:如果当前图片的内存占用超过内存限制,那么把原图片长宽等比例缩放到恰好低于内存限额 禁止图片渲染每次需要渲染前,都会给业务回调当前图片的元信息,例如图片的长宽尺寸、动图的帧数、以及预估的内存消耗量,业务可以根据此信息来禁止不符合预期的超大图渲染。大图监控实际业务场景中,待展示图片的分辨率和帧数都是未知的。在一些极端情况下(线上真实案例),某个动图分辨率是 1080p、帧数上百帧,是用户录屏生成的,是个超大的动图,解码后有超过 1 个 GB 的内存占用,在一些低端机上就直接 OOM 了。对于这类 OOM 情况,很难根据常规方法排查。那怎么有效监控这种不符合预期的线上大图呢,SDK 通过图片展示尺寸,图片解码后内存占用大小和图片文件体积这三个维度来定义一个大图,当一张图片触发这三个维度中任意一个维度的阈值限制时,就会被记录到大图监控日志内,这些数据后续会被上报。业务通过 veImageX 控制台就可以看到大图监控这个指标下的详细数据,当发现内存占用大小这个值异常大后,就可以及时查到相应的图片 URL,然后结合实际业务场景,及时下线这种不符合预期的超大图,降低线上 OOM 率。动图在业务上也是一个常见应用场景,如果能做好动图的优化,也可以带来用户体验的提升。动图在播放时,会不业内虽然已经有很多很成熟的图片加载 SDK 了,但要契合公司自己业务发展的 SDK 也很重要,图片加载 SDK 作为 veImageX 整体产品端到端不可或缺的一环,也是在这种背景下应运而生了。除了一些性能优化外,在成本节省上,HEIF 格式的应用为公司节省了大量带宽成本,收益非常可观,并且也在持续尝试新的压缩率更高的图片格式,例如 VVIC。在前沿能力应用上,随着图片超分算法的不断迭代优化,相信在未来也能带来不错的体验上的提升和成本上的节省。动图播放的优化写在最后断解码每一帧图片,这时会大量消耗 CPU 资源,SDK 内部会计算当前可用的内存以及渲染动图的所有帧需要的内存,如果当前可用内存满足渲染动图所有帧需要的内存时,SDK 会缓存动图的所有帧,以此来节省 CPU 资源,如果当前可用内存不满足渲染动图所有帧需要的内存时,SDK 会在每一帧图片播放结束之后舍弃前一帧,也就是不断重复渲染下一帧图片,通过消耗 CPU 资源节约内存,达到 CPU 消耗与内存节省的一个平衡。体验优化117RTC 端到端视频体验优化技术实践与探索RTC 是一个“发布-订阅”系统,我们在发布端和订阅端做的很多关于画质、性能、卡顿、延时的优化,在经过网络传输之后,不一定能够达到端到端的最优效果。本文介绍 RTC 如何通过发布端和接收端的联动优化,为用户提供更佳的视频通话体验。这是一个多人 RTC 系统的示意图,左边是发布端 Pub(Publisher),右边是接收端 Sub(Subscriber),把视频流从发布端通过一连串的媒体级联服务器送到接收端,就是“发布接收”的整体链路。在这条链路上,我们可以有效利用一些信息来帮助 RTC 系统做端到端优化,比如把接收端的信息送回发布端做优化。上图是一个比较常见的端到端优化的例子上下行带宽联动探测。发布端上行带宽有 1 Mbps,接收端下行带宽只有 0.5 Mbps,如果发布端和接收端不做“沟通”,发布端就会按照它的带宽探测 1 Mbps 发流,造成的结果就是下行带宽不够了,接收端收不了,延时不断增加,当增加到一定程度的时候,Buffer 清空重新发 I 帧造成大卡顿,用户的感受就是突然一个画面闪过去,中间一段内容都看不到了。当前市面上 99%的 RTC 厂商都是基于 WebRTC 来开发自己的 RTC 系统,WebRTC 系统支持 RTCP(RTP 的传输控制协议,专门用来传输控制信号),通过 RTCP 协议,我们可以把接收端探测到的网络状况,包括接收端网络的抖动信息、延时信息等回传给发送端,让发送端知道现在接收端的网络状况怎么样。由于 WebRTC 是一个点对点的系统,既然可以通过媒体级联服务器传递音视频数据,也能够使用同样的链路传递其他信息。通过 RTCP 传回的接收端带宽信息,发布端就会“知道”虽然自己有 1 Mbps 的带宽,但考虑到接收端的情况,用 0.5 Mbps 来发流更合理。以上是最常见的一个上下行带宽联动应用的例子。传统 RTC 上下行联动优化技术带宽探测摘要EXPERIENCE OPTIMIZATION118RTC 系统中的这些“通道”以及通过这些通道传递的“信息”可以被应用来做一些上下行的联动优化,解决一些 RTC 深水区的问题。由于不同应用会使用不同的“信息”和不同的“通道”,我们先归纳一下发布端和接收端的特点,看看哪些是发布端有、接收端没有的,或者哪些是接收端有、发布端没有的“独有信息”。先看发布端。发布端的特点之一是它有“视频源”,即采集或美颜后未受压缩损坏的视频源。RTC 系统中间是网络传输,网络传输的时候不可避免会碰到一些带宽波动,比如弱网、丢包、抖动等情况,为了确保把内容传输出去,发布端势必要做压缩,有压缩就会有损伤,所以接收端永远拿不到损伤前的“源”,只有在发布端才有“源”。如果我们要做质量评估,想知道 RTC 里画质好不好,只有在发布端做才更准确因为只有在有“源”的情况下,我们才能客观评价接收到的内容跟“源”有多少差距。发布端还有一个特点,就是 1 条流只有 1 个发布端,但可能有多个接收端。如果我们需要在 RTC 系统里做 1 个任务,特别是在多人通话场景下,一定会选择在发布端做,因为只要做 1 次就够了。比如在下文智能场景识别/内容识别的例子中,我们需要做一些视频内容的分析识别任务,假设 1 条流有 10 个接收端,如果在接收端做识别就需要做 10 遍重复的事,不如在发布端做 1 次识别,然后把这个信息传递给接收端来得高效。接收端的特点是它能拿到所有网络相关的信息,常见的有丢包、抖动、延时等状态信息,它还“知道”收到了哪些帧,丢了哪些帧,而发布端只“知道”它发出了哪些帧。说完了发布端和接收端的特点,我们再来看看有哪些“通道”可以传输这些信息。上文中已提到,WebRTC 已经可以实现利用标准的“沟通”通道 RTCP 把接收端的网络状态信息回传给发布端。视频的压缩码流标准定义了一个叫 SEI 的 协议,SEI 里面可以带一些 meta data,可以通过它来携带一些个性化的内容信息。SEI 的好处是它可以做到“帧”级别的对齐,RTCP 无法保证什么时候到达,无法精准地控制在某一视频帧做什么事情,但是 SEI 可以,SEI 的劣势是它只能“单向沟通”,只能从“发布端”传到“接收端”。真端到端上下行联动优化实践体验优化119同样方向的流还有 RTP,RTP 是 WebRTC 的标准传输协议,它提供扩展头(Header Extension)功能,我们可以自定义地去扩展一些头部,在 RTP 数据包头中附加一些需要的信息传输。以上 RTCP、SEI、RTP 走的都是 UDP 协议,所以它们有可能会丢。RTC 系统里也有一些“不会丢”的沟通通道,比如 data channel(它在 UDP 协议里做了一些可靠传输机制),还有基于 TCP 传输的信令,这两个都不会丢。不过,“不会丢”并不表示它就是好的,一般来说,“不会丢”表示丢了以后会重传,所以相对来说比较慢。有了这些总结归纳后,下面通过三个故事来介绍我们如何使用这些信息和通道来做上下行联动优化,解决弱网、丢包、4K 屏幕分享卡顿等问题。这三个小故事的基本叙事逻辑是一致的走的是什么通道?传的是什么信息?解决的是什么问题?第一个故事是关于超分辨率。超分辨率是一个比较古老的图像处理问题,它的本质是把低分辨率的图像放大到高分辨率,并想办法恢复或重建图像中的一些细节。由于网络带宽等限制,视频在压缩时无可避免地会受到一些损坏,超分可以做一个“修复者”的工作,它最合适的位置是在接收端。超分在 RTC 中的作用很大,它解决的问题是在系统资源有“限制”的情况下,视频质量被损坏,它能够部分恢复视频的质量(不是完全恢复)。“限制”包含了带宽限制和系统性能限制,比如在网络带宽非常低的时候,假设只有 200Kbps,我们需要要传一个 720P 分辨率的视频,这时传输的视频质量就会非常差,在这种情况下,我们不如先把它先缩小(比如先下采样到 360P),用好一点的质量把小分辨率先传出去,再在接收端用超分把画质还原回来。还有比如一些低端机发不出 720P 的视频,一发就卡顿,我们就可以先降低分辨率发出去,再通过超分把它修复回来。超分辨率的性能迭代优化框架EXPERIENCE OPTIMIZATION120超分在 RTC 中应用会遇到一些挑战。首先是计算复杂度的问题,超分不是简单的上采样,目前学术界的方式都是用深度学习卷积神经网络去训练超分模型,不可避免地,这是一个计算量非常大的操作,计算量大会限制超分的分辨率和运行设备,比如限制在比较低的分辨率,或者一些超分模型只能限制在一些高端机上使用,低端机上跑不动。其次是所有类似的后处理技术都会面临的一个问题:如何衡量超分做得好不好?线上打开超分后,我们非常需要知道,超分到底让画质增加了多少?新的模型在线上是不是比旧的模型要好?这些数据不仅对线上运营有帮助,对之后的算法模型迭代也有帮助。另外,由于深度学习并不是我们设计的一个我们能够理解的算法,它也有可能会造成“损坏”,比如损坏一些暗场景增强、一些美颜特效的效果。“衡量效果”是一个比较大的难题,因为我们只知道它在线下训练模型的测试组里面跑得好不好,无法知道这个模型在线上跑的效果好不好。这两个挑战是我们在 RTC 中应用超分时遇到的比较实际的问题。体验优化121在讨论如何解决这两个问题之前,我们先了解一下 RTC 系统中实现视频超分的卷积神经网络使用 Resnet 的残差神经网络。Resnet 网络可以有很多层,甚至可能高达一百五十几层,但因为要跑在客户端上,所以我们使用了一个非常小的神经网络,我们使用的这个网络有 6 层,但即使是这样,它的复杂度也远比做一些线性的上采样要高。和 Bicubic(OpenCV 常用的一种上采样方法)相比,当我们把视频从 270P 超分到 360P,基本可以达到 0.5dB 左右的视频修复能力。0.5dB 是什么概念?1.5dB 大概是 H.264 和 H.265 两代视频压缩标准之间相差的压缩收益,0.5dB 是它的 1/3。也就是说,在什么事情都不做、所有网络传输条件都一样的情况下,通过超分就可以平白让视频质量增加 0.5dB,这是很高的收益。我们怎么用“收发联动端到端优化”这个思路解决超分“复杂度高”和“结果难衡量”的问题?刚才我们说过,因为只有发送端有“视频源”,如果要做质量评估,只有在发送端做才是最直接、最准确的,所以我们的解法很简单,就是把超分搬到发布端去做质量评估,计算出超分能够在接收端恢复多少质量。通过这个方式,我们可以对每一个超分迭代模型在线上的表现进行评价。大家可能会认为这么做的复杂度很高,不建议这么做,但实际上,我们在线上只会放比如 2%的量来做评价,再利用大数据来了解这个模型在线上的表现,了解这个模型在线上到底跑得好不好,第二代模型有没有比第一代模型好。然后,我们用 SEI 把“超分收益好不好、值不值得做”的评估结果传递给接收端。这样做有什么好处?因为超分是在恢复带宽造成的质量“损伤”,但 RTC 系统弱网情况大概只占 20%,也就是说,80%的情况都是好网,并不会造成视频的损伤,如果我们打开了超分,它不管网络好坏照样跑,把绝大部分计算量资源跑去恢复一个并没有什么损伤的视频是资源的浪费。所以,当发布端已经知道超分在这一系列帧到底有多少恢复量的时候,如果恢复不多(比如网络很好没有什么压缩破坏,或者这帧视频非常简单,低带宽就可以压缩得很好),它就可以直接告诉接收端“现在不值得做超分,把超分关了”,这样我们就可以把复杂度投入在它产出最高画质、修复最高的那一段视频帧里,降低计算的复杂度。EXPERIENCE OPTIMIZATION122经过端到端优化后的超分技术在抖音直播连麦场景帮我们节省了很多计算量。抖音直播连麦在实际应用时,如果处于弱网条件下,我们的做法是先下采样到 270P,再通过超分把它还原到 360P。由于 52%的网络情况是带宽大于 500Kbps,网络传输并不会给视频带来额外的质量损伤,这时候用超分做修复的收益是很低的,可以忽略的。所以,针对带宽大于 500Kbps 的场景,我们告诉接收端“不用开启超分”;针对带宽小于 500Kbps 的场景,我们则告诉接收端“开启超分”。发布端通过 SEI 把决策传递给接收端,接收端开启“Adaptive Switch”,动态地开关超分这个功能。通过这个动态的开关,CPU 计算量增量从 4.8%降到 2.5%,内存的增量也可以几乎减少一半,从 35MB 到 18MB,但整体的质量修复并没有明显的减少,证明了我们其实是把计算量放在了真正有修复能力的这段视频帧上。智能内容模式的下行延时优化体验优化123第二个故事是关于屏幕分享的。屏幕分享是视频会议的一个常用功能,它在视频会议里的使用率比开视频还要高。大家在使用屏幕分享时可能会遇到这种情况:在讲 PPT 时突然播一段视频,视频会变得很卡,帧率很低。有一些视频会议厂商针对这种情况支持提供一个模式,叫“流畅模式”,如果播放视频卡,勾一下“流畅模式”,视频就流畅了;下一页 PPT 又变成了文字,我们又发现文字变模糊了,然后厂商会说,这时候应该选择“清晰模式”,它就会变清晰了。这种做法给用户的体验非常差,用户很容易忘记,切来切去也很麻烦。这个问题的本质在于,屏幕分享的 PPT 和视频是两种截然不同特性的内容,它们具备完全不同的视频参数和弱网对抗策略参数:在共享 PPT(或文档)的时候,我们的要求是越清晰越好,也就是说,它对分辨率的要求很高,但帧率可以很低,一般我们在分享文档的时候,如果是 4K,其实只要每秒 1 帧就够了,大家会看着就会觉得非常舒适,很清楚;在共享视频的时候(比如电影),它对帧率的要求很高,但分辨率可以很低,比如一般的视频可能 720P 就够了,但帧率需要 30FPS。这是在视频参数上的不同,在弱网情况下,这两种内容也有非常不一样的弱网对抗策略:PPT(或文档)需要非常低的延时,特别是投屏场景,大家一定希望电脑换页的时候投屏也马上换页,但它可以忍受非常高的卡顿,两帧之间可以忍受 500ms 的间隔,甚至很多时候每 2 秒 1 帧用户也不会感受到它有没有卡;视频则是完全相反的,视频需要非常高的流畅性和非常低的卡顿,但是它可以容忍比较高的延时,大家其实并不太在意他看到的视频和演讲人分享的视频差了 2 秒钟,只要视频本身是流畅的就可以,但一旦两帧之间有有卡顿的情况,大家就会觉得很不舒服。EXPERIENCE OPTIMIZATION124在实际情况中,分享的内容是视频还是 PPT 是会动态变化的,用这种“屏幕分享前勾选“清晰模式”或“流畅模式”,勾选后就不动”的做法不太行得通,我们需要一个实时的、能够动态去分辨分享内容类型的机制我们叫内容检测,去分辨当前分享的视频帧到底是 PPT 还是视频,然后通过这个信息在发布端做一些策略联动,比如分享 PPT 需要 4K 的分辨率,发布端就可以通知采集来提升分辨率。同时,编码器也可以针对不同的视频内容做不同的参数调整。举几个比较常见的例子,在 H.264 年代有一个非常有名的开源编码器叫 X264 直播,虽然那时还没有“屏幕分享”,但已经有“动画模式 Animation”,如果你告诉它现在在编码的是一个动画,它就可以通过参数调整把压缩率提高 30%。在 H.265 年代,视频标准里面直接写入了 SCC(Screen Content Coding),这是一种针对文字的编码模式,它里面用的 Hash ME 可以针对屏幕内容去做压缩,将压缩率提升 40%,也就是说,如果你告诉编码器它编码的内容是什么,它就可以降低 40%的带宽。同样地,如果你告诉 Pacer(Pacer 是发布端的一个网络控制模块,它可以决定冗余控制,FEC、重传控制的响应)现在共享的是什么类型的内容,它也可以去控制屏幕内容和视频内容的延时。当然,这里最关键的是发布端要怎么把内容检测的结果传给接收端。接收端里的 Jitter Buffer 是整个 RTC 系统里控制延时和卡顿 Trade Off 的关键模块,它可以决定系统的延时是多少,而延时则会直接决定卡顿程度。一个简单的概念,如果愿意使用延时很大的策略,换来的就是系统卡顿减少,类似地,像分享视频这种场景对卡顿的要求很高,就可以选择一定程度的“牺牲延时”。目前,我们使用 RTP 扩展头的方式把内容检测的结果传递给接收端,传递给 Jitter Buffer,由 Jitter Buffer 来决定“延时”和“卡顿”的偏好。体验优化125我们看一下这个策略为“飞书屏幕分享”带来的收益。在体验方面,如果用户分享的是 PPT,屏幕可以直接从 1080P 提升到 4K,帧率从 15FPS 降到 5FPS,如果用户分享的是视频,帧率可以从 15FPS 提升到 30FPS。另外,通过收发联动优化,Jitter Buffer 收到了内容检测信息以后,可以针对 PPT 限制它的 Max Jitter Delay,同时关闭 AV 同步,这样做以后,整体分享文档的延时可以从 400ms 降低到 240ms。第三个故事是关于智能参考帧的一些实践。智能参考帧技术解决了 RTC 的一个深水区问题大卡顿(我们一般定义两帧间隔超过 2s 以上的叫做大卡)。一个丢包造成的弱网很容易导致卡死的情况(Frozen Frames),它是怎么造成的?举个简单的例子,一般情况下,如果丢包了,短时间之内接收端会请求重传,让发送端再传一次(视频参考帧是有依赖关系的,这一帧其实依赖前一帧,下一帧就依赖这一帧),如果发送端能够重传过来,接收端能够补上这一帧,后面就都可以顺利地解码和输出。但如果重传失败,时间到一定的长度,接收端就会直接请求一个 PLI(Package Loss Indication),它会触发发布端开始发送 I 帧,I 帧就是关键帧,它不依赖任何其他帧,所以它特别大,在丢包网络中,越大的帧越容易丢包,越丢包它越传不到,越传不到越请求它,它就越编一个更大的帧给接收端,然后越接收不到,如此便会造成大卡顿的恶性循环。大家可能会想到,把 I 帧编小一点是不是就解决问题了。这里给大家一个数字,I 帧跟 P 帧大概是 3-5 倍的大小差,也就是说,I 帧约是 P 帧的 5 倍大。如果把它限制在 2 倍大,让它好传一点,它的质量就会特别差。大家在开视频会议的时候,如果发现每 2 秒画面就会闪一下,这种间隔的闪动叫呼吸效应,它表示你看到 I 帧了。为了把 I 帧缩小,I 帧就会很模糊,它的质量和前后帧会很不一样。这并不是我们想要的结果。智能参考帧的极致弱网延时体验优化EXPERIENCE OPTIMIZATION126智能参考帧提供的方案很简单,它在接收端跟发布端维持了一套一模一样的参考帧关系。这样做的好处是,当系统进入大卡时,发布端其实知道接收端手上有什么已经成功解码的关键帧,所以它可以发布一个接收端已经有的参考帧,而不是重新发 I 帧,这个技术叫做 LTR(Long Term Reference),它的原理是,不管什么时候向发布端请求,因为发布端“知道”接收端已经完整收到了某些帧(这些帧可以当参考),它就发一个接收端手上已有的参考帧。它改变了原来固定的参考帧关系,变成“我知道你有什么,让你去参考你自己有的东西,这样你永远可以解码”。其次,它可以解决带宽浪费的问题,原来接收端请求一个关键帧,需要清空 Buffer;现在发布端发送的任何东西,除非被网络丢包了,只要接收端可以收,它就可以解码。这一点很重要,尤其是在丢包网络的情况下,这么做可以避免带宽浪费。体验优化127智能参考帧的关键是在发布端和接收端维护一样的参考帧关系,即,接收端需要把它的参考帧关系通过编一个很精炼的信息来传递给发布端。通过在 RTCP 加入 ACK(Acknowledgement),接收端告诉发布端它已经收到并完整解码了哪些帧,这些帧可以进入参考帧关系结构,一旦发生弱网,接收端就告诉发布端取消 PLI,不再请求 I 帧,而是请求 LTR,避免弱网情况下发 I 帧导致弱网情况更恶化、甚至导致卡死的状况。智能参考帧技术在一些对卡顿、延时比较敏感的场景中对提升用户体验有很大帮助,比如在抖音好友通话场景中,通过智能参考帧,“大卡”比例下降了 14%(两秒钟不出帧的“大卡”比“小卡”对用户体验的影响要大很多),而在一般的卡顿指标上,200ms 卡顿和 500ms 卡顿分别下降了 2.6%和 0.7%。另外,智能参考帧在很大程度上也解决了延时的问题。刚才有提到,智能参考帧只要收到就能解码,而不需要通过重传,因此在智能参考帧中大部分重传是可以被关掉的,关掉后延时可以降低 11%,也就是说,200ms 的传输可以减少 20ms,端到端延时 200ms 的达标率可以提升 16%。以上三个故事就是利用收发联动优化的技术解决视频参数上升、带宽限制下的视频修复、弱网丢包、延时、“大卡”体验的问题,未来我们还可以做哪些优化呢?视频端到端优化技术的未来展望EXPERIENCE OPTIMIZATION128在超分辨率上,除了告诉接收端它可以开关超分,针对线上不同的机型,我们还可以推荐它使用不同的模型,比如高端一点的机型可以使用复杂一点、强一点的模型,我们可以告诉接收端哪个模型最适合它,哪个模型的“性价比”更高。另外,发布端其实是可以知道接收端有没有超分的能力,如果知道接收端有超分的能力,那么在碰到弱网的时候,发布端可以更进一步地去主动降低分辨率。现在的做法虽然也可以主动降低分辨率,但做得不够激进,因为发布端并不“确定”接收端能不能开启超分。如果发布端“确定”接收端可以开启超分,那么,也许本来是在 200K 的带宽才降低分辨率,现在甚至可以在 300K 的带宽下就降低分辨率因为降低分辨率后之后再进行画质修复的效果,会比不降分辨率直接传输的效果更好。这就是所谓的 SR-aware 参数选择。在内容检测上,我们也可以扩展一下,目前内容检测的结果是非黑即白的,即,内容的分类不是 PPT 就是视频,未来它会向更精细的视频分析方向演进,比如检测视频内容是运动的还是偏静止的,是复杂的运动还是简单的运动(比如是有人在跳舞健身,还是只是一个主播在播新闻)。视频和 PPT 是两个非常极端的场景,中间频谱上还可以细分很多档位,每一个档位都可以有不同的视频参数以及弱网对抗的策略(比如运动的内容可能需要 60FPS,但是一个静态的主播可能只需要 15FPS)。未来,内容检测可以告诉我们这个视频的复杂程度、或运动的程度是怎么样,而不只是简单告诉我们它是文字还是视频。在智能参考帧上,智能参考帧技术和编解码器有强绑定的关系,目前支持智能参考帧的硬件编码器非常少,基本只支持 Nvidia 和 Intel 这类比较常见的硬件,iOS 跟 Android 大部分没有硬件编码器支持,这会把智能参考帧的性能限制在软件编码器中,而用软编实现的方案会限制智能参考帧只能应用在一些分辨率较低的场景。未来,智能参考帧技术还将往移动端硬件方向进一步发展,研究让更多的硬件编码器来支持这个技术,拓展更多高分辨率的应用场景。未来,RTC 的问题会越来越破碎化,特别是当我们进入深水区以后。上下行联动优化是一种方式,希望以上这些分享可以帮助大家在一堆混乱的麻绪之中理出一些思路,来思考或解决一些问题。体验优化129从短视频到直播电商,到现在短剧的兴起,人们生活中已经离不开各种不同形式的视频内容。一份第三方研究报告显示,2022年中国 Top100 应用中,搭载视频类功能(包括点播、直播和实时音视频三类)的应用比例高达 69%。视频类应用的消费时长占移动互联网应用的比例也呈现上升态势。而越来越多的行业开始引入视频帮助其进行业务创新。与此同时,视频类应用也开始加速渗透到企业的日常经营活动中。全面视频化的趋势正在重塑空间体验、知识传递、直播电商、商业连接等领域的体验。整个2022年,中国的直播带货规模约为3.5万亿元,已经占到整个网上零售额的25.4%,市场预测这个占比在未来会持续增加。同样在 C 端,随着 AR/VR 设备的全球出货量在近几年快速增加,空间体验的重塑为视频的沉浸式体验带来了更多的想象空间,2027 年 AR/VR 市场的复合增长率预计将达到 32.6%。而在ToB市场,音视频能力几乎成为办公协同工具必备的基础能力,中国的云视频会议市场在2021年的37亿基础上持续增长,到 2022 年已达到 42 亿。由于音视频能力的成熟,近年来素质教育、职业教育以及教育数字基建等领域萌发了大量创新的线上场景,推动了知识传递方式的突破。视频类功能成为所有产品“基建”的时候,也意味着它度过了野蛮生长的阶段而不再是一个全新的事物了。观众的胃口越来越刁,对视频内容的要求也从从无到有的阶段,到现在延伸到对画面质量、延迟等更细节的素质追求,以至于一种更全面的对于观看体验的追求。迅速拉高的体验阈值视频时代需要一个新的“体验增长论”了摘要EXPERIENCE OPTIMIZATION130从短视频到直播电商,到现在短剧的兴起,人们生活中已经离不开各种不同形式的视频内容。一份第三方研究报告显示,2022 年中国 Top100 应用中,搭载视频类功能(包括点播、直播和实时音视频三类)的应用比例高达 69%。视频类应用的消费时长占移动互联网应用的比例也呈现上升态势。而越来越多的行业开始引入视频帮助其进行业务创新。与此同时,视频类应用也开始加速渗透到企业的日常经营活动中。全面视频化的趋势正在重塑空间体验、知识传递、直播电商、商业连接等领域的体验。整个 2022 年,中国的直播带货规模约为 3.5 万亿元,已经占到整个网上零售额的 25.4%,市场预测这个占比在未来会持续增加。同样在 C 端,随着 AR/VR 设备的全球出货量在近几年快速增加,空间体验的重塑为视频的沉浸式体验带来了更多的想象空间,2027 年 AR/VR 市场的复合增长率预计将达到 32.6%。而在 ToB 市场,音视频能力几乎成为办公协同工具必备的基础能力,中国的云视频会议市场在 2021 年的 37 亿基础上持续增长,到 2022 年已达到 42 亿。由于音视频能力的成熟,近年来素质教育、职业教育以及教育数字基建等领域萌发了大量创新的线上场景,推动了知识传递方式的突破。视频类功能成为所有产品“基建”的时候,也意味着它度过了野蛮生长的阶段而不再是一个全新的事物了。观众的胃口越来越刁,对视频内容的要求也从从无到有的阶段,到现在延伸到对画面质量、延迟等更细节的素质追求,以至于一种更全面的对于观看体验的追求。图源:ArchDaily迅速拉高的体验阈值体验优化131经过几年沉淀,火山引擎视频云的一支团队开始试图将抖音集团视频产品体系的内部经验转换成一条“最优”路线。他们首先想要回答一个问题:用户体验差距导致了用户增长的差距,要如何衡量体验?随着视频化应用的深入,有大量客户开始找到火山引擎视频云,希望进一步提升用户的体验。客户了解产品和技术,但却没有一套明确的标准和衡量体系来指路。火山引擎内部在服务抖音业务时总结了很多策略优化方案,覆盖涉及上传、存储、媒资处理、分发、播放多个环节,但客户能够合理用上这些策略的前提是他们对如何衡量自己用户的体验有足够准确的认识。出于这样的想法,火山引擎音视频测评实验室找到播放器团队,决定一起推演出一个通用而有延展性的,关于音视频体验的体验评估模型,来为包括抖音在内的所有音视频产品建立一个产品方法论。“这是一次业务专家能力的自动化”,火山引擎音视频评测实验室音视频体验专家说。而在模型建立之前,首先需要形成一个衡量的指标体系,来为视频产品的体验评估找到一套稳固的观察方法。这件事火山引擎从 2021 年就开始做了。自 2021 年起,火山引擎开始体系性的量化每一项体验指标优化带来的业务收益,最终构建了一个标准透明、度量准确、归因全面、验证可靠的 QoS 指标体系。要跟上这种变化,围绕视频的一切从内容到产品本身体验需要升级。现在的观众对于视频观看的容忍度已经回不到那个画面粗糙、音画不同步甚至播放会出现卡顿的时候,任何一点体验上的瑕疵都会导致观众被劝退。这种高门槛的视频能力需求,已经开始降为未来新的视频产品需要具备的基本素质。于是产品“视频化”的当下需要厘清一组体验、业务增长和成本之间的三元关系。用户音视频体验的变化会反映在业务增长的差异上,而体验与成本本身存在一定的矛盾关系。而如何在有限的资源条件下将用户体验最大化、取得三者间的最佳平衡,准确衡量音视频体验成为一个重要的前提。图源:火山引擎“体验增长论”需要一个模型EXPERIENCE OPTIMIZATION132这套音视频体验指标体系由音画质指标和流畅度这两个维度的 25 个指标组成。包含了视频从起播、播放中直到播放完成的整个完整周期。而在这套 QoS 指标体系背后,是在抖音上从播放时长、完播量、播放量、完播率到访问用户数等多维度的 400 余项 A/B 测试实验。这套衡量标准确立了之后,接下来的挑战变成了:如何定义体验与业务增长的关系?传统的数据分析方法是利用长期积累的线上业务数据进行统计和归纳,以得出当前业务指标的典型值。尽管这种方法在精密分析的基础上较为准确,但它需要大量人力和计算资源的投入,并且在不同产品和业务的复杂场景中的复用价值不高。尤其是新场景的出现,传统的数据分析方法很难有效的去适应。这次体验评估模型的构建仍然首先从抖音集团内部产品开始。2022 年团队先在内部走完了一个测试项目把与视频表现相关的一些核心因子抽出来,以 A/B 测试的方法来观察这些因子作为单一变量的情况下,对视频内容产出表现的变化。结果很有趣,也在团队的预想中。这场内部测试所反映出的迹象是,哪怕现在抖音的用户生态已经十分繁荣,但音视频体验上的“微弱”提升,仍然能兑换出新的增长空间。12 月 14 日,火山引擎视频云发布了音视频体验白皮书。火山引擎音视频测评实验室花了接近一年时间,尝试理清音视频场景中技术指标与用户体验复杂参数之间的关联,然后呈现在这份白皮书里。如何最有效率的提升音视频体验,有着巨大用户行为样本的抖音或许是最有发言权的。火山引擎视频云根据用户实践所给出的反馈,提出了音视频体验评估模型 MPEI(Multimedia Playback Experience Index)。音视频体验综合评估模型 MPEI 表示的是两个子体验模块沉浸体验质量 QImE、观看体验质量 QPE 之间的函数关系(MPEI=f(QImE,QPE))。QoS 指标体系被进一步细分成了 6 个维度。沉浸体验质量 QImE 的评估模型是码流质量 QP、画面质量 QV、音频质量 QA 这三个子模块的函数关系;观看体验质量 QPE 则是关于观看体验流畅性 QC、观看体验完整性 QI 以及交互体验质量 QInE 三者的评估模型。不同指标对体验的影响最终反映成 J、S、D三种不同的得分曲线。图源:火山引擎视频云音视频体验白皮书J 型极致优化曲线意味着随着单一因素的不断优化,产生的用户体验收益会一直显著提升;S 型拐点优化曲线意味着这种随着优化而改善的用户体验会有一个迅速兑现收益的阶段,随后边际效益逐渐降低;D 型离散优化线表示的那些不规则、离散的体验变化,常见于网络波动或播放场景跳变等情况。播放失败率就是典型的J 型曲线,即随着播放失败率的持续降低,用户体验会越来越好。画面分辨率则更贴近D型曲线,当分辨率到达一个足够高的临界点,这个要素本身就不再成为影响用户观看体验的因素。而更多的核心指标则偏向S 型曲线。比如首帧时间(起播速度)、交互流畅度以及画面质量。这意味火山引擎视频云在前两个问题的基础上,希望能够回答第三个问题:体验优化133在实际应用中,这一模型已经成功映射了用户体验的真实反馈。例如,我们观察到当视频的首帧加载时间持续降低时,用户体验在一个特定阶段内显著提升,但随后会进入一个较为稳定的满意阶段,表明进一步提升的效果变得不那么显著。这样的洞察能力帮助我们更精确地确认高 roi 的优化点,以最大化用户满意度。客户也就能依此在这条曲线上找到体验与成本的平衡点。图源:火山引擎视频云音视频体验白皮书有些客户因为音视频能力的需求找到火山引擎视频云,对于效果的要求也非常直接,“要达到抖音的音视频效果,”火山引擎音视频评测实验室音视频体验专家说。这直接切中了火山引擎视频云在音视频领域的特殊位置。火山引擎作为字节跳动旗下的云服务平台,长期服务抖音、西瓜视频等视频内容产品。而这些沉淀积累下来的,包括视频点播、直播、实时音视频、云游戏和云渲染等产品在内的可提供视频全链路技术服务的经验和解决方案,形成了这朵火山引擎视频云。现在火山引擎视频云已经服务了不同行业的近千家客户,不仅有得到、懂球帝、凯叔讲故事这样的互联网客户,也有九州、中文在线、掌阅短剧这样短剧的新场景客户。火山引擎视频云的特殊之处在于,它首先要支撑抖音,而后者甚至是音视频产品中最严苛的那个客户。许多新的客户为了抖音的高标准而来,对于视频云团队来说,这是挑战也是机遇。挑战在于,抖音的巨大影响力会变成非常大的优化压力,迫使火山引擎音视频团队在每一个指标分析都要做追求极致;而机遇则是,火山引擎视频云天生拥有这样一个足够有说服力的实验场。这套归因全面且验证可靠的 QoS 指标体系,首先基于抖音这个亿级日活用户实践,又因为足够巨大的用户体量,抖音可以成为 A/B 测试时一个巨大的效果放大器,一些比较细微的指标变化能够转化成相对明显的数据影响而被衡量。比如2022-2023的内部测验中,音视频团队将视频首帧加载耗时降低70毫秒,这一微弱的变动在巨大的用户样本中,变成了短视频内容上 0.6%的人均播放时长。模型背后的火山引擎视频云图源:火山引擎视频云音视频体验白皮书 体验与成本存在一定的矛盾关系,如何在有限的资源 条件下将用户体验最大化,取得两者间的最佳平衡?首先,并不是所有指标都同样重要,火山引擎音视频评测实验室音视频体验专家告诉硅星人。整个体验模型最初指标的选择是基于专家经验,然后以数据挖掘的结果为前者提供补充。而在最终模型出来后会对专家经验做二次验证。综合下来的结果表明,首帧未起播率等少数几个指标会对用户的体验造成很大的影响。同时,MPEI 模型的优势在于它的广泛适用性。无论是短视频、中等长度视频、长视频还是纯音频内容,它都能提供全面的体验诊断。更重要的是,随着新的业务场景不断出现,如短剧等,MPEI 也显示了出色的拟合和适应能力。EXPERIENCE OPTIMIZATION134另一方面,由于抖音用户群体的广度,一个要做视频产品的客户,他预想中的用户画像大概率能够被描述为抖音用户画像中的一个子集。这也为客户寻找适合自己的视频产品策略提供了方向和一些安全感,他要探索的新路很可能在抖音集团内部的视频内容产品身上已经有了一些成功经验。在用这个足够有说服力的体验模型给出了一套音视频体验的衡量标准之后,火山引擎视频云拿着这枚“指北针”,能够为所有与音视频相关的产品提供更好的解决方案。火山引擎音视频测评实验室负责人王飞用首帧未起播率这个指标的优化举了个例子。前面提到,通过体验模型的多轮验证发现,首帧未起播率是所有影响音视频体验中权重较大的指标之一。针对这个指标进行的测试结果显示,在短视频的场景中首帧优化到 100 毫秒后体验收益会大幅放缓。团队最终确定了该业务的短视频场景的起播耗时优化的预期目标和技术手段。项目中主要采用了预加载和预渲染等优化手段。其中预加载指将从网络下载视频的流程整体提前,从而保证在用户选择播放视频时直接从本地读取视频数据;而预渲染则是在实际播放之前,提前完成视频的解复用、解码和渲染等流程,从而在用户播放请求发起时能够快速进入播放状态。这一系列的优化中有一个明确的目标将首帧耗时从 170 毫秒优化至 100 毫秒。王飞和火山引擎视频云团队再次通过 A/B 实验进行验证并获得了更具体的体验变化:对于部分型号的 Android 手机,在将首帧耗时压进 100 毫秒之后,最终带来了约 0.6%人均观看时长提升的收益。“这次优化再次说明,通过模型分析可以快速找到优化点,进行针对性的指标优化后可以有效的提升用户播放体验,并最终带来显著的业务收益”,王飞表示。在抖音内部做了完整的验证后,这场关于首帧未起播率的试验最终变成“零耗时”首帧的解决方案向外推出,有了MPEI 模型这样一套方法论的指引,未来能够这样直接打到痛点上的音视频解决方案会越来越多。但更多新的音视频“痛点”,会伴随着直播电商、短剧甚至在 AIGC 技术加持下更新鲜的视频业态的出现而出现。甚至体验、业务增长和成本之间的平衡关系也会随着视频内容业态的起落而变化。这种情况下,MPEI 模型也需要不断迭代,而这基于越来越多在不同场景和业务上对音视频能力有诉求的行业客户向 MPEI 模型的靠拢。而经过了严苛的内部验证现在终于摆在众人面前的 MPEI 模型,站在了另一个起点上。随着与愈加丰富的客户和视频场景产生交集,它所承载的这套“体验增长论”,脉络会加速的清晰起来。这套归因全面且验证可靠的 QoS 指标体系,首先基于抖音这个亿级日活用户实践,又因为足够巨大的用户体量,抖音可以成为 A/B 测试时一个巨大的效果放大器,一些比较细微的指标变化能够转化成相对明显的数据影响而被衡量。比如2022-2023的内部测验中,音视频团队将视频首帧加载耗时降低70毫秒,这一微弱的变动在巨大的用户样本中,变成了短视频内容上 0.6%的人均播放时长。最佳实践135最佳实践04BEST PRACTICE最佳实践137抖音世界杯的画质优化实践解析卡塔尔世界杯已经结束,29 天赛程,64 场比赛,最终梅西带领阿根廷时隔三十六年再次捧杯。世界杯期间,抖音提供的稳定高质直播画面为观众带来了完美的观赛体验,决赛的 PCU 高达 3700W 。世界杯赛事涉及链路众多,如何保障各链路的画质稳定并进一步提升画质,是一个巨大的挑战。本文主要介绍火山引擎多媒体实验室在世界杯期间画质的相关工作。世界杯涉及链路较长,可简化为下图流程,FIFA 现场信号首先传到央视端进行合规安全处理,然后经过演播室的制作传输给 CDN 再进一步分发到用户侧。从画质角度来看整个链路可分为画质检测与画质优化两个部分,对于 CDN 之前的链路以画质监测为主,以发现问题/定位问题/推动对应链路人员解决问题为目的。画质优化在 CDN 和客户端两侧进行,下面的内容主要介绍画质优化部分。摘要BEST PRACTICE138本次世界杯直播使用支持 HDR(高动态范围)设备录制,团队对支持 HDR 的设备增加了 HDR 档位,同时提供了多种不同分辨率/帧率的档位。为了使得观众获得更好的画质体验,团队通过自研的自适应 ToneMapping,视频降噪,ROI,端上超分等算法有效地提升了赛事画质。卡塔尔世界杯采用 HDR 拍摄方式,HDR 拍摄的片源拥有更广的色域,更大的动态范围。但对很多终端显示设备而言,并不支持 HDR 信号播放,所以通过 ToneMapping 算法将 HDR 信号转换为 SDR(标准动态范围)信号是十分必要的。相比 SDR 信号,HDR 信号拥有更广的色域和更大的动态范围,在转换到 SDR 信号的过程中不可避免会产生一些信息损失。常用的一些 ToneMapping 方法,不论是 Reinhard,Filmic 或者 Hable,其本质都是设计固定的映射曲线实现从 HDR 到 SDR 的转换,同时尽量保持对 HDR 效果的还原。但对于世界杯等大型赛事,现场动态范围跨度极大,场馆的灯光/草地/球员亮度差异明显,观众感兴趣的球员信息实际集中在暗部区域,这就导致 ToneMapping 之后的 SDR 信号过暗的问题,为了解决这一问题,团队提出了内容自适应 ToneMapping 算法,通过统计视频内容的实际光照情况动态地进行 ToneMapping,从而得到更优效果。左:Hable 算法,右:内容自适应 ToneMapping最佳实践139注:红色框内表示 ROI 区域,左边为通用方案结果,右边为优化结果为了兼顾视频码率和主观画质,团队使用了基于 LSTM(长短期记忆网络)的时域 ROI 技术,通过人眼显著性区域检测和编码相结合的方式,让码率在画面上的分配更加合理。目前市面上没有专门针对足球场景的 saliency(显著性物体检测)数据集,通用的 saliency 数据集在世界杯这类特定场景中表现并不理想。针对这一问题,团队专门制作了足球场景的 saliency 数据集,通过眼动仪追踪球迷观看球赛时的关注区域得到足球比赛的专用 saliency 数据集,从而极大增加了模型的准确性。针对足球场景中显著性物体较多,显著性区域分散的特点,团队对检测模型进行了专门的优化,在保证检测速度的前提下,提高了模型的召回率和不同场景的鲁棒性,从而实现更优的主观质量。BEST PRACTICE140左:视频降噪前,右:视频降噪后同时团队使用了视频降噪算法,根据视频信息对其进行空域、时域噪声的去除,将带有噪声的视频处理成干净、没有噪声的视频。由于去除了视频的噪声,在提升视频质量的基础上同时降低了传输的码率。由于用户侧网速的限制,端上存在多个档位,当看播端网速较慢时,可能会切换到 480P/720P 等低分辨档位,此时会触发端上超分算法提升画面清晰度。超分辨率技术指的是,基于机器学习/深度学习方法,根据视频信息对其进行空域、时域建模重构出缺失的细节,将低分辨率的视频重建出高分辨率视频的技术。这样即使是在低分辨档位也能体验到更清晰的画质。左:视频超分前,右:视频超分后除此之外团队还提供大分辨率、高帧率、广色域,并使用色彩增强、自适应锐化等多种画质增强技术,呈现更加沉浸感的超高清画面。最佳实践141“世界杯直播”技术实践解析:抖音视频编码器优化对于世界杯这样的大型体育赛事而言,视频编码算法既要在高速运动、复杂纹理的场景下确保直播内容的清晰度和流畅度,保障用户的观赛体验,又要兼顾码率、延迟等对网络传输层面尤为敏感的指标。另外,抖音实现了业界首次的世界杯比赛支持 4K HDR 10-bit 直播,其内容信息量相较于以往有极大提升,对编码器的实时性提出了更高要求。火山引擎如何完成这个挑战?摘要BEST PRACTICE142BVC 编码器长期迭代优化世界杯项目针对性优化优化成果火山引擎自研的 BVC 编码器经过多年的技术攻关和优化技术积累,以及在不同视频服务业务方向上的长期迭代优化,目前其编码性能和编码器架构的计算效率都处于业界领先水平,在国际权威编码器大赛 MSU 比赛中多次夺冠。概述在 BVC 编码器的基础上,火山引擎多媒体实验室针对世界杯比赛场景进行了一系列针对性优化。首先通过科学构建世界杯比赛视频的测试集,分析足球比赛视频特性,进一步挖掘了当前场景下的先验信息,有效提升了编码效率,在保证画质的情况下进一步降低了码率,同时优化了码率平稳性以及码控精度。同时,团队优化了多核下的并行机制,极大幅度提升了 CPU 利用率;同时分析并优化了 4K HDR 10-bit 视频编码中的复杂度瓶颈,进一步加快了 HDR 视频的编码速度。最终使得 BVC 编码器在保证画质和降低码率的同时,能进一步提升编码速度,达到并超出了 4K HDR 10-bit 50fps 视频实时编码的要求。另外在线上部署时,团队通过主观质量评测专门对足球赛事视频优化了各种不同质量配置下的最优码率,比如超高清 4K,超高清 HDR,蓝光 HD 等质量配置,保证不同用户的观看质量。本次 BVC 编码器共优化了 3 个不同档位,分别用于 4K HDR/SDR 编码,1080p 编码,以及 720p/480p 编码。1.针对世界杯场景,BVC 编码器优化前后各项指标对比如下图可见优化后,BVC 编码器既有相同视频质量下带宽收益(BD-Rate),尤其是在相同 VMAF 质量指标时码率节省收益显著,同时编码速度和 CPU 利用率也提升较大(尤其是 4K 档位),码控精准度也有显著提升。过科学构建世界杯比赛视频的测试集,分析足球比赛视频特性,进一步挖掘了当前场景下的先验信息,有效提升了编码效率,在保证画质的情况下进一步降低了码率,同时优化了码率平稳性以及码控精度。同时,团队优化了多核下的并行机制,极大幅度提升了 CPU 利用率;同时分析并优化了 4K HDR 10-bit 视频编码中的复杂度瓶颈,进一步加快了 HDR 视频的编码速度。最终使得 BVC 编码器在保证画质和降低码率的同时,能进一步提升编码速度,达到并超出了 4K HDR 10-bit 50fps 视频实时编码的要求。另外在线上部署时,团队通过主观质量评测专门对足球赛事视频优化了各种不同质量配置下的最优码率,比如超高清 4K,超高清 HDR,蓝光 HD 等质量配置,保证不同用户的观看质量。2.针对世界杯场景的 4K 10-bit 视频,BVC 编码器与开源 x265 编码器性能对比如下图:可见在相同 PSNR 下,BVC 编码器的带宽节省高于 x265 的 veryslow 最慢档,且在相同测试条件下,编码速度也高于 x265 的 ultrafast 最快档。最佳实践143优化手段团队通过精准构建世界杯足球比赛测试集,有效约束了团队的优化场景,既能为团队提供更多的足球比赛视频的先验信息,同时也不会导致过拟合的情况。在此基础上,团队做了大量编码器内核优化,包括编码工具调优,新增数十项主/客观编码算法,多线程调度以及 SIMD 等工程优化加速,码率控制优化等;在优化过程中,团队使用了多个质量评价指标对优化技术性能进行评估,最终实现了在保证画质不变的条件下既有码率节省又有速度提升的优化效果。1.构建精准的足球比赛测试序列团队分析了足球比赛视频中每个片段的时域复杂度和空域复杂度,同时根据每个片段的场景内容,筛选出了数十个作为足球比赛测试集。在此基础上,团队加入了部分通用测试视频防止过拟合,构建了最终的测试集,如下图:备注:上述图示中,speed(相对于 x265 ultrafast 编码速度)越大越好,bandwidth(相对于 x265 ultrafast 带宽)越小越好。2.优化编码器内核团队首先测试了已有的数十个编码工具在当前场景的性价比,找出性价比最高的(复杂度最低,码率节省最高)工具在当前场景下开启,并关闭性价比低的工具。在此基础上,团队针对编码器内部的多个不同模块,其中包括预分析和编码过程中运动搜索,模式决策,环路滤波等,BEST PRACTICE1441.解决 480p 档位拖影问题2.提升 720p/480p 草坪清晰度优化前(左)vs 优化后(右):优化前(左)vs 优化后(右):优化示例开发了数十项新算法,进一步提高了编码效率和降低模块的计算复杂度,加快编码速度。针对世界杯场景中视频时域复杂度高特点,团队通过优化了码率控制算法,保证了场景切换时的码率平稳性,同时提高了整体码率的精准性。团队也优化了支持 ROI 区域的码控算法,在相同码率下使得主观感受更优,有效提高了足球比赛中人眼敏感的球员区域以及草坪区域的主观质量。团队也进行了大量并行优化,通过多线程任务调度以及 SIMD 优化,提升了多核下的 CPU 利用率,极大加快了编码速度。最佳实践145抖音世界杯直播的低延迟是怎么做到的?世界杯已经结束了,梅西带领阿根廷时隔三十六年之后终于如愿捧杯。抖音直播提供的 4K 超高清超低延迟看播能力给亿万观众留下了深刻的印象,决赛的 PCU 达到 3700w ,在这样大规模并发下,如何能稳定流畅地做到更低的延迟,是一个巨大的挑战。本文主要介绍世界杯期间火山引擎视频云和相关团队在低延迟上的工作和优化,作为低延迟方向上的总结。本文主要讨论生产和传输环节的延迟。生产环节的延迟主要受视频流供应商控制,技术团队可以实现的是,尽可能准确地测量出生产的每一个环节的实际延迟,并在发现不合理的情况时推动供应商解决。传输环节的延迟技术团队更可控,也是本次优化的重点。这部分技术能力可以作为火山引擎视频云的优势能力积累并对外提供服务。在优化的过程中,一个越来越清晰的认知是:降低延迟并不困难,难的是延迟降低之后,怎么通过优化保证播放体验不下降甚至变得更好。摘要BEST PRACTICE146测算方法:拍照 视频画面上有时钟展示的(比如画面左上角或者右上角的北京时间或者比赛持续时间,一般精确到秒),可以通过同时拍照两个播放画面的方式,记录同一时刻两个画面,然后通过照片中的时钟做差来计算。手动秒表计算 如果视频画面中无时钟相关内容,那么可以从延迟低的视频画面中选取具有标志性易识别的帧启动秒表,然后观察延迟高的画面出现同样的帧画面时,停止秒表,记录秒表结果为延迟对比结果。仅适用演播室推流到抖音播放链路首先简单介绍下世界杯直播的整个分发链路,还有每个环节的延迟的测量方法,让大家对整体的链路有初步的全局认识。一、背景信息(一)抖音世界杯信号分发链路(二)全链路延迟测量以及方法最佳实践147 计算方法:端到端延迟=观众当前系统时间戳-SEI 中的时间戳,单位 ms。统计频度:每 2s 计算一次,每 10s 上报一次当前计算结果。每个 I 帧前会有一个 SEI,流规格设置为 I 帧间隔为 2s,因此每 2s 演播室推流侧会生成一个 SEI 帧。前置要求:演播室推流前进行 NTP 本地时钟校准。延迟测量手册:测量环节画面对比参照测试方案执行方央视信号源延迟信号流 Vs 电视机顶盒方法 1 或方法 2演播室.演播室制作 抖音传输总延迟信号流 Vs 抖音 APP 画面方法 1 或方法 2火山引擎视频云/演播室抖音侧传输延迟演播室推出源流 VS 抖音 APP 画面方法 1 方法 3方法 1:火山引擎视频云方法 3:世界杯延迟大盘演播室制作引入延迟信号流 VS 演播室推出源流(演播室制作 抖音传输)总延迟-抖音侧传输延迟火山引擎视频云抖音 APP 与电视信号延迟 diff抖音 APP 画面 Vs 机顶盒方法 1 或方法 2火山引擎视频云/演播室竞品对比竞品 APP 画面 VS 抖音 APP 画面方法 1 或方法 2火山引擎视频云BEST PRACTICE148直播的传输环节里,对延迟影响大的主要是转码、分发和播放缓冲,使用实时的转码模式,转码器引入的延迟一般在 300ms 以内甚至更短。CDN 的分发环节也会带来一定的延迟,但相对也较短。为了对抗网络抖动引入的播放缓冲区引入的延迟播放缓冲引入的延迟常常会有 5s 甚至更多,所以本文主要讨论怎么在减少播放缓冲的情况下,通过不断地优化延迟降低的同时不影响整体的播放体验(不仅仅是卡顿)。在调优过程中,大家对播放体验也有了更细致、更深的理解,逐渐弄清楚了哪些 QoS 指标可以对关键的 QoE 指标产生直接的影响,对以后要优化的方向也更明确了。(一)信号源网络流信号源在给到抖音之前存在多个环节,每个环节都可能会对最终的延迟有影响,但这一部分技术团队可以影响的比较少,主要是运营同学在沟通。(二)演播室制作环节演播室在收到央视的源流之后,需要加上解说和包装,所以也会引入一定的延迟。这次抖音的多个演播室是由多家第三方公司负责的,第三方公司的制作规格不一,在正式比赛之前经过大量的沟通,基本确认最重要的两个演播室的技术方案和使用的编码系统是一致的。不过这次在演播室环节引入的延迟仍然偏高,达到了 1.5s 左右,和供应商工程师沟通后,短期内为了保证稳定,没有再进一步压缩了,这部分引入的延迟和竞品也是一致的。下图是一次直播的简化的流程:生产环节的低延迟三、传输环节的低延迟最佳实践149(一)FLV 方案FLV 是现在国内主流直播播放使用的协议,火山引擎对低延迟直播的探索也是从 FLV 开始的。在百万英雄、内购会等活动中,FLV 低延迟方案也多次得到了验证。之前详细介绍过 FLV-3s 方案在抖音落地的详细实践过程(细节内容可跳转到 基于 http-FLV 的抖音直播端到端延迟优化实践),同时提出过基于 FLV 方案做更低延迟下探,所面临的挑战也会更大:更低延迟的场景对直播全链路的传输稳定性要求苛刻程度会几何倍数增加,由于端到端链路的整体 buffer 更低,生产环节或者观众网络抖动,就更容易发生卡顿。只要发生一次卡顿,延迟就会秒级增加,最终累积延迟会越来越大。而世界杯赛事延迟要求达到 2s,继续延续 FLV-3s 方案显然达不到要求,需要配合精细的追帧或者丢帧策略。1、基于 buffer&卡顿信息的双阈值延迟追赶策略音视频数据流转时序在展开描述延迟追赶策略方案细节前,先简单介绍播放器音视频数据流转时序:网络 IO 下载音视频数据到播放器缓存 buffer-解码器从 buffer 中取数据解码并降解码后的数据存入待播放缓存-音画同步等播控策略-渲染播放音视频帧。数据驱动 QoE&QoS 优化由于进一步下探延迟,卡顿也会随之恶化,反而延迟逐渐累积增加达不到低延迟的效果,因此延迟下探必须配合延迟追赶播控策略来确保延迟增大后可及时追赶恢复到低延迟。是否只要在延迟增加后立即倍速追赶就能满足业务的需求呢?对于延迟 QoS 指标来说的确是,但对于用户主观体验的 QoE 指标,这样的策略反而可能是负向的。结合历史 AB 实验以及 DA 详细数据分析,有以下几点倍速追赶与 QoE 指标之间的关联现象:倍速追赶带来的播放速度变化本身就是负面的体验 倍速时长超过 2 秒,用户即可有感知且负向反馈 倍速速度越大,播放速度前后变化 diff 越大,负向越严重 倍速与正常速度的切换过于频繁,会带来负向反馈综上,需要一套精细的播控策略兼顾延迟与 QoE 指标的平衡。详细方案设计如下:输入:播放器当前 Buffer 时长、历史 Ns 内 buffer 抖动方差、历史 Ns 内卡顿信息以及追帧参数配置。策略可配置参数以及含义映射:参数单位描述.N秒滑动窗口大小,表示最近 NshurryStartMs毫秒滑动窗口大小,表示最近 NshurryStopMs毫秒追帧停止阈值,当前 buffer 时长小于hurryStopMs,应恢复正常速度,停止追赶hurrySpeed无量纲倍速大小BEST PRACTICE150RTM 的方案参考了 WebRTC,可以让端到端延迟直接进入 1s 以内,已经持续在抖音上打磨了一年多,整体来说遇到的困难很大,在推进的过程也不断地发现了新的问题,也逐渐认识到,直接把 RTC 在视频会议上的方案应用到直播播放场景的效果并不好,需要做大量的改造才能让直播的体验得到抖音用户的认可。同时评测的同学也持续对行业内已经上线的类似方案进行了跟踪和测试,经过线上测试后,也发现现有多方案也存在很多问题,所以一直也没有停止自研。RTM 优化的目标是在延迟降低的情况下,用户核心体验指标对齐或者优于大盘的 FLV 方案。但是由于 FLV 低延迟方案的持续优化并拿到结果,一定程度上 RTM 的优化目标的 bar 是在不断提高的。每次迭代都要经过分析数据-找到问题点-提出优化方案-完成开发和测试-AB 实验-分析数据的反复循环,每一次循环的都需要至少一个版本甚至多个版本的周期,所以项目整体耗时较长。关于如何提升实验的效率,也做了很多思考和探索。最后通过多次的实验和反复的问题解决,在核心用户体验指标基本对齐了 FLV,所以在世界杯的多场比赛中,RTM 方案也承担了一定量级的 CDN 容量,核心键指标上都对齐了大盘,稳定性和质量得到了充分的验证。1、RTM 方案优化概述项目启动后,将 RTC 实时通信 SDK 直接集成进入播放器后首先进行线上 AB 测试,初期的实验效果显得大跌眼镜:除了端到端延迟指标符合预期以外无论是拉流成功率,首屏秒开时间,卡顿等指标均与 FLV 差距很大;所以 RTC 技术方案要顺利部署到直播场景,还需要配合直播播控策略进一步优化。为了让 RTM 的综合指标对齐 FLV,从若干角度来进行 RTM 的播控逻辑定制化,所有的优化围绕着核心用户体验指标进行展开:DNS 节点优选、SDK 信令预加载、UDP 连通性预探测主要解决的拉流成功率相关问题。SDP 信令相关优化主要解决信令时间消耗的问题(首帧时间)与成功率问题。输出:目标播放速度。原理:基于 buffer 抖动方差&历史卡顿信息,来定性衡量网络质量,判断是否可以追赶,只有在网络质量良好是才能触发追赶逻辑避免卡顿。追帧采用双阈值,并且支持可配置,可以控制追帧持续时长不超过 2s,同时也可以保证不频繁变速。追帧速度可配置,保证倍速变化不超过一定辐度。2、FLV 2s 低延迟方案在抖音上调优总结(1)收益总结 FLV 2s 低延迟已在抖音验证收益:核心 QoE 波动,电商指标显著正向,成本也有一定比例的节省,目前已全量。世界杯:双端 FLV-2s 方案作为世界杯低延迟方案之一,支持了开幕赛到决赛的全部赛事。(2)调优经验总结 无论播放过程中丢帧方式追赶延迟,还是卡顿后立即丢帧追赶延迟,只要是丢帧,QoE 都是负向。iOS 端对倍速负向没有 Android 敏感,对倍速容忍度高。精细化倍速追帧策略可以满足 FLV-2s 的延迟需求,但再进一步下探延迟,就需要同时配合卡顿优化方案从源头避免延迟增加。(二)rtm 方案最佳实践151 RTC 内核播控定制化主要解决播放的卡顿问题。播放器播控逻辑结合解决的音画同步与渲染策略的问题。2、首帧时间的优化传统的 RTC 技术采用 SDP 信令方式进行媒体能力协商,SDP 信令通过如下图方式进行交互参见下图:BEST PRACTICE152但是 HTTP SDP 信令交互存在如下方案的弊端:弱网环境下(如 RTT 较大/网络信号不稳定),HTTP 信令建联成功率不理想;导致播放请求响应缓慢或超时(基于信令数据包庞大且发生 TCP 重传导致信令响应速度不理想);另一方面 SDP 交互传输 SDP 文本的内容很大(通常 3KB10KB)建联的成本较高导致初始化的成本无法忍受;对比 FLV 的 HTTP 请求完成后直接完成建联和媒体数据直接传输,可以采用新的信令模式:MiniSDP 信令。这是一种基于二进制编码的压缩协议,提供对标准 SDP 协议进行压缩处理;这种方案可以降低信令交互时间,提高网络传输效能,降低直播拉流首帧渲染时间,提高拉流秒开率/成功率等 QoS 统计指标。其作用原理是将原生 SDP 转换成更小的二进制格式(300bytes)通过一个 UDP 包(MTU 限制之内)完成整个 C/S 交互。采用 MiniSDP 信令进行媒体协商通信的信令交互流程如下图所示:采用 MiniSDP 压缩信令方式利用 UDP 网络传输;预期单个 UDP 数据包请求即可完成 SDP 完整压缩信息的传输。最佳实践153当前 MiniSDP 信令(UDP)信令上线后观察后续的 QoS 指标发现,信令建联的成功率和首帧时间得到了大幅度的优化。3、拉流成功率的优化经过线上的 AB 实验发现:RTM 拉流成功率相比 FLV 持续存在着一定的差距,而且这种差距经过观察得知:用户的网络等级质量和用户的拉流成功率存在一定的正相关性(UDP 协议本身特性),即用户网络质量越高成功率越高。拉流网络等级筛选根据网络质量预估信息综合评估用户的 TCP/UDP RTT 和数据下行吞吐率,得出用户网络等级;选择网络质量优异的用户采用 RTM 拉流降低失败率。当线上 AB 实验采用网络等级漏斗进行网络筛选以后,选择用户网络情况相对较好的这一部分的用户开启实验(这部分用户占全网用户的绝大部分,剩余的用户采用默认 FLV 低延时),原理就是用户在拉流前综合权衡当前网络状态,当网络不适合 RTM 时候通过策略前置回落到 FLV,使得这部分用户的体验不受到影响。UDP 节点探测拉流前根据用户请求的 URL 所归属的对应 CDN 边缘节点,发起 UDP 探测;一段时间内发送数据包观察对应 CDN 节点的数据 RTT 和丢包率,只有满足一定条件(如 RTT80ms 且丢包率 请求-响应-断开连接,会引入大量的建连耗时,造成卡顿,同时导致延迟的增大。做一个简单的计算,假设每个切片是 2s,那么平均 1s 就会有一次音频或视频请求的建连,这对于网络较差,尤其是高 RTT 的用户来说是不可接受的,如果此时为了低延迟强行降低 buffer 水位,建连时的缓存消耗将导致频繁的卡顿。为此,可以在 CMAF 上采用 QUIC 协议与连接复用结合的方式,首先 QUIC 协议的 0-RTT 建连允许客户端在服务端确认握手成功之前就发出 HTTP 请求,而连接复用直接省去了后续请求的建连操作,大幅优化了建连耗时,维持延迟的稳定。但即使如此,每个分片的请求也会引入 1-RTT 的延迟,未来将与服务端一起探索预请求模式,进一步压缩延迟、降低卡顿。最佳实践157CMAF 优化的整体难度较大,团队同学也经常需要在半夜和海外的 CDN 的工程师对齐和解决问题。不过经过不断的努力,最近在部分地区的也已经有了阶段性的进展,在部分场景下核心指标已经对齐 FLV,团队也有信心在最近一段时间就能去掉机型和网络类型的限制,让 CMAF 可以承载更多常规比例的流量。(四)Xr 直播的延迟优化XR 直播的沉浸感以及高交互性是普通直播无法比拟的,但是这也导致了传输层需要承担更大的压力:分辨率为 8K x 4K 或 8K x 8K,源流码率达到 50M 甚至 120M、非常容易因为拥塞导致卡顿、延迟增大,甚至无法正常解码播放。火山引擎视频云的做法是将 8K 的视频切分成多个块(tile),只传输用户视角(viewport)内的部分超高清块,其它区域只传输 2K 或 4K 分辨率的缩小后的背景流,在用户切换视角的时候再去重新请求新的超高清块。当然这里需要把切换延迟尽可能降到更低,经过长时间的优化,切换延迟已经降低到非常低,一般情况下已经感受不到切换的过程,未来会持续优化,让切换延迟更低。这两种做法都引入了优先级的概念,即用户视角内的数据优先级高于其他部分,低清数据优先级高于高清数据。基于这种特性,火山引擎视频云将探索基于 UDP 的内容优先级感知的传输方案,优先保障高优数据的传输,对于低优数据可选择非可靠传输,即使丢失也无需重传,保证 XR 直播低延迟的同时不引入过大的视觉失真。经过优化后,在传输 8K x 8K/8K x 4K 的超高清视频时对播放端的码率要求从 120M/50M 降低到 20M/10M 左右甚至更低,在用户侧极大地减少了卡顿发生的概率,从而也减少了延迟增大的概率。未来火山引擎视频云也会持续优化 XR 直播下在更高码率更高分辨率下的卡顿和延迟,为用户提供更沉浸的观看体验。BEST PRACTICE158语音成游戏标配,体验仍面临挑战沐瞳的实践与探索场景切换游戏语音不间断在手游高度发展的今天,游戏与社交密不可分,游戏语音已成为许多游戏不可或缺的重要功能之一。对于Mobile Legends:Bang Bang这类 MOBA 游戏来说,“组团开黑”已成为游戏的乐趣之一,玩家通过语音交流可以与队友更好地协作配合,从而取得更多的比赛胜利。因此提供稳定、流畅的游戏语音体验对于游戏厂商来说变得至关重要。游戏语音内置于游戏中,语音体验会直接影响玩家对游戏本身的体验,例如,场景切换时语音音效中断会打破游戏连续性,而语音功耗高则可能导致游戏画面流畅度降低。这些问题都会破坏玩家游戏时的沉浸感,并降低游戏的用户满意度。此外,由于游戏在全球范围内发行,玩家使用的终端设备和网络环境参差不齐,因此保证玩家流畅低延时的交流体验也成为了一个重要挑战。沐瞳与火山引擎合作,依托于火山引擎 RTC 在游戏语音技术经验的积累,对游戏语音体验全面升级。火山引擎 RTC 利用房间管理与流管理相互独立的架构优势,采用语音流双通道设计,使得玩家从组队到匹配游戏场最佳实践158游戏出海如何让全球玩家“纵享丝滑”体验?伴随东南亚游戏市场呈现出迅猛且稳定的增长态势,收入不断攀升。据Statista Digital Market Insights的数据预测,到 2027 年,东南亚地区的移动游戏市场收入预计达 56 亿美元。来自上海沐瞳科技有限公司(下文简称:沐瞳)的 MOBA 手游 Mobile Legends:Bang Bang 在东南亚市场也热度不减。2022年,Mobile Legends:Bang Bang 作为电竞项目二度入选东南亚运动会,收视数据位列该届运动会电竞项目第一。上海沐瞳科技有限公司(MOONTON)成立于 2014 年,已成功推出多款在海外拥有高知名度的移动游戏产品,是拥有最多海外玩家的中国游戏公司之一,旗下Mobile Legends:Bang Bang为 2021 年 Senser Tower 评选的海外最佳MOBA 手游;并在数十个国家的 App Store 和 Google Play 畅销排行第一。摘要最佳实践159BEST PRACTICE159性能与音质体验平衡Mobile Legends:Bang Bang作为一个风靡全球的手游,沐瞳对提升玩家语音的质量、语音交流的声场环境、声音播放时的响度等方面有着更高的要求。不仅如此,为了不影响游戏本身的流畅度和渲染效果,游戏语音也需要在保证音质体验的基础上做到极致低功耗。沐瞳与火山引擎共建完善且全面的性能测试方案,分别从游戏侧与 RTC 侧分析性能瓶颈,双方共同寻找“最优解”。火山引擎 RTC 通过低计算量的自研自动增益控制,即便是对音量小的机型也可以做到有效提升音量,保证所有机型的游戏语音音量适中;并通过低复杂度的 VAD 自适应算法降噪模型,有效抑制常见环境噪声,啸叫收敛时间相较原方案缩短 50%,提高玩家的语音交流清晰度,同时提升语音整体编码效率,降低游戏语音性能消耗。通过全方位性能优化,火山引擎的游戏语音方案满足各档终端设备玩家交流体验的同时,也能保持游戏战斗画面的自然流畅。值得一提的是,在中低端终端设备中,帧率、大小卡、PSS 内存指标都优于原方案,游戏体验全面提升。低延时语音全球体验一致Mobile Legends:Bang Bang自 2016 年上线以来,迅速风靡东南亚,已经成为东南亚多个国家和地区的“国民游戏”,同时也拓展到拉美、中东、北美、欧洲等市场。火山引擎 RTC 提供覆盖全球的优质网络,并针对东南亚、中东等海外基础设施较差区域打造专属的网络接入节点,游戏玩家可以实现就近、最优的接入,降低了游戏语音的网络延迟和丢包率。此外,火山引擎 RTC 适配了全球40,000 机型,确保在各种设备上都可以提供稳定优质的语音服务,让世界各地玩家都可以拥有低延时且流畅的游戏语音体验。企业出海之路道阻且长,沐瞳携手火山引擎积累了大量的经验和解决方案,依托技术创新、行业经验等优势,不断探索新的前沿技术,持续关注玩家体验,共同探索游戏新方向,为游戏行业的增长持续注入新动力。景相互转换时,底层无需基于 RTC 进退房即可实现队友之间组队语音和全队语音的联通,避免音频引擎重启导致的游戏语音和音效中断卡顿,很好地保持游戏的连续性,为玩家带来了更流畅、更沉浸的游戏体验。BEST PRACTICE160毫末智行&火山引擎迈向自动驾驶“智”高点2023 年是自动驾驶行业的冲刺和考验之年一高阶智能驾驶乘用车的搭载率将从不到 30%增加到 2025 年的 70%。城市导航辅助驾驶将大规模应用,行泊一体化市场迎来量产高峰,末端物流自动配送也正在形成闭环。但是,安全保障和大量无人车的管制是当下面临的最主要的挑战。大算力、大数据和大模型技术的升级将使自动驾驶变得更智能和聪明,在推进自动驾驶技术的同时,安全性和运营问题也将得到解决。摘要最佳实践161平行驾驶”,它是自动驾驶研究的一种新思路,利用传感、物联网、大数据、人工智能等技术在云端构建一个“数字孪生”虚拟驾驶系统。将安全管理搬到虚拟世界中,24 小时保护无人车与乘客安全。和真实世界的安全员相比,虚拟世界里的安全员,无需直接面对风险,要轻松和高效多了。他们以 上帝视角 全方位监控,随时处理潜在风险,同时在恶劣环境下远程控制车辆,确保作业的安全性。“平行驾驶”的 2 大体验升级:从“一对一管理”升级到“一对多管理”:提升工作效率,降低车企的运营管理成本 从“近距离管理”升级到“远程管理”:提升在高危、恶劣环境下作业的安全性。平行驾驶,让安全员“上云”平行驾驶关键要求是,实时传输真实世界画面到虚拟世界,及时传达虚拟世界指令到真实世界,确保状态同步,避免延迟带来的安全隐患。满足实时性、可靠性、稳定性的高要求:在生产环境下,一般要求从车机采集视频到远端安全员看见画面做出指令,再到指令实现,整段延时做到低于 200ms;提升弱网对抗能力的要求:由于车辆在行驶过程中的基站距离一直在变,这些变化会引起较大的网络波动,因此也提升对音视频和信令传输的弱网对抗能力;保障更低码率与更低带宽的传输:一辆自动驾驶车机一般有 5 路以上摄像头同时采集和传输,规模化商业落地后会有大量视频流井喷,给带宽传输和车企的带宽成本带来很大的压力,因此传输时做到尽量保持低码率、低带宽占用。平行驾驶,让虚拟与现实“同步”为了提升末端物流自动配送规模化落地中的安全性和完整性,火山引擎助力毫末智行“小魔驼”搭建了远程运营平台中的远程驾舱模块。远程驾舱可提供监督和脱困两种模式:监督模式:可以对正在末端配送作业的无人车进行远程监管、识别异常;脱困模式:可以在极端环境或紧急情况时短暂介入车辆控制,远程辅助车辆脱困,或完成一些未经训练过的操作。作为国内知名自动驾驶独角兽企业,毫末智行在乘用车辅助驾驶系统、末端物流自动配送车和智能硬件/机器人领域都取得了多项业内第一的成绩。在末端物流自动配送领域,毫末智行于去年发布了全球首款 10万元级的末端物流自动配送车小魔驼 2.0;今年 5 月,又发布了全球首款 9 万元内的中型末端物流自动配送车小魔驼 3.0,截至 2023 年 8 月,小魔驼订单量已经突破 20 万单。毫末智行携手火山引擎打造的远程驾舱方案共同携手,为运营安全保驾护航BEST PRACTICE162远程驾舱方案使用了火山引擎实时音视频 RTC 和实时信令 RTS 技术,在实际应用中,视频卡顿率仅为 0.3%,视频端到端延时低至 100ms,实现了远程安全员和现场车机之间的实时、流畅的交互;同时,在同等清晰度下,火山引擎方案的带宽占用比原方案降低 30%,为公司节省了一笔可观的流量费用。毫末智行携手火山引擎除了提升自动驾驶的安全性,远程车控方案也可以升级各项智能驾驶体验。哨兵模式 PLUS传统哨兵模式的做法是,当系统检测到车辆周围可能存在威胁时会发出警报并通知用户,用户则会收到“您的车辆可能遭受威胁”的通知,如果需要进一步确认情况,用户需要赶到车辆现场。远程车

    浏览量0人已浏览 发布时间2024-04-10 173页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • 智研咨询:2024年中国云计算产业现状及发展趋势研究报告(44页).pdf

    ICTIMCIMITITIaaSPaaSSaaSIaaSPaaSSaaS 一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十

    浏览量29人已浏览 发布时间2024-04-07 44页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • 火山引擎:2024云原生数据仓库ByteHouse性能白皮书(企业版)(35页).pdf

    CONTENTS目 录人群圈选&用户画像BitEngine/BitMap行为分析留存分析函数漏斗分析函数数据分析场景实时数仓0102060708高并发场景10Kafka&FlinkCDC(Change Data Capture)实时数据同步Upsert&部分列更新1.11.21.30101022.12.202043.13.23.33.4060607074.1075.15.20809复杂查询优化器执行层宽表查询预聚合Zero copy 优化全局字典UncompressedCache 优化Vector 向量检索GIS时空分析1012标准测试集性能参照SSB 性能测试测试结果测试环境测试步骤TPC-H 性能测试测试结果测试环境测试步骤TPC-DS 性能测试测试结果测试环境测试步骤1539571.11.21.31517171.11.21.33941411.11.21.3576464在数据处理和分析的领域,提升查询效率始终是一项关键挑战。在 OLAP 领域,性能的关键需求在于能够快速进行数据检索,支持实时分析,具备处理大规模数据的能力,轻松应对复杂查询,提供快速响应,具备良好的可扩展性,高效处理并发操作,以及实现高效的数据压缩和存储。这些方面对于满足高效、准确的数据分析需求至关重要。ByteHouse 是火山引擎自主研发的云原生数据仓库产品,它全面继承了开源 ClickHouse 的高性能和强大的分析能力,并在架构上遵循新一代云原生理念进行全面重构,实现了容器化、存储计算分离、多租户管理和读写分离等功能。在可扩展性、稳定性、可运维性、性能以及资源利用率等方面都有显著提升。截至 2022 年 2 月,ByteHouse 在字节跳动内部的部署规模超过 18000 台,单集群超过 2400 台。它经过了内部数百个应用场景和数万用户的锤炼,并在多个外部企业客户中得到了广泛应用。本文将介绍 ByteHouse 企业版的一系列优化措施。这些改进旨在缩短查询执行时间、优化资源利用,提供更流畅的数据分析体验。通过智能优化算法和先进的执行技术,ByteHouse 能够更好地应对各种复杂的查询场景。为了让大家亲身感受这些优化带来的效果,我们提供了使用 SSB 100G、TPC-H 100G、TPC-DS 100G 数据集的性能测试步骤。您可以按照这些步骤进行测试,亲自验证 ByteHouse 企业版在查询效率方面的显著提升。数据分析场景实时数仓HaKafka:更稳定的高可用 Kafka 消费引擎Kafka&FlinkCDC(Change Data Capture)实时数据同步Upsert&部分列更新ByteHouse 的 HaKafka Engine 是一款自研表引擎,在数据实时消费性能不降级的基础上解决了Kafka 消费的高可用问题,提供了 low-level 消费模式,保证了 At-least-once 消费语义。用户可以通过ByteHouse 控制台可视化创建实时导入任务。当前,很多企业在分析型业务中对数据去重有很强的诉求,为此,ByteHouse 研发了 HaUniqueMergeTree 表引擎,保留了 ClickHouse 高效的查询性能,还支持主键实时更新的场景,ByteHouse 在落盘即去重,解决了社区版 查询时去重的效率问题,可以帮助业务更轻松地开发实时分析应用。同时,在 ByteHouse 中,我们可以在 HaUniqueMergeTree 表中实现部分列更新的功能。部分列更新模式在指定变量 enable_unique_partial_update=1 后,允许以部分列更新的模式进行写入。DES 数据快车服务(ByteHouse 插件)Flink ConnectorFlink Connector for ByteHouse 连接器专用于通过 Flink 将数据加载到 ByteHouse,目前 FlinkConnector 已经支持 通过 Table API&SQL 和 Flink DataStreamAPI 两种方式来连接 ByteHouse并处理数据,详情请参见产品手册(https:/ Express Service)是一个用于将多源异构数据源和数据结构导入到ByteHouse 的服务,通过提供数据集成、结构映射、高效导入、安全可靠等功能,帮助用户快速、准确地将各种类型的数据(如关系型数据库、日志文件、对象存储等)导入到 ByteHouse 中进行后续的处理和分析。使用 DES 可实现数据秒级同步到目标端,用户可以根据业务需求选择不同规格的独享资源以享受更高性能的同步体验,同步性能可达到 25 万 records/s 以上,详情请参见产品手册。目前,数据快车的 CDC 同步任务已支持 MySQL/PostgreSQL 数据源的历史或增量数据同步。内置 MaterializedMySQL 引擎0102为了强化实时数仓的能力,便于将 MySQL 中的表映射到 ByteHouse 企业版中,ByteHouse 引入了MaterializedMySQL 数据库引擎,ByteHouse 服务作为 MySQL 副本,可以读取 Binlog 并执行 DDL和 DML 请求,实现了基于 MySQL Binlog 机制的业务数据库实时同步功能。ByteHouse 企业版在实现 MaterializedMySQL 时,底层引擎采用了自研的 HaUniqueMergeTree 引擎,支持自定义版本字段以及根据 UNIQUE KEY 实时删除数据功能,无需引入其他额外字段。同时,ByteHouse增强了 MaterializedMySQL 引擎的稳定性和易用性。SQL-以部分列更新的模式进行写入,并主动制定更新列示例SET enable_unique_partial_update=1;-主动指定 _update_columns_INSERT INTO t1(k,c1,m1,a1,_update_columns_)VALUES(1,20,k2:2,world,k,c1,m1,a1);kc1c2c3c4m1a1 1 20 3.14 k2:2 world 复杂查询优化器数据库优化器是DBMS中一个核心组件,它负责分析查询语句,并根据表的结构、索引等信息来生成最优的执行计划。通过优化查询执行计划,可以提高查询的执行效率,减少资源消耗,提升系统性能。为了提升在复杂场景的查询性能,ByteHouse 的自研优化器进行了大量的优化,主要包括四个大的优化方向:RBO(基于规则的优化能力),CBO(基于代价的优化能力),分布式计划优化以及一些高阶优化能力。RBO优化器实现了常见的优化规则。例如列裁剪、分区裁剪、表达式简化、子查询解关联、谓词下推、冗余算子消除、Outer-JOIN 转 INNER-JOIN、算子下推存储、分布式算子拆分等常见的启发式优化能力。解关联很多 OLAP 引擎不支持相关子查询,在语法分析阶段就会报错。优化器实现了完整的解关联能力,对于关联查询可以转换为常见的 join agg filter 等算子执行,下图就是一个简单的解关联例子。对于一些特殊类型的关联查询也可以利用 window 算子执行,更加快速简洁。N U L LN U L LCBO0304非等值 Join 优化在很多引擎中,带有非等值条件的 join 需要通过多个算子来组合执行(inner join filter group-by),而在 ByteHouse 中,支持非等值 join 之后可以直接在 join 算子中完成非等值条件的执行。优化器会对一些关联子查询转成非等值 join 来执行,相较于转成其他常见的算子(inner join,filter,agg)性能有一倍以上的提升。Join Reorder对 10 表级别规模的 Join Reorder 问题,能够全量枚举并寻求最优解,同时针对大于 10 表规模的 JoinReorder 支持启发式枚举并寻求最优解。CBO 支持基于规则扩展搜索空间,除了常见的 Join Reorder问题以外,还支持 Outer/Semi/Anti-Join 的 Reorder。基于 Cascade 搜索框架,利用 Graph Partition 技术实现了高效的 Join 枚举算法,以及基于 Histogram的代价估算。分布式计划生成业界主流实现分为两个阶段,首先寻求最优的单机版计划,然后将其分布式化。但是这样的设计流程,不能提前考虑分布式系统的特点,可能会导致网络延迟、数据分布不均衡,并导致可扩展性限制等问题。我们的方案则是将这两个阶段融合在一起,在整个 CBO 寻求最优解的过程中,会结合分布式计划的诉求,从代价的角度选择最优的分布式计划。同时在 Join/Aggregate 过程中,也支持 Partition 属性展开。另外,我们也在 CBO 中实现了对于 Aggregate/Join Reorder,Magic Set Placement 等相关能力。对于 CTE 的实现方式也基于 Cost 进行选择,在 inline,shared 和 partial inline 之间做权衡,选出最优的计划。在 tpcds 等 benchmark 中都有一定的应用。SELECT count(c_custkey)FROM customerWHERE 10000 10000AggregatingNodeGrupBy:o_custkeyFunctions;SUM(o_totalprice)ProjectionNodeDatabase:tpchTable;customerGreaterOrEqualsGroupBy:Functions:count(c_custkey)Assignments:count(c_custkey):count(c_custkey)Assignments:o_totalprice:o_totalpriceo_custkey:o_custkey build side non null symbol:1Ulnt8ReadFromStorageNodeDatabase:tpchTable:orders执行层Exchange在执行层中,数据的传入和传出依赖于 Exchange 模块。Exchange 是数据在 PlanSegment 实例之间进行数据交换的逻辑概念。在具体实现上,我们将其分为数据传输层和算子层。数据传输层主要基于定义的 Receiver/Sender 接口,同进程传输基于队列,跨进程基于 BRPC Stream,支持保序、状态码传输、压缩和连接池复用。简单来说,就是在大集群上的两个节点之间只建立一个连接,所有查询都在这个连接上通信。由于我们使用连接池,实际上两个节点之间是固定数量的连接,这样稳定性更高。算子层支持四种场景:一对多的 Broadcast、多对多的 Repartition、多对一的 Gather,以及本进程之间的 Round-Robin。ByteHouse中另外还做了一些优化,包括避免 Broadcast 重复序列化、提升Repartition 性能以及 sink 攒批。在大集群下,通过一个 ExchangeSource 读取多个 receiver 的数据来降低线程数。0506并行化重构 Bucket 表ClickHouse 内部的并行执行在 Agg 和 Join 上存在一些性能瓶颈,主要表现在不能很好地结合数据上下游的数据特征,以及在中间执行过程中引入了不必要的 Final Merge 和数据 Shuffle。在此基础上,ByteHouse 对 ClickHouse 进行了并行化重构,支持 Aggregation Streaming 并结合HashTable Two-Level 的并行和数据的分布特征,有效减少了中间出现的 Agg Final Merge 和ConcurrentHashJoin 中的数据 Shuffle,从而显著提升了整体 Query 的执行性能。QueryPlanQueryPipelineIQueryPlanStepIProcessorExchangeSourceBufferedCopyTransformTransformerExchange SinkRepartitionTransformMultiPartitionExchangeSinkLoadBalancedExchangeSinkRemote Broadcast APIBRPC BroadcastLocal BroadcastSinglePartitionExchangeSinkBroadcastExchangeSinkRemoteExchangeSourceStepProcessors ModuleData TransportLayerRuntimeFilter 优化在 OLAP 场景中,Join 是一个十分常见的操作,也是查询的性能瓶颈。Runtime Filter 是在 Join 的Probe 端提前过滤掉那些不会命中 Join 的数据,减少存储扫描、网络传输和算子计算的数据,是优化复杂查询的重要手段之一。Runtime Filter 也称为 Dynamic Filter,是一种在执行引擎中动态构建 Filter 的能力。它的目的是通过在 Join 的 Probe 端提前过滤掉那些不会命中 Join 的输入数据,来大幅减少 Join 中的数据传输和计算,从而减少整体的执行时间。例如在 Hash Join 的过程中,当右表 HashTable 构建完成后,将根据 JoinKey HashTable 生成 RuntimeFilter,并将其作用于左表的 Scan 节点,从而减少左表的扫描数据量,可进一步减少磁盘 IO、网络数据传输等,最终使得 Query 的性能显著提高。ByteHouse 支持根据不同的场景生成最优的 RuntimeFilter,优化了生成和 Apply 的流程,同时支持 Distributed 和 Local 的 RuntimeFilter,在较大规模集群上也自适应的支持 Shuffle-Aware 的RuntimeFilter。JoinJoinFilterTableScanRuntimeFilterBuilderTableScanRuntimeFilterBuilderFilterTableScan提前过滤RPCTableScan(withRuntimeFilter)RuntimeFilterProbe宽表查询预聚合物化视图物化视图存储了 SQL 查询语句包含的数据,并提供更新机制。物化视图最重要的功能就是查询加速。用查询物化视图来替代直接查询数据表,可以避免对数据进行再次的计算与聚合,能够以空间换时间的方式节省查询时间,达到查询加速和简化查询逻辑的目的。数据仓库中存在大量在大型表上执行复杂的查询,并会消耗大量资源和时间。物化视图可以通过预计算的结果回答查询,消除昂贵的 Join 和聚合计算所带来的开销,大幅度改善查询处理时间,降低系统负载。对于可以预见并反复使用相同子查询结果的查询,物化视图非常高效。0708ProjectionProjection 是按照 ByteHouse 的存算分离架构进行设计的,Projecton 数据由分布式存储统一进行管理,而针对 projection 的查询和计算则在无状态的计算节点上进行。相比于社区版,ByteHouse Projection实现了以下优势:对于 Projection 数据的存储节点和计算节点可以独立扩展,即可以根据不同业务对于 Projection 的使用需求,增加存储或者计算节点。当进行 Projection 查询时,可以根据不同 Projection 的数据查询量来分配计算节点的资源,从而实现资源的隔离和优化,提高查询效率。Projection 的元数据存储十分轻量,在业务数据急剧变化的时候,计算节点可以做到业务无感知扩缩容,无需额外的 Projection 数据迁移。Zero copy 是一种优化技术,用于在数据传输过程中减少数据的拷贝次数,从而提高数据传输的效率和性能。Zero copy 可以避免原来前期需要的大量 deep copy 操作。在减少 deep copy 降低查询计算overhead 的同时,也可以避免内存 IO 吞吐过早达到内存 IO 带宽上限,从而缓解高并发下内存 IO 吞吐带宽瓶颈带来的问题。Zero copy 优化全局字典UncompressedCache 优化全局字典以全局字典编码的方式进行数据的读写计算,针对 Agg、Function和Exchange 实现了基于编码值的处理,将基于非定长字符串类型的计算改变为基于定长整型编码值的计算,以此提升计算效率。UncompressedCache 优化提高了多线程下 cache 访问的效率。社区 OLAP 多个 cache 模块使用 LRU cache,在多线程并发场景中存在锁竞争激烈,影响 cache 效率的情况。而 UncompressedCache 优化解决了这一问题,提高了系统的性能和响应能力。BitMap 索引(BitMap index)目前用于 Array Int8/16/32/64/String UInt/8/16/32/64/String 类型,它为 Array 数组中每个元素构建一个 bitmap-index,在查询的时候,我们使用 arraySetCheck(column,(item)检测 item 是否在数组里的时候会使用 bitmap-index 做过滤,从而避免大量的 array 数据读取,目前大部分 Array 类型的过滤操作都使用了 bitmap-index,性能有 4-10 倍不等的提升。人群圈选分析是客户画像平台(CDP)中的核心功能。分析师利用各种标签组合,挑选出最合适的人群,进而进行广告推送,达到精准投放的效果。同时由于人群查询在不同标签组合下的结果集大小不同,在一次广告投放中,分析师需要经过多次的逻辑调整,以获得更合适的人群包。在这种高频的操作下,画像平台通常会遇到两方面的问题:第一,由于此类查询分析是临时性的,各种标签组合数巨大,离线预计算无法满足此类灵活性。第二,由于此类查询是实时场景,查询性能变得非常关键,通常一次查询在分钟级,耗时较长,无法满足分析师需求。目前,从 ByteHouse 实测数据表现上看,在 10 亿级用户测试数据下,ByteHouse 的人群查询 P99 小于 10s,展现了优异的性能。人群圈选&用户画像BitEngine/BitMapBitEngine 是一个高效集合数据 处理模型,它是查询分析数据库 ClickHouse 的一部分。BitEngine 底层基于 MergeTree Family 存储引擎,并在此基础上引入了 BitMap64 类型,开发了系列相关运算函数。BitEngine 提供的 BitMap64 类型适合表达具有特定关系的大量实体 ID 的集合,将集合的交并补运算转化为 bitmap 之间的交并补运算,从而达到远超普通查询的性能指标。已上线业务的测试表明,使用BitEngine 相比普通和 Array 或者用户表方式,在查询速度上有 10-50 倍不等的提升,详情可参见官方文档(https:/ 根据用户行为分析使用场景,定制了部分函数,包括留存分析类函数 genArrayIf()/retention2()、路径分析类函数 pathSplit()/pathCount(),以及漏斗分析函数 finderFunnel()/funnelRep()等。漏斗分析和留存分析是常用的转化分析方法,在用户行为分析和 App 数据分析的流量分析、产品目标转化等数据运营和分析中得到广泛应用,使用这些函数相比拼装 SQL 或者 ClickHouse原生函数更为高效。留存分析函数留存分析函数通常用于分析用户在一段时间内的留存情况。这些函数可以帮助我们了解用户在特定时间段后是否仍然活跃或继续使用产品或服务。通过对留存率数据分析数据,可以识别用户行为模式,并通过持续不断的优化产品和数据监测,可以提高用户满意度和忠诚度,增加留存率。0910漏斗分析函数漏斗模型是一种常见的分析方法,用于描述一个过程中各个阶段的转化情况,就像一个漏斗一样,数据从宽口进入,逐渐缩小,最终到达窄口。ByteHouse 中的漏斗函数主要用于统计用户在不同阶段的转化率和转化路径。它可以根据用户的行为数据,分析用户的每一步操作,并将其分为不同的阶段。根据不同的条件,例如访问量、点击量、注册量等,计算每个阶段的转化率,并显示出用户在整个转化路径上的转化。例如,在一些业务场景中,需要选定一段时间范围,观察此时间范围内每一个时间单位(天)内用户按一定时间范围划分的漏斗分层汇总情况。目前,通过使用 ByteHouse 作为查询加速引擎,帮助行为分析系统 接入了字节跳动内部几乎所有的产品线。业务上,在满足了高效查询性能的同时,扩展了时间分析的范围与事件埋点的数量。让分析用户能够在海量数据的情况下,依然可以灵活地进行交互式分析,洞察事件行为背后的原因。SQLDAU:4000 活跃项目:1000 OpenAPI 活跃业务方:100 日增事件数:4万亿条总事件数:1000万亿条 高并发场景OLAP 高并发场景指的是在在线分析处理(Online Analytical Processing)环境中,有大量用户同时进行数据分析操作的情况。在这种场景下,系统需要处理多个并发请求,以满足用户对快速数据查询和分析的需求。比如,在部分在线服务的分析场景下(如游戏日志检索,用户信息检索等),需要给多个分析师提供相似 SQL Pattern 的查询服务。通常此类查询性能要求极高,需要有 10000 以上、可线性扩展的QPS 查询性能。业内主流 OLAP 引擎在高并发能力上表现不佳,通常需要借助行存引擎去支持高并发点查场景,但是对建模和运维管理都带来了很多额外工作量。ByteHouse 针对性做了很多增强,在纯列存模式上极大提升了点查场景的 QPS,技术点包括:TopN 短路计算、唯一键索引、读链路优化、查询模板等等。在某游戏广告推荐业务上,仅仅 256 Core 的算力,即可支持 10万 QPS。Vector 向量检索向量是一种常见的非结构化数据表现形式。基于向量相似度的 KNN 计算广泛使用于图像搜索、多模态搜索、推荐、大模型推理等场景。ByteHouse 企业版已提供向量数据的管理与近似度查询功能,同时通过支持多种常见近近似最近邻搜索算法(Approximate Nearest Neighbor,ANN)算法来提升检索性能,以提供对非结构化数据的处理能力。ByteHouse 企业版当前支持 HNSW(hnswlib)、Faiss 两个算法库,后续还会对 DiskANN 等算法库提供支持。HNSW 索引热门的基于图的近似最近邻搜索算法(ANN)。HNSW 是一种非常流行和强大的算法,具有超快的搜索速度和出色的召回率。(Hierarchical Navigable Small World graphs,分层-可导航-小世界-图)FaissFacebook 开源的 ANN 算法库,包含了倒排(IVF,Inverted File)、PQ、SQ 等多种类型的索引,同时多种索引还可以组合使用。我们主要使用 Faiss 的 IVF 类索引,同时支持 PQ、SQ 等向量压缩方法,以减少索引的内存使用。访问激活注册活跃交易留存用户首次使用时间新增用户留存率1周后2周后3周后4周后5周后6周后7周后8周后日 周 月9周后09-13-09-1909-20-09-2609-27-10-0310-04-10-1010-11-10-1710-18-10-2410-25-10-3111-01-11-0711-08-11-1412061292158412331227137314331351140343.4CD.99.1A.6A.7E.8C(.71.91.61.8&(.3(.92.8%.1$.9&.6.4.6$.2.2!.5 .2!.1.5.4.4.4.9.1.9%9.5.4.4.1%7.2.2.9%9.4%7%7.5%表:Vector 大模型向量检索核心应用场景广泛基于业界最新的 VectorDBBench 测试工具进行测试,在 cohere 1M 标准测试数据集上、recall 98 的情况下,ByteHouse 可以达到与专用向量数据库(以专用向量数据库 Milvus 为例)同等水平的性能。在 recall 95 以上的情况下,QPS 可以达到 2600 以上,p99 时延在 15ms 左右,具备业界领先优势。1112GIS 时空分析在数字化时代,地理空间分析(Geospatial Analytics)成为辅助企业市场策略洞察的重要手段。无论是精准广告投放,还是电商物流的效率优化,都离不开对地理空间数据的查询、分析和可视化处理,以便助力企业更好决策。ByteHouse 的 GIS 功能不仅提供了高性能的地理空间分析能力,还具有易于使用、实时分析和云原生等特点。这使得企业可以更灵活、更高效地利用地理空间数据,从而在激烈的市场竞争中获得优势。在关键性能层面,ByteHouse GIS在列式小批组织的数据结构上引入 RTree 等二维空间索引能力,并在CPU 硬件层面实现了二维空间函数的性能优化,整体提升了端到端性能。在功能层面,兼容 OGC 标准,支持导入标准 GIS 文件格式,目前已支持超过 50 个主流的空间函数。在具体的业务场景中,ByteHouse 的 GIS 功能可以带来显著的提升:位置洞察:通过高性能 GIS(ST_DistanceSphere)函数,企业可以快速获取指定范围内的相关 信息,为定价策略和市场定位提供数据支持。作战地图:利用 GIS(ST_Within)函数,企业可以实时观察特定区域内的商家供给和客流量,为即 时零售业务的配送优化提供决策依据。为了说明性能效果,我们基于两个关键的 GIS 函数:ST_DistanceSphere 和 ST_Within;并使用 NYCTaxi 数据集(Size:21GB;条数:169,001,162),数据集将纽约拆分成多个地理区域(比如 Brooklyn,Manhattan),选取其中 3 个不同大小的地理区域(按照过滤度区分:zone 1、zone 2、zone 3),将 ByteHouse 与 ClickHouse、PostGIS、DuckDB 等常见数据库进行了性能对比。基于标准数据集的测试结果来看,ByteHouse GIS 对比传统的 PostGIS:在 OLAP 层面,ByteHouse 已经有计算优势。在 GIS 层面,空间数据对象按照列的方式存储,而非序列化成字节数组,在存储上能够做到更加紧凑并节省空间,在计算上能够充分发挥向量化的优势。在空间函数层面,可以利用硬件的并行化能力提速。ByteHouse GIS 对比社区 ClickHouse:ByteHouse GIS 兼容 OGC 标准,能够水平替换之前 PostGIS 的场景。空间索引能力可以大大减少 ClickHouse 的读放大的现象。ByteHouse 自研的优化器同样具备适配 GIS 特性的能力。Search Performance Test(1M Dataset,768 Dim)Qps(more is better)ByteHouse-HNSW1,8501,601Milvus0.9850.9825ByteHouse-HNSWMilvusRecall(more is better)533.5s801sByteHouse-HNSWMilvusLoad duration(less is better)5.4ms12.8msMilvusByteHouse-HNSWSerial latency_p99(less is better)行业互联网-电商互联网社交政府机构金融零售应用场景商品以图搜搜图像去重、视频原创验证、风控审核、关联推荐、舆情监控人脸识别、视频检索、指纹搜索、人体图像检索、车辆查找、内容查重人脸识别、文本检索、智能客服人脸识别、商品识别、自动售货机1314标准测试集性能参照SSB、TPC-H 和 TPC-DS 都是常用于测试分析型数据库/数据仓库的数据集。这些数据集被广泛应用于数据仓库领域,并且包含了常见的业务场景和数据模式。通过测试这些数据集,可以全面评估数仓在处理复杂数据结构和查询操作时的性能和效率。SSB:Star Schema Benchmark 是一种在学术界和工业界广泛应用的数据库系统性能评估基准测试方法。它能够对比不同数据仓库在处理星型模式查询时的性能,帮助数据库管理员和决策者选择最符合需求的数据库系统。此外,参考 OLAP 行业的做法,将 SSB 中的星型模型展平转化为宽表,还可以改造成单一表测试 Benchmark(SSB flat)。TPC-H:TPC-H 作为一种决策支持基准,被广泛应用于学术界和工业界,用于评估决策支持技术应用的性能。它以真实的生产运行环境为基础进行建模,模拟了一个包含 8 张表的销售系统数据仓库。其选择的查询和填充数据库的数据具有广泛的行业相关性,同时具备足够的易实现性。TPC-DS:TPC-DS 由 TPC 委员会制定并发布,是一种面向决策支持系统的、涵盖多维度常规应用模型的决策支持基准,包括查询和数据维护。该基准对被测系统在决策支持系统层面的表现评估具有代表性。TPC-DS 查询包含共计 99 个测试语句。以下内容将以性能著称的某开源 OLAP C*为基准产品,通过 SSB、TPC-H 和 TPC-DS 三种数据集,展示 ByteHouse 的性能效果。您可以按照这些数据集的测试步骤进行测试,验证 ByteHouse 在查询效率方面的显著提升。某汽车内容平台借助 ByteHouse 的 GIS 时空分析功能,帮助用户在选择店址时快速评估商业价值。例如,某汽车品牌使用该平台的建店选址产品,可以快速了解该城市的人口分布、消费水平、竞争对手等信息,从而选择最合适的店址,提高开店成功率。ST_Within 函数性能对比ST_DistanceSphere 函数性能对比测试结果经过对标准 SSB 和 SSB 宽表的测试发现:SSB 宽表测试的 13 个查询中,ByteHouse 查询性能全面超越开源产品 C*,整体查询性能达到该产品的 3.6 倍。SSB 标准测试的 13 个查询中,开源产品 C*最后三个查询因为内存问题查询失败,整体查询性能与ByteHouse 相差较大。SSB 性能测试q1.1q1.2q1.3q2.1q2.2q2.3q3.1q3.2q3.3q3.4q4.1q4.2q4.3sum19911797460997467151194736709811512293265253334270191164571991722558查询完成时间(ms)ByteHouse开源产品 C*q1.1q1.2q1.3q2.1q2.2q2.3q3.1q3.2q3.3q3.4q4.1q4.2q4.32811121661501283141581292531114095235207209111267615763095129893278915788792查询完成时间(ms)ByteHouse开源产品 C*SSB 宽表测试结果如下:标准 SSB 测试结果如下:15161718测试环境下面列举了本次 SSB 性能测试所使用的环境信息。硬件环境每个测试环境 3 个节点,配置如下:CPU 16 核:INTEL内存:64 GB网络带宽:5 Gbits/s磁盘:ESSD 高效云盘,空间 200 GB测试步骤ByteHouse 测试所使用的数据、生成、导入和查询步骤如下。测试数据软件环境内核版本:Linux 3.10.0-1127.19.1.el7.x86_64 x86_64操作系统:CentOS Linux release 7.8.2003(Core)数据库版本:ByteHoue 企业版:2.4.0.231 (混布 ZooKeeper:3.8.1)开源产品 C*:24.3.1.1023表名lineordercustomerpartsupplierdateslineorder_flat行数6 亿300 万140 万20 万25566 亿解释SSB 商品订单表SSB 客户表SSB 零部件表SSB 供应商表日期表SSB 打平后的宽表数据生成首先下载 ssb 工具包并编译Bash$git clone https:/ ssb-dbgen$make生产数据Bash$./dbgen-s 1000-T c$./dbgen-s 1000-T l$./dbgen-s 1000-T p$./dbgen-s 1000-T s$./dbgen-s 1000-T d创建测试表SQLDROP DATABASE IF EXISTS ssb_local ON CLUSTER ch_benchmark;CREATE DATABASE ssb_local ON CLUSTER ch_benchmark;USE ssb_local;CREATE TABLE customer ON CLUSTER ch_benchmark(C_CUSTKEY UInt32,C_NAME String,C_ADDRESS String,C_CITY GlobalLowCardinality(String),C_NATION GlobalLowCardinality(String),C_REGION GlobalLowCardinality(String),C_PHONE FixedString(15),C_MKTSEGMENT GlobalLowCardinality(String)ENGINE=MergeTree()ORDER BY(C_CUSTKEY);CREATE TABLE dwdate ON CLUSTER ch_benchmark(D_DATEKEY UInt32,D_DATE String,1920 D_DAYOFWEEK String,-defined in Section 2.6 as Size 8,but Wednes-day is 9 letters D_MONTH String,D_YEAR UInt32,D_YEARMONTHNUM UInt32,D_YEARMONTH String,D_DAYNUMINWEEK UInt32,D_DAYNUMINMONTH UInt32,D_DAYNUMINYEAR UInt32,D_MONTHNUMINYEAR UInt32,D_WEEKNUMINYEAR UInt32,D_SELLINGSEASON String,D_LASTDAYINWEEKFL UInt32,D_LASTDAYINMONTHFL UInt32,D_HOLIDAYFL UInt32,D_WEEKDAYFL UInt32)ENGINE=MergeTree()ORDER BY(D_DATEKEY);CREATE TABLE lineorder ON CLUSTER ch_benchmark(LO_ORDERKEY UInt32,LO_LINENUMBER UInt8,LO_CUSTKEY UInt32,LO_PARTKEY UInt32,LO_SUPPKEY UInt32,LO_ORDERDATE UInt32,LO_ORDERPRIORITY GlobalLowCardinality(String),LO_SHIPPRIORITY UInt8,LO_QUANTITY UInt8,LO_EXTENDEDPRICE UInt32,LO_ORDTOTALPRICE UInt32,LO_DISCOUNT UInt8,LO_REVENUE UInt32,LO_SUPPLYCOST UInt32,LO_TAX UInt8,LO_COMMITDATE Date,LO_SHIPMODE GlobalLowCardinality(String)ENGINE=MergeTree()PARTITION BY toYear(toString(LO_ORDERDATE)ORDER BY(LO_ORDERDATE,LO_ORDERKEY);CREATE TABLE part ON CLUSTER ch_benchmark(P_PARTKEY UInt32,P_NAME String,P_MFGR GlobalLowCardinality(String),P_CATEGORY GlobalLowCardinality(String),P_BRAND GlobalLowCardinality(String),P_COLOR GlobalLowCardinality(String),P_TYPE GlobalLowCardinality(String),P_SIZE UInt8,P_CONTAINER GlobalLowCardinality(String)ENGINE=MergeTree()ORDER BY(P_PARTKEY);CREATE TABLE supplier ON CLUSTER ch_benchmark(S_SUPPKEY UInt32,S_NAME String,S_ADDRESS String,S_CITY GlobalLowCardinality(String),S_NATION GlobalLowCardinality(String),S_REGION GlobalLowCardinality(String),S_PHONE String)ENGINE=MergeTree()ORDER BY(S_SUPPKEY);-Create distributed tableDROP DATABASE IF EXISTS ssb ON CLUSTER ch_benchmark;CREATE DATABASE ssb ON CLUSTER ch_benchmark;use ssb;CREATE TABLE customer ON CLUSTER ch_benchmark AS ssb_local.customerENGINE=Distributed(ch_benchmark,ssb_local,customer,C_CUSTKEY);CREATE TABLE dwdate ON CLUSTER ch_benchmark AS ssb_local.dwdateENGINE=Distributed(ch_benchmark,ssb_local,dwdate,D_DATEKEY);CREATE TABLE lineorder ON CLUSTER ch_benchmark AS ssb_local.lineorderENGINE=Distributed(ch_benchmark,ssb_local,lineorder,rand();CREATE TABLE part ON CLUSTER ch_benchmark AS ssb_local.partENGINE=Distributed(ch_benchmark,ssb_local,part,P_PARTKEY);CREATE TABLE supplier ON CLUSTER ch_benchmark AS ssb_local.supplierENGINE=Distributed(ch_benchmark,ssb_local,supplier,S_SUPPKEY);数据导入导入单表数据。Bashclickhouse-client-d bench-query INSERT INTO customer FORMAT CSV customer.tblclickhouse-client-d bench-query INSERT INTO part FORMAT CSV part.tblclickhouse-client-d bench-query INSERT INTO supplier FORMAT CSV supplier.tblclickhouse-client-d bench-query INSERT INTO lineorder FORMAT CSV lineorder.tblclickhouse-client-d bench-query INSERT INTO dwdate FORMAT CSV=1993-01-01 and LO_ORDERDATE=1993-12-31 AND LO_DISCOUNT BETWEEN 1 AND 3 AND LO_QUANTITY=1994-01-01 and LO_ORDERDATE=1994-01-01 and LO_ORDERDATE=1992-01-01 AND LO_ORDERDATE=MFGR#2221 AND P_BRAND=1997-12-01 AND LO_ORDERDATE=1992-01-01 AND LO_ORDERDATE=1992-01-01 AND LO_ORDERDATE=1997-01-01 and LO_ORDERDATE=1997-01-01 and LO_ORDERDATE=MFGR#2221 AND P_BRAND=MFGR#2228 AND S_REGION=ASIAGROUP BY D_YEAR,SQL-Q1.1SELECT SUM(LO_EXTENDEDPRICE*LO_DISCOUNT)AS REVENUEFROM lineorder,dwdateWHERE LO_ORDERDATE=D_DATEKEY AND D_YEAR=1993 AND LO_DISCOUNT BETWEEN 1 AND 3 AND LO_QUANTITY=1992 AND D_YEAR=1992 AND D_YEAR=1992 AND D_YEAR=date 1996-01-01 and l_shipdate date 1996-01-01 interval 3 monthGROUP BY l_suppkey;sum(l_extendedprice)as sum_base_price,sum(l_extendedprice*(1-l_discount)as sum_disc_price,sum(l_extendedprice*(1-l_discount)*(1 l_tax)as sum_charge,avg(l_quantity)as avg_qty,avg(l_extendedprice)as avg_price,avg(l_discount)as avg_disc,count(*)as count_orderfrom lineitemwhere l_shipdate=date 1998-12-01group by l_returnflag,l_linestatusorder by l_returnflag,l_linestatus;-Q2select count(*)from(select s_acctbal,s_name,n_name,p_partkey,p_mfgr,s_address,s_phone,s_commentfrom part,partsupp,supplier,nation,regionwhere p_partkey=ps_partkey and s_suppkey=ps_suppkey and p_size=15 and p_type like%BRASS and s_nationkey=n_nationkey and n_regionkey=r_regionkey and r_name=EUROPE and ps_supplycost=(select min(ps_supplycost)from partsupp,supplier,nation,region where p_partkey=ps_partkey and s_suppkey=ps_suppkey and s_nationkey=n_nationkey and n_regionkey=r_regionkey and r_name=EUROPE )order by s_acctbal desc,n_name,s_name,p_partkey)as t1;-Q3select count(*)from(select l_orderkey,sum(l_extendedprice*(1-l_discount)as revenue,o_orderdate,o_shippriority导入数据Pythonclickhouse-client-d bench-query=insert into region format CSV region.tbl;clickhouse-client-d bench-query=insert into nation format CSV nation.tbl;clickhouse-client-d bench-query=insert into supplier format CSV supplier.tbl;clickhouse-client-d bench-query=insert into part format CSV part.tbl;clickhouse-client-d bench-query=insert into customer format CSV customer.tbl;clickhouse-client-d bench-query=insert into lineitem format CSV lineitem.tbl;clickhouse-client-d bench-query=insert into orders format CSV orders.tbl;clickhouse-client-d bench-query=insert into partsupp format CSV partsupp.tbl;查询数据SQL-Q1select l_returnflag,l_linestatus,sum(l_quantity)as sum_qty,性能测试过程中,将执行以下 22 条查询 SQL。from customer,orders,lineitem where c_mktsegment=BUILDING and c_custkey=o_custkey and l_orderkey=o_orderkey and o_orderdate date 1995-03-15 group by l_orderkey,o_orderdate,o_shippriority order by revenue desc,o_orderdate )as t1;-Q4select o_orderpriority,count(*)as order_countfrom orderswhere o_orderdate=date 1993-07-01 and o_orderdate date 1993-07-01 interval 3 month and exists(select *from lineitem where l_orderkey=o_orderkey and l_commitdate=date 1994-01-01 and o_orderdate=date 1994-01-01 and l_shipdate date 1994-01-01 interval 1 year and l_discount between 0.06-0.01 and 0.06 0.01 and l_quantity=date 1993-10-01 and o_orderdate (select sum(ps_supplycost*ps_availqty)*0.0001000000 from partsupp,supplier,nation where ps_suppkey=s_suppkey and s_nationkey=n_nationkey and n_name=GERMANY )order by value desc)as t1;4950-Q12select l_shipmode,sum(case when o_orderpriority=1-URGENT or o_orderpriority=2-HIGH then 1 else 0 end)as high_line_count,sum(case when o_orderpriority 1-URGENT and o_orderpriority 2-HIGH then 1 else 0 end)as low_line_countfrom orders,lineitemwhere o_orderkey=l_orderkey and l_shipmode in(MAIL,SHIP)and l_commitdate l_receiptdate and l_shipdate=date 1994-01-01 and l_receiptdate=date 1995-09-01 and l_shipdate date 1995-09-01 interval 1 month;-Q15select s_suppkey,s_name,s_address,s_phone,total_revenuefrom supplier,revenue0where s_suppkey=supplier_no and total_revenue=(select max(total_revenue)from revenue0 )order by s_suppkey;-Q16select count(*)from(select p_brand,p_type,p_size,count(distinct ps_suppkey)as supplier_cntfrom partsupp,partwhere p_partkey=ps_partkey and p_brand Brand#45 and p_type not like MEDIUM POLISHED%and p_size in(49,14,23,45,19,3,36,9)and ps_suppkey not in(select s_suppkey from supplier where s_comment like%Customer%Complaints%)group by p_brand,p_type,p_sizeorder by supplier_cnt desc,p_brand,p_type,p_size)as t1;-Q17select sum(l_extendedprice)/7.0 as avg_yearlyfrom lineitem,partwhere p_partkey=l_partkey and p_brand=Brand#23 and p_container=MED BOX and l_quantity 300 )and c_custkey=o_custkey and o_orderkey=l_orderkeygroup by c_name,c_custkey,o_orderkey,o_orderdate,o_totalpriceorder by o_totalprice desc,o_orderdate)as t1;-Q19select sum(l_extendedprice*(1-l_discount)as revenuefrom lineitem,partwhere (p_partkey=l_partkey and p_brand=Brand#12 and p_container in(SM CASE,SM BOX,SM PACK,SM PKG)and l_quantity=1 and l_quantity=10 and l_quantity=20 and l_quantity (select 0.5*sum(l_quantity)from lineitem where l_partkey=ps_partkey and l_suppkey=ps_suppkey and l_shipdate=date 1994-01-01 and l_shipdate l1.l_commitdate and exists(select *from lineitem l2 where l2.l_orderkey=l1.l_orderkey and l2.l_suppkey l1.l_suppkey )and not exists(select *from lineitem l3 where l3.l_orderkey=l1.l_orderkey and l3.l_suppkey l1.l_suppkey and l3.l_receiptdate l3.l_commitdate )and s_nationkey=n_nationkey and n_name=SAUDI ARABIAgroup by s_nameorder by numwait desc,s_name)as t1;-Q22select cntrycode,count(*)as numcust,sum(c_acctbal)as totacctbalfrom (select substr(c_phone,1,2)as cntrycode,c_acctbal from customer where substr(c_phone,1,2)in (13,31,23,29,30,18,17)and c_acctbal (select avg(c_acctbal)from customer where c_acctbal 0.00 and substr(c_phone,1,2)in (13,31,23,29,30,18,17)and not exists(select *from orders where o_custkey=c_custkey )as custsalegroup by cntrycodeorder by cntrycode;5556测试结果经过测试发现,在完成 TPC-DS 标准测试数据集的 99 个查询中,开源产品 C*总体时间超出 6 倍多,且部分语句无法正常执行。在两者均完成查询的结果中,开源 OLAP C*与 ByteHouse 查询时间相差15.7 倍,其中 Q53、Q63、Q82 等语句的查询效率相差 200 倍左右,具体数据如下图:TPC-DS 性能测试5758q23q24q25q26q27q28q29q30q31q32q33q34q35q36q37q38q39q40q41q42q43q441002516512802894231403356328112610627020771925114313295741791711112153730266120676123925100014887096784901197219361720256203498047556001898查询完成时间(ms)ByteHouse开源 OLAP C*q1q2q3q4q5q6q7q8q9q10q11q12q13q14q15q16q17q18q19q20q21q224202875085899416382348223106619833671281430671130249037663526013020391408950523900011544860222301028166170025520006782106914871897查询完成时间(ms)ByteHouse开源 OLAP C*5960q67q68q69q70q71q72q73q74q75q76q77q78q79q80q81q82q83q84q85q86q87q8848393022955701801787158271224125454485984549554458205249261528200134411167837815600386337510813009609500168096090385084935606242135617485594查询完成时间(ms)ByteHouse开源 OLAP C*6162q45q46q47q48q49q50q51q52q53q54q55q56q57q58q59q60q61q62q63q64q65q6621339510146032294162760110180392112234660423103942834536618213857555751618162700065651591147083714633528484297502832434710373360121237093000查询完成时间(ms)ByteHouse开源 OLAP C*测试环境下面列举了本次性能测试所使用的环境信息。硬件环境每个测试环境 3 个节点,配置如下:CPU 8 核:INTEL内存:32 GB网络带宽:5 Gbits/s磁盘:ESSD 高效云盘,空间 500 GB测试步骤准备工作软件环境内核版本:Linux 3.10.0-1127.19.1.el7.x86_64 x86_64操作系统:CentOS Linux release 7.8.2003(Core)数据库版本:开源产品 C*:24.3.1.1023ByteHoue 企业版:2.4.0.231 1.请扫描下面的二维码联系 ByteHouse 小助手,回复“ByteHouse 性能测试脚本”,获取最新版本的 ByteHouse-TPCDS 测试脚本。2.确保安装了 ClickHouse Client 程序,详情可参考 ClickHouse Client。6364q89q90q91q92q93q94q95q96q97q98q99225315227111495464276277195315855139734330146906824005471392120562064查询完成时间(ms)ByteHouse开源 OLAP C*6566安装依赖Bashsudo apt-get install gcc make flex bison byacc git time通过下面的命令安装依赖程序。查询数据在 ByteHouse 上运行 TPD-DS 100G 基准测试,运行成功后系统会显示测试结果。Bash./benchmark.sh 100版权声明本书正文部分的所有内容,包括但不限于文字、商标、架构、图示、图片、页面布局等,其知识产权(著作权、商标权、专利权、商业秘密等)归属于北京火山引擎科技有限公司及其关联公司,非经火山引擎书面同意,任何个人和组织不得复制、使用、修改、转发或以任何违反本书所承载的目的进行传播。获取并解压 ByteHouse-TPCDS 工具包,进入目录后先配置 Config 文件,重点关注配置文件中的ByteHouse 连接地址 ip、端口,以及 连接密码。Bashcp config.sh.tpl config.sh创建指向“bin/clickhouse”的软链接。Bashln-s$path-to-clickhouse-binary bin/clickhouse按下面的命令完成编译。Bashchmod a x*.sh./build.sh生成数据生成 TPC-DS 标准测试集 100G 的数据。这一过程可能时间较长,请耐心等待。Bash./gen_data.sh 100导入数据执行命令将生成的 TPD-DS 数据从数据文件导入到 ByteHouse。这一过程可能时间较长,请耐心等待。Bash./populate_data.sh 100创建表结构运行下面的命令以在 ByteHouse 中创建数据库和表。SQL./create_table.sh 100

    浏览量0人已浏览 发布时间2024-03-28 35页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • 国产算力行业深度:驱动因素、国产替代、产业链及相关企业深度梳理-240315(31页).pdf

    1/31 2024 年年 3 月月 15 日日行业行业|深度深度|研究报告研究报告 行业研究报告 慧博智能投研 国产算力行业深度:驱动因素、国产替代、产业链及相关企业深度梳理国产算力行业深度:驱动因.

    浏览量0人已浏览 发布时间2024-03-21 31页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • 华为云DevSecOps质量效能白皮书(2023)(45页).pdf

    华为云DevSecOps质量效能白皮书有质量的效率,有效率的质量,使能企业价值创造1111011010100110011110010000110001010001011001002023年7月01 华.

    浏览量0人已浏览 发布时间2024-03-20 45页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • 中国信通院:绿色算力技术创新研究报告(2024年)(47页).pdf

    中国信息通信研究院云计算与大数据研究所 2024年03月 绿色算力技术创新研究报告绿色算力技术创新研究报告 (2022024 4 年年)版权声明版权声明 本报告版权属于中国信息通信研究院,并受法律保.

    浏览量0人已浏览 发布时间2024-03-18 47页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • 绿盟科技:2023公有云安全风险分析报告(84页).pdf

    CONTENTS执行摘要101公有云安全发展趋势分析1022023 年重大云安全事件回顾32.1简介42.2微软 AzureActiveDirectory 配置错误导致 Bing 服务受到严重影响42.

    浏览量0人已浏览 发布时间2024-03-18 84页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • 算力行业深度:驱动因素、行业现状、产业链及相关公司深度梳理-240226(43页).pdf

    1/43 2024 年年 2月月 26 日日 行业行业|深度深度|研究报告研究报告 行业研究报告 慧博智能投研 算力行业深度:驱动因素、行业现状、产业算力行业深度:驱动因素、行业现状、产业链及相关公.

    浏览量0人已浏览 发布时间2024-02-29 43页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • ICV TA&K & 光子盒:2024全球量子计算产业发展展望报告(105页).pdf

    2024/02量子信息年度系列报告2024全球量子计算产业发展展望在过去的一年里,我们见证了全球量子计算领域取得的多方面的进展和突破,这些成就正在引领人类进入一个前所未有的计算时代。2023年无疑是A.

    浏览量0人已浏览 发布时间2024-02-22 105页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • 量子信息网络产业联盟:2024量子计算云平台功能模型、体系架构与能力分级研究报告(58页).pdf

    量子计算云平台功能模型、体系架构与能力分级研究报告 1 一、研究背景与意义(一一)国内外量子计算云平台发展现状国内外量子计算云平台发展现状 图 1 给出了量子计算及云平台的发展历程。1900 年 Ma.

    浏览量0人已浏览 发布时间2024-02-05 58页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • IBM:2024云端制造:运营和IT高管将愿景转化为优势报告(37页).pdf

    联合出品方 IBM 商业价值研究院|研究洞察云端制造运营和 IT 高管将愿景转化为优势2IBM 可以帮助制造商利用混合云、AI 和自动化实现全新的业务敏捷水平。我们将依托于久经考验的工业 4.0 参考.

    浏览量0人已浏览 发布时间2024-02-02 37页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • 先进计算产业发展联盟:2023生命科学算力解决方案白皮书(43页).pdf

    生命科学算力解决方案白皮书生命科学算力解决方案白皮书先进计算产业发展联盟先进计算产业发展联盟20232023 年年 1212 月月I版权声明版权声明本白皮书版权属于先进计算产业发展联盟,并受法律保护。.

    浏览量0人已浏览 发布时间2024-02-01 43页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • 艾瑞咨询:2023年中国隐私计算行业研究报告(50页).pdf

    部门:TMT金融组署名:李梦瑶2023 iResearch Inc.2023年中国隐私计算行业研究报告数据流通生态加速开展建设,场景布道仍需多方齐力推动2自2016年伊始,我国隐私计算在政策、学术研究.

    浏览量0人已浏览 发布时间2024-02-01 50页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • CSA GCR:2024云控制矩阵 v4报告( 中英文版)(18页).pdf

    云控制矩阵 4.0(中英版)中中文文翻翻译译版版说说明明本文由云安全联盟大中华区(CSA GCR)CCM4.0翻译专家组对Cloud Controls Matrix v4进行翻译审校。翻翻译译审审校校.

    浏览量0人已浏览 发布时间2024-01-29 18页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • Dynatrace:2023年版DevOps自动化脉动报告(48页).pdf

    2023 DynatraceDevOps 自动化脉动 2023 年版由 Dynatrace 提供的调查研究DevOps 自动化脉动|2前言 随着企业继续向云原生软件交付过渡,DevOps 自动化已从提.

    浏览量0人已浏览 发布时间2024-01-23 48页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • 可信边缘计算推进计划:2024边缘云原生虚拟化研究报告(31页).pdf

    I边缘云原生虚拟化研究报告2024 年 1 月可信边缘计算推进计划II目次前言.III1 技术与需求概述.11.1 虚拟机和容器.11.2 OpenStack 与 Kubernetes.11.3 融合.

    浏览量0人已浏览 发布时间2024-01-15 31页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • 先进计算产业发展联盟:大数据云原生技术发展研究报告(2023年)(53页).pdf

    大数据云原生技术发展研究报告大数据云原生技术发展研究报告(2023 年)年)先进计算产业发展联盟先进计算产业发展联盟2023 年年 12 月月I研 究 报 告 要 点研 究 报 告 要 点随着行业的快.

    浏览量0人已浏览 发布时间2024-01-12 53页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • 中国移动研究院:2023分布式异构智能算力的管理和调度技术研究报告(26页).pdf

    1分布式异构智能算力的管理和调度技术分布式异构智能算力的管理和调度技术研究研究报告报告研究单位:研究单位:中国移动研究院、浪潮电子信息产业股份有限公司中国移动研究院、浪潮电子信息产业股份有限公司、新华.

    浏览量0人已浏览 发布时间2024-01-11 26页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
  • 清华产业院&浪潮信息:中国算力发展观察报告(2023)(38页).pdf

    2023年12月?03?04?05?06?07?08?09?10?11?12?13?14?15?16?17?18?19?20?21?22?23?24?25?26?27?28?29?30?31?32?,.

    浏览量0人已浏览 发布时间2024-01-08 38页 推荐指数推荐指数推荐指数推荐指数推荐指数5星级
300条  共15
前往
会员购买
小程序

小程序

客服

专属顾问

商务合作

机构入驻、侵权投诉、商务合作

服务号

三个皮匠报告官方公众号

回到顶部