本期作者
一、前言
1.创作的本质是什么
从剪辑工具的角度，可以将创作拆解为主题、素材、剪辑三个要素
主题：对应的品类 & 风格，比如游戏、影视、泛生活等
素材：用户使用的视频、音频、图片等内容
剪辑：对素材进行时间、空间、效果上的调整，比如裁剪、复制、滤镜、转场、特效等
视频模板恰好覆盖了创作的三个要素，限定「主题」和「剪辑手法」，允许用户填入部分「自定义素材」，降低用户创作门槛，实现B站的供增需求，从而辅助达成用增的目标
2.B站视频模板的迭代历程
竞品使用视频模板完成了大规模的起量，B站也在该领域进行不断的探索和迭代，除了字幕、特效、贴纸等基础剪辑能力，还实现了AI绘图、3D运镜等高阶功能，相较竞品支持更多的垂类玩法。
2.1. PGC vs UGC
从模板生产者角度，可以将视频模板分为PGC和UGC两种类型：
PGC视频模板：使用定制工具，由内部设计 & 供应商制作模板
UGC视频模板：使用必剪APP，支持所有用户制作模板
下面是PGC和UGC模板的优劣对比
2.2. PGC to UGC
从21年-23年，我们持续完善了视频模板的协议，并将其从「PGC生产模式」逐步迁移至「UGC生产模式」
目前在B站多款应用中（粉版、必剪）已落地了UGC视频模板功能，效果如下图：
二、实现
1.生命周期 & 工作流
在实现视频模板之前，首先需要了解模板的生命周期，从而设计出一套合理的模板生成 & 解析方案
一个模板从诞生到消费成稿件，包含5个阶段：生产、审核、分发、消费、投稿
生产：用户使用必剪编辑器，对素材进行剪辑操作，生成模板并投递至素材中台
审核：在素材中台对模板的效果和能力进行人工 & 机器审核，将满足要求的模板pick至模板推荐库
分发：根据用户画像、模板消费等信息将模板分发至不同的应用 & 人群
消费：用户使用模板，填充自定义素材并进行二次微调
投稿：用户将微调后的编辑器草稿投递稿件，生成作品
基于生命周期，梳理模板的工作流程，如下图所示：
2.架构设计
工程框架角度，将视频模板分为三个层级：业务层、通用业务层、基础组件层
业务层：负责独立业务，如模板配置页、模板Feeds流等，不同业务有各自的实现
通用业务层：业务相关，向上层业务输出通用能力，如主编辑器引擎、上传组件、模板协议等
基础组件层：业务无关，向上层业务输出原子能力，如剪辑SDK、推理引擎、ASR服务等
3.协议规约
明确了工作流 & 工程架构，我们会发现在整个模板生命周期中，有一项内容贯穿始终，那就是「模板协议」
模板协议是限定「主题」、「素材」和「剪辑手法」的主要手段，它告诉我们一个元素应该在什么时间、以哪种方式、出现在什么位置
对于模板协议，需要具备三个特性：
支持跨端：支持在Android、iOS、PC、Web、后端等各平台生产 & 解析协议数据
可拓展的：支持新增字段，向前兼容（老版本应用支持解析新版本协议）
易于传输：支持序列化 & 反序列化，压缩率高（IO读写 & 网络传输快）
3.1.JSON vs Protobuf
很多数据序列化的方式都拥有「支持跨端」和「可拓展」这两个特性，比如：XML、JSON、Protobuf，在这里列举下我们选择Protobuf的理由：
tips：编解码速度方面，部分JSON框架也做过相应的优化，因此实际差距可能不大
实际上Protobuf最吸引我们的理由在于它的可维护性：多端共同维护一套协议，由框架输出数据模型，确保数据模型的一致性
对于JSON来说，协议本身可以通过子仓方式进行同步，但是数据模型依然是各平台独自定义，人工维护（文档同步 or 口口相传）势必会有模型不一致的风险。PB通过框架帮助我们有效规避了这个问题，各平台都有适合自己的框架来解析协议并生成最新的数据模型
下面是分别使用JSON和PB来实现模板协议的对比案例：
3.2.协议规范
确定使用PB之后，需要针对协议内容 & 管理制定一系列规约：
● 协议管理：通过Submodule管理协议并进行权限收口，仅开放给各平台相关负责人修改权限
● 协议字段规范：禁止使用键值对，要求所有字段语义明确
● 协议修改规范：只允许新增字段，不允许修改字段（保证向前兼容）
● 长数据类型（ID & 时间戳）：禁止使用int，推荐使用string或int64
● ……
3.3. 协议示例
下面是模板协议的一个简单案例：
……
message TimeLine {
string id = 1;
// 时间轴配置：分辨率 & 帧率 & 码率
TimeLineConfig config = 2;
// 视频轨道
repeated VideoTrack videoTracks = 3;
// 音频轨道
repeated AudioTrack audioTracks = 4;
}
message VideoTrack {
string id = 1;
// 转场片段
repeated VideoTransition transitions = 2;
// 视频片段
repeated VideoClip clips = 3;
}
message VideoClip {
string id = 1;
// 片段的入点 & 出点
int64 inPoint = 2;
int64 outPoint = 3;
// 素材id
LocalPath materialId = 4;
}
……
这是一个比较标准的树状结构：
1个时间轴包含N个视频轨道、音频轨道、字幕轨道、xx轨道
1个轨道内包含N个片段
1个片段内包含出入点 & 素材ID等核心信息
4.素材格式规约
模板中使用了很多的素材类型：比如视频、音频、图片、特效、字幕等
素材有两种来源：本地 & 素材库
本地素材：用户从本地选择的图片/视频，会在模板打包时拷贝至模板包并在PB记录素材的相对路径
素材库素材：用户从素材库选择的素材，会在PB记录素材ID和URL
为了保证模板在多个平台解析的效果和性能，需要对素材本身进行一系列的约束
4.1. 模板支持的多媒体格式
4.2. 本地转码规范
针对「本地素材」，为了节约上传带宽和存储成本，因此在模板打包前需要优先执行一次转码操作：
4.3. 视频云转码规范
为了进一步降低存储和下行带宽，在云端针对「本地素材」进行二次转码操作：
4.4 模板zip包设计
下图是模板zip包的目录设计，除了代表模板协议的draft.pb，还包含了视频、图片、音频类型的「本地素材」：
5.生产 & 消费子系统设计
上文提到了模板生命周期的五个阶段：生产、审核、分发、消费、投稿，分别对应模板的五个子系统，本章节通过几个问题来阐述实现子系统的核心思路。
5.1. 版本兼容方案
思考一个问题：模板中的原子能力不断迭代，包含新原子能力的模板无法在老版本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正常解析的模板列表正确下发了
5.2. 模板 x 素材关系图谱
如果模板上线后，与之关联的「素材库素材」下架了，模板侧如何获取到关联素材失效的通知？以及该模板后续要如何处理？
在第4小节提到过「素材库素材」的概念：模板PB中会记录该素材的ID和URL，若素材下架后，该ID & URL也会随之失效
关于问题一，我们建设了模板 x 素材关系图谱，在素材中台建设模板与素材的双向映射。当素材下架后，通过图谱可查询到影响模板的范围。协议格式如下：
message EditorBody {
// 协议版本
int32 version = 1;
//使用的素材列表
repeated Material Materials = 2;
//使用的功能列表
repeated Feature Features = 3;
//其他元数据信息
Metadata Metadata = 4;
}
关于问题二，思考两种方案：
1. 自动将模板下架
2. 模板局部效果应用失败，整体还原依然成功
考虑到UGC视频模板属于用户资产，会影响激励结算，因此采用方案二的方式，不做强制下架处理。
5.3. 抹平平台间的差异性
为了实现UGC制作的生产模式，我们将必剪主编辑器开放成模板生产的工具。这意味着模板需要实现线上所有的剪辑能力。
但是各平台独自发展迭代了几年，UI上看着差不多，内部实现早已存在巨大的差异，简单举几个例子：
1. A平台使用交叠转场；B平台使用普通转场
2. A平台使用归一化坐标；B平台使用绝对坐标
3. A平台使用剪辑SDK实现图片裁剪功能；B平台使用系统SDK实现该功能
凡此种种，涉及成百上千种剪辑能力，我们是如何抹平平台间的差异的？
归纳成三句话就是：确保协议唯一性，向正确方向兼容，允许通过适配层来减少部分工作量
其中「确保协议唯一性」和「向正确方向兼容」比较好理解，比如我们希望采用归一化的坐标来标识所有的特效（蒙版、画面偏移等），那就针对不合理的一方进行改造。但是这里遇到一个问题：如果我们直接针对引擎数据进行修改，所有调用该引擎的上层业务需要全面适配，工作量不可控。
所以针对改造成本过大的差异，允许使用中间方案进行一定妥协：不直接修改引擎数据，而是在模板打包生成PB时，通过胶水层抹平部分平台差异性。
5.4. 模板 x AIGC远程服务
模板更多是依赖本地剪辑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运镜、高光识别等），这也是视频模板拓展垂类玩法的核心策略。
6.模板组件化建设
为了将模板业务横向输出至必剪、B站等多个平台使用，在第2节模块分层的基础上，我们还使用flavor x 插件化的方式重构模板业务，并针对不同宿主实现按需依赖：
main（蓝色）：所有平台集成
bcut（黄色）：仅集成至必剪APP
bilibili（粉色）：仅集成至bilibili APP
编译选项如下：
三、保障
1.模板审核系统
模板和稿件类似，需要搭配一套审核系统才可以正常运转。模板的功能、性能、效果、安全都需要经过验证才允许下发给用户使用。
首先介绍下模板管理平台的构成：
模板投稿库：用户通过必剪APP上传的模板会存储在这个地方，等待审核
模板精选库：审核通过后的模板会转存到此处，等待各业务方（粉版 & 必剪）按需使用
模板推荐库：当模板被挑选到推荐库，就会实际下发给用户使用
一个原始的审核系统是如何运转的？
模板上传至投稿库->人工测试模板的功能、性能->人工检查模板的效果、安全->将模板挑选至精选库->业务方将模板上架至推荐库
可以发现，人工保障的流程太多了，如果只是简单检查效果没问题，但是还要人工检查每个模板的功能和性能，审核速度将成为最大的瓶颈
实际上最初我们就遇到了审核资源不足的问题：将投稿库（待审核）的模板下放到一个白名单模板列表中，让测试 & 审核同学逐个检查还原功能是否正常。当模板产能日均上百后，大家都开始宣告"罢工"，只有一条路摆在眼前：如何通过机审来承担一部分人审的工作？
分析了世面上部分画面检测技术，我们选择通过PSNR来评估模板的还原度：在EP部署一批云真机，机审过程中，优先将模板下载到云真机进行还原，将「还原视频」与生产侧导出的「预览视频」进行比对，若对比结果一致，则认为功能正常，继续走人审检查模板的效果；否则直接将模板淘汰。
优化后的审核流程如下图所示：
模板上传至投稿库->机审测试模板的功能、性能、安全->人工检查模板的效果->将模板挑选至精选库->业务方将模板上架至推荐库
执行过程中发现PSNR的召回率高，但准确率很低（50%左右），即机审通过的模板一定是正确的，但机审失败的视频不一定就有问题。
为此我们使用cv算法来丰富图像比对策略，确保机审的准召率达到95%以上：
最终通过搭建机审系统，解决了审核人力不足的问题，支持日均审核1000+的模板量级
2.监控体系建设
当模板业务正式上线，需要观测业务的健康度，特别是核心链路的各项技术指标是否正常，因此我们建设了模板全链路的监控体系。
根据模板的生命周期细分核心指标：
● 模板生产侧：模板导出成功率 & 耗时、模板上传成功率 & 耗时
● 模板分发侧：模板封面加载耗时
● 模板消费侧：模板下载成功率 & 耗时、模板还原成功率、稿件导出成功率 & 耗时
数据下钻遵循几个基本原则：
1. 成功率指标：
a. 准确性：触发=成功+失败+取消，偏差不超过0.1%
b. 细分错误码，溯源造成失败的原因
c. 细分场景 & 类型，例如记录模板分类：游戏大片、图文模板、UGC模板等
2. 耗时指标：
a. 明确从触发到完成的最短路径
b. 细分场景 & 类型
监控方案上（实时 or 离线表），对时效性要求没有那么高，因此选择了离线表的方式（Hive，H+1）
最终建设的看板示例如下：
四、发展
1.视频模板的垂类衍生品
随着视频模板的基础建设落地，我们结合B站生态 & 热门垂类做了更多的尝试，比如王者战报、原神活动、心情日签等
这些尝试的底层均依赖了模板协议，上层进行业务差异化处理，比如高光识别、智能填坑。下面是一些案例展示：
2.视频模板的未来在哪里
B站的消费生态以优创为导向，高播稿件往往意味着PUGV & OGV
而移动端剪辑工具的定位更多是用来提供效率 & 创意向的视频剪辑手法，生产的内容以轻创为主（如果拿稿件时长衡量，轻创通常集中在3min以内），模板便是其中的典型案例
从业务视角看，很多人可能都有类似的困惑：模板=轻创=低质？
不可否认，模板确实存在内容同质化的问题。但从成长路径的视角，模板除了起量的优势，还可以作为up成长的敲门砖，配合任务 & 激励，可以培养出更多优秀的up主生产优质内容。
从技术视角看，模板代表着剪辑更多的可能性，目前部分竞品已实现了云草稿等商业化手段。不论是云草稿还是端云协同，都离不开模板协议的支持。
关于模板，关于B站的视频创作，用一句话来表达我的心声：道阻且长，行则将至；行而不缀，未来可期。
