背景
视频转码系统是B站视频处理最核心的系统,其主要功能在于:
- 统一格式,提升视频播放兼容性;
- 从原片输出不同的清晰度,满足不同场景的播放需求;
- 通过使用不同编码算法和技术,控制播放带宽成本。
视频转码是一个IO和计算密集型任务,其过程较为耗时。为了保证创作者的投稿体验,降低转码耗时是技术团队需要一直追求的目标。从优化大方向看,降低转码耗时可以分为:提升物理(CPU和网络)性能、提升编码器性能和优化转码架构。
整个技术团队更关注通过优化转码架构来加速单任务转码过程。因此,在B站第三代转码体系下引入了流式转码,以解决同稿件下多条转码任务的重复切片问题、转码临时产物大文件导致的耗时问题,以及非必要的IO和算力开销问题。

测试视角架构和质量保障规划
转码架构
流式转码的整体架构涉及较多技术模块。稿件进入转码系统后,从业务编排到标准生产会经历多条生产链路。在不同链路中,处理过程包括视频元数据计算,并依次经过调度服务、切片服务、转码镜像以及最终的转码执行单元,从而完成一轮转码流程。 在测试视角下,可将复杂的系统抽象为简易框架图,以便于设计质量保障方案,如下:

质量保障规划
流式转码方案需要适配整个转码体系的多种转码链路,涉及的维度包括业务属性(参数定制、片源特征)、软硬编码(CPU、GPU、瀚博)、技术属性(窄带高清、前处理)等。因此,质量保障必须针对不同的技术目标进行精准设计。
同时,项目涉及多个研发团队协作,开发周期跨度较大。在完成阶段性转码链路后推进下一个里程碑节点时,必须考虑各模块在技术实现过程中对历史转码链路的影响。这一点在整个项目测试实践中极其重要。
整个项目测试期间,按照保障思路规划了四个保障工作方向:
- 稿件转码流程的影响与依赖分析;
- 各模块核心技术要点摸底;
- 高效准确的问题定位和排查手段构建;
- 多资源兼容性保障。
因为流式转码适配到生产环境后,将影响整个稿件处理链路。且B站点播业务当前日投稿量均达到百万量级,微小的问题也可能会被显著放大。因此,全方位的质量保障客观上存在极大的挑战。

核心模块测试设计
转码调度
业务的调度模块主要包括以下服务:
- bvcflow服务:负责业务通信和任务编排,管理稿件多任务转码的生命周期。
- hive服务:用于资源计算和任务派发。
- OpenBayes服务:作为全新的计算平台,支持更好的精细化资源调用和端到端的分布式计算。
站在测试视角,将围绕着调度链路,从功能测试和策略验证两方面着手。简易流程图如下:

功能链路测试
首先, 对整个转码调度链路采用基础的功能测试手段。测试从业务入口(投稿)开始,并区分了两种主干转码调度类型:transcode架构和xcode架构(两者在视频元数据处理上存在技术差异)。其次, 在主干转码链路中,根据任务类型适配不同的资源调度策略,确保功能链路测试能够覆盖核心流程。在功能链路测试过程中,通常会弱化对底层镜像和切片服务内部逻辑的关注,聚焦于端到端的验证断言。端到端验证断言主要分为以下几个阶段:
-
子任务节点产物和元数据断言(如时长、码率、帧率等);
-
主分支链路独立产物的播放验证;
-
生产环境中多终端设备的播放表现验证(覆盖多种清晰度及编码格式)。
调度策略测试
调度策略测试需要结合不同的转码业务类型进行针对性设计。在测试过程中,通过 hive服务进行任务分配以模拟不同场景,并对比新计算平台 OpenBayes 在任务调度和结果输出上的差异。例如:
- 通过并发创建长稿件、多分片任务,验证并比较响应时间差异;
- 统计异常状态发生次数,检验重试保障机制的有效性。
此外,针对不同视频特性进行策略测试,例如:
-
对二次转码(二转)中的 HDR 和 Dolby Vision(高码率、长片源)等高质量稿件执行多组耗时测试,并收集数据;
-
通过多阶段测试发现稿件整体耗时受分片策略影响,并据此最终调整出最优的分片调度策略。该策略有助于提高生产转码资源的利用率。

此外,在测试过程中,针对特定场景的策略测试还包括区分转码任务类型(CPU & GPU);基于软硬编码的参数差异和特性,进行一定程度的资源交叉测试。相应的验证断言也会根据测试目标有所不同,例如:
-
在窄带高清(窄带)策略测试中,重点关注输出码率控制效果和视频质量评估;
-
在前处理任务测试中,会融入与画质优化和成本控制相关的指标验证,包括CRF(恒定速率因子)值的偏移计算与补偿校验以及输出视频的PSNR(峰值信噪比)值评估等。

#crf 测试相关内容
#补偿公式验证(针对 OTT NB264/265 1080P)
def compensate_rate(predict_crf, max_crf, min_crf, control_crf, strength):
#补偿逻辑
... ...
return value
不同转码业务的策略设计存在显著差异。以窄带高清策略为例:在流式转码的分片机制下,其核心质量判定逻辑从原片单次判定(成功率 ≈ β%) 转变为 N 个分片任务的多次独立判定。此时,整体转码任务的最终成功率理论上会显著降低(可近似为 β%^N)。因此,针对窄带高清策略的测试方案需相应调整:优先选择场景内容简单、码率分布均匀的稿件进行验证。若不进行此调整,转码流程可能因该策略差异(即分片多次判定)与稿件自身特征(如复杂场景导致局部码率突变)的叠加效应,产生大量由客观因素(非系统缺陷)导致的失败任务。
切片模块
切片模块主要包含以下核心组件:
-
切片调度服务 (Slice Scheduler Service):负责对外通信、接收切片任务请求并进行任务分配。
-
状态机 (State Machine):作为切片调度服务内部的核心单元,其功能是管理异步切片过程中的状态流转。
-
切片 Worker (Slice Worker):执行具体的切片计算任务。
-
数据模块 (Data Module):使用常规数据库持久化存储切片任务的元信息。

切片调度测试
服务通信与初始化响应测试:
- 测试场景:模拟上游调度下发具体切片任务时的服务通信层初始化响应过程。
- 测试重点:高并发连接建立(并发建联)场景。
- 测试方法:通过并发派发批量稿件,并触发多种业务类型(如单分片切片、多分片切片) 的切片任务,验证服务在高负载和复杂业务混合条件下的处理逻辑健壮性。
分片处理效率与协调性测试:
- 分片生成速度(如:2分钟/片 vs 6分钟/片的耗时差异分析);
- 分片间边界衔接的精确性,(如:m3u8文件);
- 事件驱动机制下各环节(调度、Worker、状态机)的协调效率。
状态同步与幂等性保障测试:
- 机制:通过读取数据库(DB)中的切片元数据进行状态同步。
- 核心目标:实现高效幂等判定(关键性高:因多个下游转码任务可能依赖同一切片产物)。
- 测试方法:故障注入模拟典型问题场景:
a. 场景一(幂等校验绕过):伪造不同稿件包含相同内容片段的哈希值(采用MD5),导致系统误判幂等(校验通过),实际合并转码后产出内容异常的稿件。
b. 场景二(状态一致性风险):在切片状态机处理核心状态变更(如任务启动、完成) 时,强制读取数据库主库(Master),避免因主从(Replica)延迟导致读取到过期状态数据,进而引发资源调度错误或数据不一致问题。

切片worker测试
切片 Worker属于核心执行单元,通过从存算平台下载待处理的原片,执行具体的切片计算任务。单个切片任务最终由底层的切片二进制程序执行,该程序核心调用 ffmpeg 命令行工具完成实际的切片操作。切片过程涉及多种业务参数组合(取决于任务要求)。切片 Worker 测试策略是围绕切片特性和特殊稿件特征设计测试场景,包括:
-
基础元信息组合验证:媒体时长、文件大小、码率、编码格式等基础元数据的兼容性与准确性。
-
特殊场景专项测试:超长 GOP (Group of Pictures) 稿件切片:
a. Open GOP 结构稿件切片。
b. 动态分辨率/动态帧率 (VFR) 稿件切片。
c. 包含特殊音轨(如多音轨)稿件的处理。
- 切片输出完整性验证:断言切片数据完整性:
a. 校验关键帧 (I-Frame) 位置符合预期。
b. 验证时间戳 (PTS/DTS) 连续性,确保播放无画面跳跃或卡顿。
c. 比对切片基础元数据与原始文件的一致性。
- 切片产物处理与后续验证:
a. 按时间顺序将分片信息写入 m3u8 索引文件。
b. 上传分片文件至存算平台,供后续转码任务下载使用。
- 容错与健壮性测试:模拟 m3u8 文件内容错误(如:非法标签、错误分片时长、错误分片URL、文件缺失标记)。验证下游链路(如转码worker、播放器)的容错处理能力与整体系统的健壮性。

异常切片测试主要是边界场景构造与验证:
- 测试策略扩展除常规特殊场景外,主动构造复合型异常稿件:
a. 分辨率混合+GOP 不对齐: 合成不同分辨率的视频流,人为制造 GOP 边界未对齐,验证切片服务对多轨道 GOP 异步的兼容性,预防切片合并后播放卡顿或任务失败。
b. 异常 PTS(显示时间戳)模拟: 构造 PTS 头部负值或突发性跳变的测试片源,探测切片二进制对异常时间戳的处理逻辑(如:强制归零、时间戳偏移补偿、时间基重对齐)。
-
混合媒体类型探索: 横向组合 SDR/HDR、Dolby Vision 等特性,纵向交叉非常规元数据(如动态帧率、非标准色彩空间),模拟生产环境中可能出现的异构媒体文件,全面验证兼容性。
-
切片性能测试:效率与吞吐量评估。
-
单任务基准性能: 使用标准化视频样本(如:2 小时,1080p H.264 / 4K HEVC)测试单任务全流程耗时(从任务下发到分片就绪)。
-
多任务调度损耗: 在并发场景下,量化调度器交互产生的额外延迟(如任务排队、资源争用),关注多任务并行时的有效吞吐率衰减。
-
服务吞吐极限测试: 模拟高并发稿件请求,逐步提升负载直至服务性能拐点,记录切片任务成功/失败率
转码镜像
转码镜像核心组件:
转码调度服务 (Transcode Scheduler Service):对外通信,编排转码任务生命周期
转码 Worker (Transcode Worker):调用底层转码工具链(如FFmpeg、x264/x265编码器)
转码镜像的工作就是将多类输入的媒体按照统一的标准处理输出,可以参考通用标准的转码流程,如下图:

转码worker测试
在具体的转码worker的实例中,首先从存算平台拉取切片服务生成的分片(TS 格式)并解析业务透传参数组(分辨率、编码档次、版权水印策略)。
后续调起转码二进制模块进行处理。这点和切片模块有些相似,同样是对媒体文件进行一次二进制处理,因此测试重点也在资源场景设计上,对片源的多样构造策略和元数据污染模拟。
点播场景构造 | |
---|---|
文件类型 | 1kb/20g、超高/低码率 |
场景变化 | 拼接场景/动态分辨率/动态帧 |
音轨 | 空音轨/多音轨/异常音轨 |
边缘格式 | webm/flv |
动态范围 | 10-bit-高动态Hdr、vivid |
内核 | 抽I帧/B帧/长短gop/IDR帧 |
音画同步 | pts跳变 |
花屏/黑屏 | dts异常/负值 |
其他 | 头信息篡改等 |
由简入深,对于一些基础的转码测试,例如:探测镜像的帧处理逻辑,通过对分辨率的缩放、不同的色彩空间(YUV420、YUV444)、滤镜处理(多水印)进行转码前后播放效果对比测试。对于一些复杂的测试,例如:GOP测试场景下,我们将目标视频转码为 H.264 格式,使用开放式 GOP 和包含 3 个 B 帧的优化配置,固定每 60 帧一个关键帧。通过该场景可以验证出镜像对OpenGOP的兼容性,若结合输入的原片为快速场景变化的4K高清视频,同时还可以验证出是否会因为关键帧不足导致产物画质下降或单次编码效率低的问题,也可以通过转码产物在低端设备和老播放器上的兼容效果,进一步测试镜像底层算法的健壮性和兼容性。

由于待测的视频原片及设计的变种较多,测试效能上我们将自动化构建视频和自动化投稿转码结合,基于技术迭代和增量技术特性(例如:某实验版本新增去B帧操作),匹配生产出几组不同视频的变种场景,能快速验收转码产物和结果。

线上质量观测
流式转码接入B站转码体系后,由于技术层面进行了较大调整和优化,需对生产环境下的复杂情况进行长时间观察和资源的动态调配。因此我们针对核心指标进行追踪分析,便于持续迭代优化。通过观测核心流式转码业务的成功率,收集失败场景并定位处理,逐步提升兼容性。
另外,切片服务作为整个流式转码方案的驱动核心,虽然资源占比有所增加,但其任何小问题都可能导致切片失败或任务异常,进而影响下游多条转码任务,甚至触发降级逻辑延迟用户稿件发布。因此,我们会重点监控实际调度和资源使用情况,观察切片消息的生产与消费比例,确保流式转码整体质量处于较健康状态。

结语
B站第三代流式转码系统通过架构优化(切片复用、减少IO开销),显著降低转码耗时。测试团队针对调度、切片、转码三大核心模块,设计多维保障方案:功能链路覆盖全流程,策略测试验证性能与兼容性,极端场景模拟(如动态分辨率、异常音轨)确保健壮性,构建自动化生产视频应对海量投稿挑战,最终支撑百万级日投稿稳定运行。
-End-
作者丨也每