各类剪辑类工具中都有一键成片的能力，解决创作者在视频创作中剪辑特效包装难的问题，行业主流做法一般是对用户上传的视频素材识别提取高光，加上后期的模板特效包装，最后出片。以上处理均会对视频进行裁剪处理以适应模板填充坑位的时长。

B站从2022年7月开始做智能成片功能，第一版仅支持「图片转视频」功能，核心是对用户选择的图片素材添加简单的音乐包装，转化成视频，基本流程如下：

图片

2022年10月开始做第二版的智能成片，支持添加视频元素，同时扩充了特效包装的维度，除了业界通用的模板特效，还结合了智能配乐，以及对用户音频信息的识别自动转化成字幕。新的智能成片业务流程：

图片

以上第一版和第二版总体上完整了智能成片结构化的特效包装，即模板，配乐，ASR字幕 基础智能三要素。历史原因，在业务滚动迭代快的情况下，智能成片仅完成了快速上线的要求，也就是0到1的建设。在成片的性能上没有定义出核心可观测的指标。比如内部用户反馈的效果问题，成片耗时长等基础体验问题较多：

图片

本文主要从效率和效果 两个层面来探讨B站智能成片上的性能优化与实践。

二. 可观测性数据建设

基于智能成片整体的业务流，梳理核心的三条链路以及三条主链路下的子链路。首先定义出智能成片关键性的两个可用指标。

合成耗时：用户选择完素材之后，开始智能成片和完成智能成片的整体耗时。这里我们取P90的指标来做参考

合成效果的定义提取较为复杂，有三个维度的链路可以去优化：

●素材应用成功率：提升智能成片子链路（基础的模板，配乐，ASR字幕）的素材应用成功率，每一个子链路应用成功，即代表最终还原的效果越丰富。

这一维度的定义偏理想化，但子链路素材应用成功率的指标业务上是可量化的。

●模板还原原子能力的丰富度：特效包装集模板本身的原子能力补齐，模板具备更丰富的子元素。

这一维度为业务手段补基础能力提模板效果，不做讲解

●素材推荐的精准度：智能推荐的模板，音乐等包装特效能和用户选择的素材内容相匹配，精准度高。

模板和音乐的推荐依赖于 AI模型的画面标签识别率，画面标签识别率主要是人工评测，识别率在41%（P0画面标签识别率 68%），这部分的优化依赖画面识别模型本身的能力升级，本文不做详解。

以上我们最终选取「素材应用成功率」作为合成效果的主要量化指标。本文主要围绕这一维度的优化展开。

有了基础的指标定义，我们从智能成片全局角度整理输出需要补全的观测数据：

图片

三. 性能优化

初始数据显示，智能成片的P90耗时为 20s （基本超时），素材应用成功率：46%。整体可用性较差。

在基础数据量化的基础上，我们从三条核心链路切入，摸排可优化的点定项优化。整体的摸排点如下：

图片

 3.1 模版链路优化

初始模板的下载成功率只有91%，模板从抽帧推荐到下载完成P90耗时 在19s

模板推荐从素材页到智能成片合成页整体业务链路如下：

图片

我们从以下几个关键点进行优化

3.1.1 资源重复下载问题

主要是两类资源重复下载问题：

• 一类 智能成片业务流程中有单独的音乐下载。模板本身也携带音乐子元素但业务流并不会采用（模板携带的音乐和素材本身不匹配）。这里我们采用的方案是模板下载业务层支持素材子元素按需下载（剔除了不需要的素材）。
• 二类 历史原因哔哩哔哩粉版字幕和必剪字体字幕版本不一致，而UGC模板都是必剪生产。智能成片下载完模板资源之后，因字体字幕资源的不匹配而需要重新索引下载相匹配的字幕字体资源。解决方案类似，按需处理不下载模板携带的字体字幕，直接跳过下载单次智能成片需要的字体字幕。

图片

以上是两类典型的资源重复下载问题，通过缩减不必要资源从而节省下载耗时。最终P90耗时缩减 2s

3.1.2 特殊资源转码问题

我们对智能成片超时（业务配置20s即为超时）链路进行收集，分析80+ bad case，逐一查看超时原因。发现两个超时较多的场景：

图片

1） iOS 端字幕下载经常超时 120s，经过反复尝试摸排，我们发现业务下载器存在bug，下载多字幕字体时下载链路会卡住，直至下载任务超时120s之后返回结果。

2） 模板素材中子元素包含GIF素材时，容易超时。分析发现业务使用的三方剪辑SDK存在私有素材格式的定义，GIF素材在模板消费端会被转码成三方剪辑SDK自定义的CAF格式素材，这个转码过程耗时较长，容易超时。

• 问题一：修复业务下载处理流程即可
• 问题二：有两个方向，第一个方向是素材效果还原时支持直接渲染GIF（由于美摄自定义格式问题，未开放类似API），第二个方向是模板素材生产端生产素材时直接将GIF素材转化成CAF格式，消费端可直接读取CAF素材渲染从而缩减链路转化的耗时。

图片

基于第二个方向优化，又衍生出一系列链路需要处理：

• 对于存量的包含GIF素材的模板，需要清洗转化成CAF格式。对于增量的模板，含GIF素材的生产端默认直转CAF格式，需要对模板生产端进行改造。同时下发新的生产包给到内部或外部模板生产商。
• 内部有自研剪辑SDK蒙太奇，支持GIF素材渲染。在前置优化已转成CAF格式的前提下。处理这类不同SDK对素材兼容问题，也有两个方案：

• 美摄支持CAF素材格式反向转化成GIF格式。在最终自研SDK替换上线时，对素材在进行一次清洗CAF转GIF。通过与美摄技术对接，诉求API可以提供
• 自研剪辑SDK支持美摄私有CAF格式，需要对CAF格式素材进行逆向分析，然后解码支持CAF格式渲染。通过与内部自研SDK技术团队沟通，该方案也能走通。

以上两个方案在考虑业务迭代和上游模板生产维护成本的角度，优选是「自研剪辑SDK支持CAF格式」。从素材格式标准化的角度，优选「美摄支持CAF素材反向转成GIF格式」。最终我们选择「自研剪辑SDK支持CAF格式」低成本的解决这个问题。

素材格式转换处理和多字幕问题修复之后，P90耗时大幅下降至12s。

图片

3.1.3 模板资源大小生产标准化 & 版本兼容

智能成片的模版素材一般是由内部设计师生产。早期素材中台素材入库时没有对素材体积做标准化压缩处理，模版生产时也未对模版做大小限制，部分生产的模版体积超大，下载耗时长。这里我们从两个方向进行优化：

图片

• 定义模板体积基线标准（20M）。模板生产提交时，实时计算模板总体积，超出标准体积的，展示模版元素体积信息，针对大体积子元素做替换处理

图片

• 推动素材中台对素材做标准化压缩处理，增量素材接入转码服务，存量素材做清洗。同时根据不同业务场景下发不同质量素材。

图片

模版版本兼容

图片

模板是一个特效包装集，它是由多个基础原子能力组成，比如字幕，字体，转场特效，滤镜，画中画..., 在加上标准还原协议。模板的原子能力随着版本迭代逐步增加。如何设计版本兼容方案？

简单的做法是针对不同模版支持的原子能力做版本控制。这里的问题在于：

• 模板运营同学需要知道该模板支持的原子能力与支持的App版本，理解难度高。
• 在素材中台纯手工配置模板支持的版本号，效率低。

更合理的做法，App端维护一份支持还原的原子能力信息，云端根据App端支持的模板原子能力和模板本身支持的原子能力，筛选出相匹配的模版列表，在下发到App端。以上解决了模板分发的问题。但仍有部分情况需要做版本兼容处理：

• 比如某个原子能力升级之后对应素材没办法向下兼容，需要做版本隔离，新版本对应新素材，旧版本对应旧素材。
• 比如做了某个性能优化，生产端素材格式发生了变化（如前所述GIF转CAF优化），需要对新素材做版本隔离。

版本隔离的问题在于，纯手工配置容易出错，在历史版本迭代中，也有少许因版本上线间隔时间长，模板生产端人员变动长下文信息不全导致的版本隔离信息配置出错，最终导致模版子元素拉取失败，进而影响模板下载成功率。

以上问题我们通过模板下载报错信息，索引到对应模板子元素，逐一校准模板版本信息，该问题解决之后，模版下载成功率提升至96%

图片

3.1.4 模板资源增加预加载&兜底处理

业界基操，采用预加载和增加兜底来提升素材下载应用的成功率。我们从三个方面做了预加载的逻辑

• 对下载推荐模板失败 或者 下载超时的模板 增加预下载兜底模板，保证基础的包装特效
• 对高热的智能成片转化率高的模板增加预下载，提高高热模板的缓存命中率，缩减耗时
• 缩减模板服务链路，模板核心zip资源及其索引子元素支持并发下载

图片

同时也做了模板下载器本身的优化，历史模板业务下载器仅支持串行下载。业务上接入基架新的下载组件，解决无法并发下载的问题。

3.2 ASR链路优化

智能成片的第二条智能链路，核心依赖ASR服务，ASR服务主要是对音频数据分析，输出音频分类信息：有音乐，混音，有人声，没有声音四个类别。每个类别的标识看各类信息的占比：

图片

其业务链路如下：

ASR链路中可以优化的点

问题1：ASR服务耗时较长，单线统计ASR链路耗时，发现P90基本超20s，处于不可用状态。

问题2：ASR链路前置流程包含音频文件提取和音频上传链路。音频上传链路中会出现耗时较长的场景。主要点是历史原因：音频文件上传链路中间有一个业务服务和文件存储服务做转发，耗时有损。

图片

问题1：协同AI服务端查找极端case排查，最终是发现ASR服务接口被刷的情况，服务QPS过高，导致业务ASR处理排队等待耗时长。处理方案是将刷量的task任务加入黑名单。处理完之后，ASR链路P90耗时缩减50%

图片

图片

问题2：去除上传业务服务中间层即可，客户端直接调用基础文件存储BFS服务接口再返回存储地址给到AI服务侧，缩减链路。

图片

 3.3 智能音乐链路

智能成片的第三条链路，音乐推荐。其基本流程如下。

图片

AI侧处理响应音乐推荐主要有三个维度的指标：用户特征，音乐特征，画面特征：

• 用户特征依赖基础的人群分层。
• 音乐特征是用户往期匹配的音乐特征记录，每天更新一次。
• 画面特征即用户本次智能成片识别素材的画面标签。

基于以上三个特征按权重推荐音乐，且画面特征维度更匹配当次智能成片的效果。

在某次上传组件升级替换过程中，业务侧传递了错误的抽帧地址给到AI服务侧导致无法输出画面标签。AI侧基于用户特征和音乐特征返回了策略降级的音乐推荐（音乐和画面匹配度低，同质化问题），业务侧无感知。

问题的发现主要是AI团队有基于画面打标成功率监控告警，一段时间内，打标成功率大幅低于预期值。

图片

问题的修复：

• 客户端回滚线上编辑器帧上传功能配置至老组件，线上用户止损。
• 客户端新版本修复帧地址给错问题。基于新的业务配置灰度放量

问题的预警：业务测试和研发人员在交付验收阶段如何判断返回的推荐音乐是否降级。以及上线之后业务侧能否更快感知。

AI服务端返回无画面特征的错误信息，端上基于此错误做两个处理：

• 客户端log日志打印音乐推荐错误信息（含新的是否包含画面特征的错误），验收阶段方便筛查。
• 客户端增加实时埋点上报，统计有画面特征音乐推荐成功率，根据实际情况确定推荐成功率阈值，做实时告警监控。

通过以上系列优化，智能成片P90耗时在 10s左右，素材合成成功率 90%+

图片

四. 指标防裂化

前面主要讲解了智能成片性能优化过程，这一部分主要是对已达成的指标做客户端监控告警，防止数据劣化。我们主要从以下几个纬度来建立监控告警整体流程

图片

• 定指标：这部分主要定义智能成片三条核心链路子链路的关键节点指标来做告警。

图片

• 设阈值：对每个选定的指标项设置合理的阈值，统计时间范围，触发条件 etc

图片

• 配置告警：在Fawkes平台配置每个关键节点指标的告警信息
• 备注：Fawkes是一款企业移动Sass平台产品，提供了全面的移动应用程序开发和部署解决方案，可以大大提高开发效率和应用程序质量，降低开发成本和风险。

图片

• 告警响应处理：告警触发之后，值班人员对告警进行响应处理。我们定义了基础5-10-20原则，即5分钟发现，10分钟响应，20分钟定位问题。

这里有两个问题，告警触发后如何快速通知值班人员？以及如何让值班人员快速查找error信息

图片

我们通过Fawkes告警平台，配置自定义的Webhook信息。告警触发后，通过解析标准Webhook配置，筛选告警关键日志信息，在通过自定义Webhook封装关键日志信息和当日的值班人员信息推送到告警处理群。

图片

• 告警复盘：每条告警信息都有当日值班人员记录，我们会定期对告警值班信息进行复盘，不断校准告警颗粒度和阈值信息。

以上通过实时告警监控SOP建设，对智能成片三条主链路数据做日常巡检。定期收集，分析，调整告警信息，告警更加精准，提升日常值班效率。

五.总结和展望

5.1 总结

我们首先定义出智能成片核心可用性指标，基于核心指标细化关键链路节点可观测数据。同时基于数据围绕模板，ASR字幕，配乐三条链路做耗时和成功率的调优。最后我们对智能成片核心链路建立实时监控告警值班机制，防止数据劣化。未来数据，调优，告警三部分还会持续演进。

数据部分：更加精细化，数据口径校准

调优部分：智能模板生产端素材大小监控，模板素材入库标准化，画面识别准召率提升

监控告警部分：策略类告警补齐（智能配乐策略），智能成片耗时告警补齐，告警颗粒度细化，双端告警差异项对齐。

5.2 未来方向

智能成片1.0 主要是 模板，ASR字幕，配乐基础三要素特效包装，并没有对用户素材本身做处理（Before）。

智能成片2.0 是对标行业竞品，基于画面识别的能力做智能提取高光，智能剪辑（ing...）。

智能成片3.0 基于AIGV大模型，通过AI生成视频内容，一键成稿（Future）。

图片

本期作者

徐惠雨哔哩哔哩资深开发工程师