B站视频模板的前世今生

谭涛

本期作者蔡政和哔哩哔哩资深开发工程师一、前言1.创作的本质是什么从剪辑工具的角度，可以将创作拆解为主题、素材、剪辑三个要素主题：对应的品类 & 风格，比如游戏、影视、泛生活等素材：用户使用的视频、音频、图片等内容剪辑：对素材进行时间、空间、效果上的调整，比如裁剪、复制、滤镜、转场、特效等视频模板恰好覆盖了创作的三个要素，限定「主题」和「剪辑手法」，允许用户填入部分「自定义素材」，降低用户创作门槛，实现B站的供增需求，从而辅助达成用增的目标2.B站视频模板的迭代历程竞品使用视频模板完成了大规模的起量，B站也在该领域进行不断的探索和迭代，除了字幕、特效、贴纸等基础剪辑能力，还实现了AI绘图、3D运镜等高阶功能，相较竞品支持更多的垂类玩法。2.1. PGC vs UGC从模板生产者角度，可以将视频模板分为PGC和UGC两种类型：PGC视频模板：使用定制工具，由内部设计 & 供应商制作模板UGC视频模板：使用必剪APP，支持所有用户制作模板下面是PGC和UGC模板的优劣对比PGCUGC产能（个/日）6-10600成本（元/个）200035原子能力（高、中、低）低高效果（高、中、低）中高2.2. PGC to UGC从21年-23年，我们持续完善了视频模板的协议，并将其从「PGC生产模式」逐步迁移至「UGC生产模式」模板类型品类生产模式面世时间片头模板不限PGC2020年12月游戏大片游戏PGC2021年7月图文模板泛知识PGC2021年12月虚拟形象成片虚拟PGC2021年12月视频模板不限UGC2022年7月目前在B站多款应用中（粉版、必剪）已落地了UGC视频模板功能，效果如下图：二、实现1.生命周期 & 工作流在实现视频模板之前，首先需要了解模板的生命周期，从而设计出一套合理的模板生成 & 解析方案一个模板从诞生到消费成稿件，包含5个阶段：生产、审核、分发、消费、投稿生产：用户使用必剪编辑器，对素材进行剪辑操作，生成模板并投递至素材中台审核：在素材中台对模板的效果和能力进行人工 & 机器审核，将满足要求的模板pick至模板推荐库分发：根据用户画像、模板消费等信息将模板分发至不同的应用 & 人群消费：用户使用模板，填充自定义素材并进行二次微调投稿：用户将微调后的编辑器草稿投递稿件，生成作品基于生命周期，梳理模板的工作流程，如下图所示：?2.架构设计工程框架角度，将视频模板分为三个层级：业务层、通用业务层、基础组件层业务层：负责独立业务，如模板配置页、模板Feeds流等，不同业务有各自的实现通用业务层：业务相关，向上层业务输出通用能力，如主编辑器引擎、上传组件、模板协议等基础组件层：业务无关，向上层业务输出原子能力，如剪辑SDK、推理引擎、ASR服务等?3.协议规约明确了工作流 & 工程架构，我们会发现在整个模板生命周期中，有一项内容贯穿始终，那就是「模板协议」模板协议是限定「主题」、「素材」和「剪辑手法」的主要手段，它告诉我们一个元素应该在什么时间、以哪种方式、出现在什么位置对于模板协议，需要具备三个特性：支持跨端：支持在Android、iOS、PC、Web、后端等各平台生产 & 解析协议数据可拓展的：支持新增字段，向前兼容（老版本应用支持解析新版本协议）易于传输：支持序列化 & 反序列化，压缩率高（IO读写 & 网络传输快）3.1.JSON vs Protobuf很多数据序列化的方式都拥有「支持跨端」和「可拓展」这两个特性，比如：XML、JSON、Protobuf，在这里列举下我们选择Protobuf的理由：JSONProtobuf语言中立（Language Neutral）√√数据压缩率（Data Size and Efficiency）×（文本类型，压缩率低）√（二进制类型，压缩率高）编解码速度（Encoding/Decoding Speed）×√可读性（Readability）√×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. 模板支持的多媒体格式多媒体类型封装格式编码格式视频MP4、MOV、WMV、M2V、MPGH264、H265音频MP3、FLAC、AAC、M4A、WAVMP3、AAC、PCM、FLAC图片JPG、PNG、GIF-4.2. 本地转码规范针对「本地素材」，为了节约上传带宽和存储成本，因此在模板打包前需要优先执行一次转码操作：多媒体类型封装格式转码规格视频素材MP4视频轨道裁剪视频时长（若视频做过Trim操作）编码：H264分辨率/帧率：保持不变VBRSDR音频轨道裁剪音频时长（若音频做过Trim操作）编码：AAC音频素材M4A裁剪音频时长（若音频做过Trim操作）编码：AAC4.3. 视频云转码规范为了进一步降低存储和下行带宽，在云端针对「本地素材」进行二次转码操作：多媒体类型封装格式转码规格视频素材MP4视频轨道编码：H264帧率/分辨率/颜色空间：保持不变CRF 25音频轨道编码：AAC码率：128k音频素材M4A编码：AAC码率：128k图片素材（仅压缩JPG）JPG质量因子：0.84.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模型->reProcess->引擎数据模型PreProcess设计如下：通过PreProcess机制，我们拓展了很多本地剪辑SDK不支持的异步效果（AI绘图、3D运镜、高光识别等），这也是视频模板拓展垂类玩法的核心策略。?6.模板组件化建设为了将模板业务横向输出至必剪、B站等多个平台使用，在第2节模块分层的基础上，我们还使用flavor x 插件化的方式重构模板业务，并针对不同宿主实现按需依赖：main（蓝色）：所有平台集成bcut（黄色）：仅集成至必剪APPbilibili（粉色）：仅集成至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站的视频创作，用一句话来表达我的心声：道阻且长，行则将至；行而不缀，未来可期。以上是今天的分享内容，如果你有什么想法或疑问，欢迎大家在留言区与我们互动，如果喜欢本期内容的话，欢迎点个“在看”吧！往期精彩指路bilibili-AVIF图片格式落地B站移动端低代码测试探索与实践必剪Android项目组件化最佳实践