B站视频模板的前世今生

从剪辑工具的角度，可以将创作拆解为主题、素材、剪辑三个要素

主题：对应的品类 & 风格，比如游戏、影视、泛生活等

素材：用户使用的视频、音频、图片等内容

剪辑：对素材进行时间、空间、效果上的调整，比如裁剪、复制、滤镜、转场、特效等

视频模板恰好覆盖了创作的三个要素，限定「主题」和「剪辑手法」，允许用户填入部分「自定义素材」，降低用户创作门槛，实现B站的供增需求，从而辅助达成用增的目标

竞品使用视频模板完成了大规模的起量，B站也在该领域进行不断的探索和迭代，除了字幕、特效、贴纸等基础剪辑能力，还实现了AI绘图、3D运镜等高阶功能，相较竞品支持更多的垂类玩法。

从模板生产者角度，可以将视频模板分为PGC和UGC两种类型：

PGC视频模板：使用定制工具，由内部设计 & 供应商制作模板

UGC视频模板：使用必剪APP，支持所有用户制作模板

下面是PGC和UGC模板的优劣对比

从21年-23年，我们持续完善了视频模板的协议，并将其从「PGC生产模式」逐步迁移至「UGC生产模式」

目前在B站多款应用中（粉版、必剪）已落地了UGC视频模板功能，效果如下图：

在实现视频模板之前，首先需要了解模板的生命周期，从而设计出一套合理的模板生成 & 解析方案

一个模板从诞生到消费成稿件，包含5个阶段：生产、审核、分发、消费、投稿

生产：用户使用必剪编辑器，对素材进行剪辑操作，生成模板并投递至素材中台

审核：在素材中台对模板的效果和能力进行人工 & 机器审核，将满足要求的模板pick至模板推荐库

分发：根据用户画像、模板消费等信息将模板分发至不同的应用 & 人群

消费：用户使用模板，填充自定义素材并进行二次微调

投稿：用户将微调后的编辑器草稿投递稿件，生成作品

基于生命周期，梳理模板的工作流程，如下图所示：

工程框架角度，将视频模板分为三个层级：业务层、通用业务层、基础组件层

业务层：负责独立业务，如模板配置页、模板Feeds流等，不同业务有各自的实现

通用业务层：业务相关，向上层业务输出通用能力，如主编辑器引擎、上传组件、模板协议等

基础组件层：业务无关，向上层业务输出原子能力，如剪辑SDK、推理引擎、ASR服务等

明确了工作流 & 工程架构，我们会发现在整个模板生命周期中，有一项内容贯穿始终，那就是「模板协议」

模板协议是限定「主题」、「素材」和「剪辑手法」的主要手段，它告诉我们一个元素应该在什么时间、以哪种方式、出现在什么位置

对于模板协议，需要具备三个特性：

支持跨端：支持在Android、iOS、PC、Web、后端等各平台生产 & 解析协议数据

可拓展的：支持新增字段，向前兼容（老版本应用支持解析新版本协议）

易于传输：支持序列化 & 反序列化，压缩率高（IO读写 & 网络传输快）

很多数据序列化的方式都拥有「支持跨端」和「可拓展」这两个特性，比如：XML、JSON、Protobuf，在这里列举下我们选择Protobuf的理由：

tips：编解码速度方面，部分JSON框架也做过相应的优化，因此实际差距可能不大

实际上Protobuf最吸引我们的理由在于它的可维护性：多端共同维护一套协议，由框架输出数据模型，确保数据模型的一致性

对于JSON来说，协议本身可以通过子仓方式进行同步，但是数据模型依然是各平台独自定义，人工维护（文档同步 or 口口相传）势必会有模型不一致的风险。PB通过框架帮助我们有效规避了这个问题，各平台都有适合自己的框架来解析协议并生成最新的数据模型

下面是分别使用JSON和PB来实现模板协议的对比案例：

确定使用PB之后，需要针对协议内容 & 管理制定一系列规约：

● 协议管理：通过Submodule管理协议并进行权限收口，仅开放给各平台相关负责人修改权限

● 协议字段规范：禁止使用键值对，要求所有字段语义明确

● 协议修改规范：只允许新增字段，不允许修改字段（保证向前兼容）

● 长数据类型（ID & 时间戳）：禁止使用int，推荐使用string或int64

● ……

下面是模板协议的一个简单案例：

这是一个比较标准的树状结构：

1个时间轴包含N个视频轨道、音频轨道、字幕轨道、xx轨道

1个轨道内包含N个片段

1个片段内包含出入点 & 素材ID等核心信息

模板中使用了很多的素材类型：比如视频、音频、图片、特效、字幕等

素材有两种来源：本地 & 素材库

本地素材：用户从本地选择的图片/视频，会在模板打包时拷贝至模板包并在PB记录素材的相对路径

素材库素材：用户从素材库选择的素材，会在PB记录素材ID和URL

为了保证模板在多个平台解析的效果和性能，需要对素材本身进行一系列的约束

针对「本地素材」，为了节约上传带宽和存储成本，因此在模板打包前需要优先执行一次转码操作：

为了进一步降低存储和下行带宽，在云端针对「本地素材」进行二次转码操作：

下图是模板zip包的目录设计，除了代表模板协议的draft.pb，还包含了视频、图片、音频类型的「本地素材」：

上文提到了模板生命周期的五个阶段：生产、审核、分发、消费、投稿，分别对应模板的五个子系统，本章节通过几个问题来阐述实现子系统的核心思路。

思考一个问题：模板中的原子能力不断迭代，包含新原子能力的模板无法在老版本APP正常解析，我们应该怎么分发这些模板呢？

最简单的思路是：控制模板下发的APP版本号

如果采用这个方案，又引申出三个问题：

1.  谁来配置版本号？

2.  怎么配置版本号？

3.  如果将模板业务横向输出至多个应用，版本号应该怎么管理？

在解答上面这个问题之前，我们先丰富一下背景：

假设APP1.0实现了A功能，APP2.0实现了B功能，APP3.0实现了C功能

用户使用APP1.0制作了一款模板T1，其中携带了A功能

用户使用APP3.0制作了两款模板T2和T3，T2携带了AC；T3携带了A

我们的期望是：T1和T3可以下发给APP1.0、APP2.0、APP3.0；T2只下发给APP3.0

很显然，如果单纯控制模板下发的APP版本号，无法依据生产模板的APP版本号进行自动配置（按这个逻辑，T3只能下发给APP3.0）；我们也无法人工挨个做确认和配置（日均成千上万个模板，成本过高）；假如将模板输出给粉版和必剪使用，控制模板在不同APP的不同版本下发显然更加不现实。

因此模板版本控制的核心在于：应用隔离 & 理解原子能力

下面是最终设计的方案：

• 上传模板后，在云端记录该模板的原子能力，比如T1携带"A"；T2携带"A,C"；T3携带"A"

• APP发起模板列表的请求时，上报该版本支持的原子能力集合，比如APP1.0上报"A"；APP2.0上报"A,B"；APP3.0上报"A,B,C"

通过上面两个步骤，云端根据「APP支持的原子能力」⊆「模板携带的原子能力」进行简单过滤，就可以将支持在APPx正常解析的模板列表正确下发了

如果模板上线后，与之关联的「素材库素材」下架了，模板侧如何获取到关联素材失效的通知？以及该模板后续要如何处理？

在第4小节提到过「素材库素材」的概念：模板PB中会记录该素材的ID和URL，若素材下架后，该ID & URL也会随之失效

关于问题一，我们建设了模板 x 素材关系图谱，在素材中台建设模板与素材的双向映射。当素材下架后，通过图谱可查询到影响模板的范围。协议格式如下：

关于问题二，思考两种方案：

1.  自动将模板下架

2.  模板局部效果应用失败，整体还原依然成功

考虑到UGC视频模板属于用户资产，会影响激励结算，因此采用方案二的方式，不做强制下架处理。

为了实现UGC制作的生产模式，我们将必剪主编辑器开放成模板生产的工具。这意味着模板需要实现线上所有的剪辑能力。

但是各平台独自发展迭代了几年，UI上看着差不多，内部实现早已存在巨大的差异，简单举几个例子：

1.  A平台使用交叠转场；B平台使用普通转场

2.  A平台使用归一化坐标；B平台使用绝对坐标

3.  A平台使用剪辑SDK实现图片裁剪功能；B平台使用系统SDK实现该功能

凡此种种，涉及成百上千种剪辑能力，我们是如何抹平平台间的差异的？

归纳成三句话就是：确保协议唯一性，向正确方向兼容，允许通过适配层来减少部分工作量

其中「确保协议唯一性」和「向正确方向兼容」比较好理解，比如我们希望采用归一化的坐标来标识所有的特效（蒙版、画面偏移等），那就针对不合理的一方进行改造。但是这里遇到一个问题：如果我们直接针对引擎数据进行修改，所有调用该引擎的上层业务需要全面适配，工作量不可控。

所以针对改造成本过大的差异，允许使用中间方案进行一定妥协：不直接修改引擎数据，而是在模板打包生成PB时，通过胶水层抹平部分平台差异性。

模板更多是依赖本地剪辑SDK的一种脚本能力。当模板遇到远程或异步耗时服务时（asr、tts、倒放、AI绘图等），又应该如何做扩展呢？

下面以"AI绘图"举例，描述模板是如何支持远程AIGC服务的

5.4.1. AI服务交互流程

AI服务的流程相对简单，本质上就是资源请求的逻辑，通过A文件请求获取B文件：

5.4.2 模板预处理机制

我们来思考下如何将”AI绘图“集成至模板系统：

1.制作模板时，当用户针对素材A使用"AI绘图"并生成素材A'，需要在PB对应的VideoClip打上"AI绘图"的标签

2.消费模板时，当用户选择了素材B，若VideoClip携带"AI绘图"的标签，先异步将B处理为素材B'，再将B'填充至VideoClip中

3.除了"AI绘图"，所有针对素材的异步操作都要走类似流程，因此抽象出一个前处理环节：PB文件->TimeLine模型->PreProcess->引擎数据模型

PreProcess设计如下：

通过PreProcess机制，我们拓展了很多本地剪辑SDK不支持的异步效果（AI绘图、3D运镜、高光识别等），这也是视频模板拓展垂类玩法的核心策略。

为了将模板业务横向输出至必剪、B站等多个平台使用，在第2节模块分层的基础上，我们还使用flavor x 插件化的方式重构模板业务，并针对不同宿主实现按需依赖：

main（蓝色）：所有平台集成

bcut（黄色）：仅集成至必剪APP

bilibili（粉色）：仅集成至bilibili APP

编译选项如下：

模板和稿件类似，需要搭配一套审核系统才可以正常运转。模板的功能、性能、效果、安全都需要经过验证才允许下发给用户使用。

首先介绍下模板管理平台的构成：

模板投稿库：用户通过必剪APP上传的模板会存储在这个地方，等待审核

模板精选库：审核通过后的模板会转存到此处，等待各业务方（粉版 & 必剪）按需使用

模板推荐库：当模板被挑选到推荐库，就会实际下发给用户使用

一个原始的审核系统是如何运转的？

模板上传至投稿库->人工测试模板的功能、性能->人工检查模板的效果、安全->将模板挑选至精选库->业务方将模板上架至推荐库

可以发现，人工保障的流程太多了，如果只是简单检查效果没问题，但是还要人工检查每个模板的功能和性能，审核速度将成为最大的瓶颈

实际上最初我们就遇到了审核资源不足的问题：将投稿库（待审核）的模板下放到一个白名单模板列表中，让测试 & 审核同学逐个检查还原功能是否正常。当模板产能日均上百后，大家都开始宣告"罢工"，只有一条路摆在眼前：如何通过机审来承担一部分人审的工作？

分析了世面上部分画面检测技术，我们选择通过PSNR来评估模板的还原度：在EP部署一批云真机，机审过程中，优先将模板下载到云真机进行还原，将「还原视频」与生产侧导出的「预览视频」进行比对，若对比结果一致，则认为功能正常，继续走人审检查模板的效果；否则直接将模板淘汰。

优化后的审核流程如下图所示：

模板上传至投稿库->机审测试模板的功能、性能、安全->人工检查模板的效果->将模板挑选至精选库->业务方将模板上架至推荐库

执行过程中发现PSNR的召回率高，但准确率很低（50%左右），即机审通过的模板一定是正确的，但机审失败的视频不一定就有问题。

为此我们使用cv算法来丰富图像比对策略，确保机审的准召率达到95%以上：

最终通过搭建机审系统，解决了审核人力不足的问题，支持日均审核1000+的模板量级

当模板业务正式上线，需要观测业务的健康度，特别是核心链路的各项技术指标是否正常，因此我们建设了模板全链路的监控体系。

根据模板的生命周期细分核心指标：

● 模板生产侧：模板导出成功率 & 耗时、模板上传成功率 & 耗时

● 模板分发侧：模板封面加载耗时

● 模板消费侧：模板下载成功率 & 耗时、模板还原成功率、稿件导出成功率 & 耗时

数据下钻遵循几个基本原则：

1.  成功率指标：

a.  准确性：触发=成功+失败+取消，偏差不超过0.1%

b.  细分错误码，溯源造成失败的原因

c.  细分场景 & 类型，例如记录模板分类：游戏大片、图文模板、UGC模板等

2.  耗时指标：

a.  明确从触发到完成的最短路径

b.  细分场景 & 类型

监控方案上（实时 or 离线表），对时效性要求没有那么高，因此选择了离线表的方式（Hive，H+1）

最终建设的看板示例如下：

随着视频模板的基础建设落地，我们结合B站生态 & 热门垂类做了更多的尝试，比如王者战报、原神活动、心情日签等

这些尝试的底层均依赖了模板协议，上层进行业务差异化处理，比如高光识别、智能填坑。下面是一些案例展示：

B站的消费生态以优创为导向，高播稿件往往意味着PUGV & OGV

而移动端剪辑工具的定位更多是用来提供效率 & 创意向的视频剪辑手法，生产的内容以轻创为主（如果拿稿件时长衡量，轻创通常集中在3min以内），模板便是其中的典型案例

从业务视角看，很多人可能都有类似的困惑：模板=轻创=低质？

不可否认，模板确实存在内容同质化的问题。但从成长路径的视角，模板除了起量的优势，还可以作为up成长的敲门砖，配合任务 & 激励，可以培养出更多优秀的up主生产优质内容。

从技术视角看，模板代表着剪辑更多的可能性，目前部分竞品已实现了云草稿等商业化手段。不论是云草稿还是端云协同，都离不开模板协议的支持。

关于模板，关于B站的视频创作，用一句话来表达我的心声：道阻且长，行则将至；行而不缀，未来可期。

以上是今天的分享内容，如果你有什么想法或疑问，欢迎大家在留言区与我们互动，如果喜欢本期内容的话，欢迎点个“在看”吧！