2025 B站春晚直播——极速流式直转点在春晚项目中的实践

项目背景

2025年春晚是公司的年度大型直播活动，在常规的直播之外，直播结束之后转出点播稿件的耗时，也是一项重要的竞争指标。根据运营团队同步的信息，一些竞品可以在10分钟之内，将超过4小时的直播内容转成点播稿件。

视频云当时已经存在一套快速直转点系统，用于赛事大型活动的快速转点播，但是在生成超过4小时内容，需要至少40分钟，与业务需求的10分钟内差距较大。所以，技术团队以此为目标，对直播转点播的链路进行了整体的升级，同时，这也是新一代流媒体基建系统在线上大型活动下的首战。在春晚当天，4小时40分钟的晚会内容，在约8分钟完成了点播稿件的生产，相比优化前实现了约5倍的加速，达成业务目标。

问题梳理

最长路径

对于加速类的问题，对未优化流程进行最长路径分析，并在各个环节找到优化点，是最有效的解决方式。在直播转点播的场景的最长路径如下：

末段点播转码

为了不浪费整个直播的时间，直播转点播的转码都会与直播同步进行。而点播转码由于其侧重点在压缩率与画质上，而非速度，往往需要对直播进行分段录制之后，在分段上进行。当直播结束时，最后一个分段的速度越快，意味着点播转码的速度越快，当编码速度无法显著提升的情况下，尽可能缩短分片长度是提速最直接有效的优化方式。

运营后台剪辑

一场直播中并非所有内容都适合放入最终的点播稿件中，所以需要由运营人工接入进行判断，并裁剪时间轴。同时，大型活动往往存在卡段剪辑的需求，人工操作不可避免。让人工剪辑越准确快速，就意味着点播稿件可以尽快生成。老后台由于各种历史原因，方案很重，优化空间较大。

点播稿件生产

运营完成剪辑之后，点播稿件生产需要流转整个点播稿件生产流程，在直转点的全片上施加裁剪，生产占位原片，格式转换等多项媒体处理，生成符合点播要求的音视频产物。在我们的评估中，这一部分在全流程中占比最大。

FLV-->HLSv7

原先的直转点系统成型于3~4年前，设计的出发点是尽可能复用当时已经较为成熟的点播转码系统与相关生产流程，随着近几年点播业务体系的演进，当时看起来合理的选择，已非最优解。其中最为核心的，是流程中媒体格式的选择。

原先的直转点流程，媒体格式选择了FLV，这是当时点播转码体系下的主要格式，且与直播RTMP有较高的契合度。

随着近几年各种新codec以及HDR等技术的引入，点播播端逐渐转向以DASH，生产流程使用FLV，带来了较大的格式转换，当遇到超长内容时，这部分的转换带来的成本也较为显著。

直播的RTMP录制FLV的系统采用3分钟一段的录制粒度，为了让直播转点播的流程加速，需要在直播录制时，将录制分段的时长尽可能缩短到秒级，但这套系统游离于主线开发路线之外，代码陈旧，难以迭代优化。

最后，FLV本身并非是一种分段格式，浏览器上没有较为成熟高效的分段FLV播放方案，而这又是预览所必须的。所以原先的剪辑后台在进行剪辑前，需要将各个FLV转码分段下载到浏览器中。在面对接近5小时时长的内容，就算是使用码率最低的360p的转出清晰度，也需要加载接近1G的内容，这一过程耗时巨大，同时如若当时网络环境不佳，加载失败，重复加载将意味着更大的时间浪费。

HLSv7可以较好的解决上面提到的各种问题。

首先，HLS本身就是一种基于分片的流式协议，与直转点场景契合度较高。其中音视频的容器使用了fmp4（Fragment MP4）格式，可标准化地支持各类新Codec、HDR等新技术，在直播体系中已经实现大规模业务应用。

流媒体HLSv7体系内，已经存在一套基于HLSv7的录制系统，录制数据流与业务系统都较为完备。直转点转码采用相同格式输出，可作为另一种直播录制，复用大多数现有录制系统的更新、管理、查询等业务逻辑，实现快速接入。

同时在进行源流HLSv7录制时，可以实现秒级的单GOP录制，并对外通知。在转码侧实现了基于秒级分片的转码之后，转码速度可以有极大的提升。

最后，浏览器上有较为成熟的hls.js项目，提供准原生的播放能力，在面对超长内容时，只需加载一个m3u8播放列表，无需加载整个视频文件，这对于操作后台的开发，还是运营同学的操作也都更为友好。

技术方案

新直播录制系统

直播录制系统是新系统中的数据核心交换中枢。由于需要实现秒级的直播录制，且对接的新直转点转码系统也会以秒级频率与直播录制系统交互，同时其又需要面对直转点后台剪辑的请求、稿件生产中的请求，其服务QPS是关键指标。

新录制系统与新流媒体服务器Transmition之间简化了交互协议，内部的录像上报、外部的查询和服务都基于m3u8来进行。对长m3u8列表进行一定的分片之后，将相关信息存入数据库。由于一个m3u8列表中已经含有大量的分片信息，这部分数据可以从数据库中卸载出来，让新录制系统的对外服务能力（QPS）得到了显著提升，可有效应对新转码系统基于小分片频次的大量录像请求。

此外，直转点转码需要在m3u8分片之间进行精准地衔接，这是之前录制系统不需要处理的需求，新系统在原有查询的基础上，实现了基于m3u8 media sequence的衔接，保证转码的输入端能获得正确的录制视频数据。

新直转点转码

点播转码系统是视频云中历史较为悠久的老服务，现行的转码系统基于状态机驱动，状态存放于中间件之中。转码的各个步骤的执行是过程化的，一旦启动，再响应外部请求实现困难，同时，调度器与执行器之间的耦合较重，开发难度大，在面对新时代的各类媒体处理需求时，显得力不从心，亟待一次架构更新。

流媒体在更早的时间点，就已面向这些新媒体处理需求，规划了新一代转码系统，其中基于短分片的极速转码也是规划中的重点feature之一，本次春晚项目，是发挥该项特性最为合适的业务场景，也是新转码系统的第一个业务落地场景。

系统工作模型

对于一个分布式转码系统，我们从最大并发，最快速度的角度出发，设计了如下的系统工作模型，并以此作为主要的实现目标。

这一模型设计是基于如下观察：

多个媒体处理操作之间的数据依赖是局部的，也即，允许后一处理，在前一处理得到部分结果之后就立刻开始。
单个媒体处理操作，输入和输出之间的数据依赖也是局部的，也即，单个媒体操作完成部分处理之后，即可对外同步结果。

这一工作模型将两者进行了结合，在同一架构下同时获得3种高性能特性：

单一计算横向并发
局部IO与计算并发
多阶段流水线并发

此外，单一计算的横向并发，可以在单个计算调用中处理的分片数目，单独调节，动态适应于各种资源供给场景，且不影响另外两点特性获取收益，比如，在资源供给不富裕的场景下，可以选择单次计算调用，处理多个连续小分片，降低任务级的总资源需求与并发压力，同时还能获得加速。而在春晚这样，提供重点资源保障的场景下，则可以选择单次计算调用只处理单个分片，并极限缩短分片的长度，实现可用资源的最大化利用，追求最高的性能。

事件驱动的m3u8代理

新转码系统是面向通用的媒体处理而设计的，我们希望新系统具有一定的模块化特性，能通过小的元系统组合而成，故而，在多个计算之间的分片通信和数据交换机制就是系统的重中之重。

由于媒体协议围绕HLSv7展开，使用m3u8列表，在系统各个节点之间同步分片信息是最匹配的选择，有大量现有的标准化媒体IO的能力，可以复用。但是在分布式节点之间传递m3u8列表在实现上，还需要解决如下问题：

首先，m3u8有2种标准化的更新方式。局部更新主要应用于直播播放场景下，最新的m3u8文件中只会包含最新分片几其之前几个分片的信息。全局更新的差异在于，最新的m3u8会包含从开始到最新的所有的分片信息。在转码场景这种，我们只能选择全局更新，主要原因是：

不同转码用来存储的中间文件的分布式存储会有业务策略与类型的差异，访存与媒体处理的实现需要解耦。如此，访存逻辑很难获取到媒体处理内部的分片进度，只更新部分分片会有丢分片的风险，而这对转码来说是不可接受的。
系统主要服务于点播场景，存在异常恢复，分片复用等业务需求，只有全局更新才能满足这些需求。

在如何执行全局方面，最直观的做法是，生产端对每一个新分片都更新m3u8，并上传到分布式存储上进行覆盖，在消费端，按照一定的间隔轮询从分布式存储上读取m3u8，获得新分片的信息。这样的做法简单清晰，却存在如下问题：

分布式存储系统的稳定性风险

在海量小分片的场景下，在分布式存储上会生成海量的、同名的小文件。在消费端，由于并不了解生产侧的状态，并不保证每次读取都会获得新的分片信息，这种读取是盲目的，这些都会对存储系统不友好在业务扩量时，很容易对存储系统造成冲击，影响其稳定性。

通信效率低

由于使用全局更新，每次传输的m3u8会包含之前的所有历史分片，存在大量信息重复发送的情况，真正有效的通信数据占比，会随着进度的推进逐渐劣化。

为了解决这些问题，我们基于流媒体存算团队研发的OpenBayes快速计算平台，设计实现了事件驱动的m3u8代理机制：

首先，我们基于OpenBayes提供的Ray Actor组件，实现了轻量化的分布式队列，这种队列拥有一些对系统实现非常友好的特性：

易共享

两个媒体计算流程通过传参，即可建立点对点的连接，让计算流程，在启动之后不再是无法对外响应的孤岛。

本地化

队列资源都由计算集群本身提供，避免外部依赖，也提供了理论上胜过中间件的通信效率。

生命周期管理

其生命周期被一套引用计数管理，当队列两端的计算结束，队列和对应的资源也一并被回收，无需业务管理。

这是一种非常强大而灵活的机制，未来有大量的想象空间，而现阶段，我们借此，实现了分片生产与消费之间的消息同步。

消费端通过消费消息队列，触发分片下行同步，可以做到生产一片，同步一片的高效协同，避免了对存储系统上对m3u8的反复、盲目的读取。
当新的输入分片完成同步后，会在计算节点本地的m3u8副本中更新分片，本地副本用于承接媒体计算组件对m3u8的高频轮询，减低媒体处理的响应延时，同时避免对分布式存储造成高压力。
在媒体计算输出一个分片后，分片的信息，仍以消息，通知关心的下游，在非必须更新m3u8的场景下（绝大多数场景下），在媒体处理过程中可只上传分片，在处理完成后上传一份完整的m3u8，从而避免在存储系统上产生海量、重名的小文件。
在队列中传递的都是新生成的分片信息，历史分片信息由代理的本地m3u副本提供，通信效率无劣化。
计算节点上，所有的媒体计算组件都只访问由代理托管的本地m3u8进行读写。媒体计算与访存之间实现完全的解耦。

在本次春晚的极速直转点中，从录制系统中获取到的新分片、音视频数据清洗、重组、音视频分离、音视频转码、转码产物合并的每一个步骤都通过这一机制互联，实现了全链路，各步骤高效的事件驱动与协同。同时，依托OpenBayes高度灵活的编排能力和高性能调度，进一步提升系统整体的吞吐。

针对快速直转点本身，转码系统会对最终产物，重新按照5秒再切片，尽可能提升在HLS上剪辑的精度。同时协议上与快速直转点业务主控服务系统，实现了直播录制上报的协议，以5秒分段的频率，向直播录制系统上报，让剪辑后台可以尽早获取到新的转码产物，早预览，早剪辑。

音画同步保障

音画同步一直是分布式转码的挑战，一般来说，切分片越多，出现不同步的概率会越大。为解决这一问题，我们通过若干个媒体组件和相关配套建设，避免这一问题。在新转码系统中，收到的音视频内容的组件会经过时间戳清洗、包重组和重切片，对于源流中的异常时间序列进行重排或修正。在此基础上，后续的所有操作，包括转码、合并、重切片等，都采用对齐修复后源时间轴的方式控制时间戳。这套方案除了在新转码系统实现之外，在基于老架构的点播的流式转码项目中也先行进行了部署和上线，在春晚前，已得到较长时间和过较为完善的验证。故而本次春晚，我们有更大的信心，保证在片源音画同步的条件下，无论转码多长的内容，切成多少片转码，都不会出现音画不同步。

新直转点后台

新直转点后台保留老后台的绝大多数功能，针对媒体预览和剪辑这两个核心功能，面向超长内容剪辑需求，进行了较大的优化。以下二图为预览剪辑操作区域新老后台的变化。

老直转点后台预览部分

新直转点后台预览部分

可以看到，在面对超长内容时，新后台不需要像老后台那样，人工选取大量的转码产物分片，也不需要专门的"加载"操作。页面长度显著缩短，所有视频剪辑的操作可以"同屏"进行。依托HLS协议和hls.js播放器，后台页面省去了之前大量分段播放flv的代码，新播放器即使面对十几小时的内容，也可以实现"秒加载"。

在此基础基础体验得到保证之后，新后台增加了大量与时间轴展示、时间轴控制、直播精度追赶的操作按钮，无论是剪辑卡段还是全片内容，操作效率都显著提升。操作的运营同学可以在先固定剪辑起始时间的情况下，不断点击"刷新直播流"，结合转码的小分片级上报，可以让预览紧追最新的直播转码进度，在需要成片时，直接选定结束时间，生成分片即可，实现极速剪辑。

新直转点稿件生产系统

之前提到过，点播体系从FLV转向Dash之后，生产流程引入了多次媒体封装格式转换，这种转换虽然消耗的算力不多，但是对IO的负担较重，对于超长内容进行多次转封装的时间成本已不可忽视。

在老流程中，生产流程需要先获取到剪辑所需分片，根据剪辑的起止时间裁合并裁剪出对应的FLV产物，之后会对FLV再转成Dash，生成点播清晰度的各个产物。同时，由于稿件生产流程是由稿件原片驱动的，为了尽可能兼容稿件生产的上下游系统，快速直转点流程也需要一个占位原片，这次原片的生成与一次剪辑的耗时是接近的。

在这种情况下，全链路速度最快的实现方式需要做到2点：

1）原片生产与点播各个清晰度生产同时进行

2）各清晰度稿件生产跳过FLV，直接输出DASH

在这一过程中，流媒体点播业务团队对稿件流程完成全并发改造，并完善了相关的数据监控与可观测性建设。流媒体组件团队为该功能，先于ffmpeg社区实现了正确Seek m3u8的能力，同时支持直出dash的onDemand Profile功能，做到了两次本地IO读写，完成剪辑、分片合并、音视频分离、输出Dash 4个步骤，让整个稿件生产的流程成倍提升。

生产保障

春晚活动本身的分量以及大量新系统需要在这样的重大活动中上线，我们在保障工作上必然不敢松懈。主要分项目开发阶段和项目执行两阶段规划保障工作。

项目开发阶段

鉴于有大量新系统，项目开发阶段保障工作最重要的目标就是发现问题，而整个流程较为冗长，不能完全依赖测试同学。所以，我们与项目开发过程中，同时积累了两项基础验证能力：标准化播放网关与自动音画不同步检测。

标准播放网关

线上播放器与业务深度定制集成，投稿视频必须完成完整的生产审核流程才能在真实环境中验证播放效果，这个过程较为繁琐。目前后端接口提供的调试能力有限，不利于开发人员快速迭代测试，而单纯依赖本地测试又无法验证浏览器兼容性等问题。为解决这些问题，我们开发了一套标准播放网关，能将数据库中的结构化元数据通过模板转换为 mpd 文件并生成 playlist。我们还与播放器团队协作，专注于核心功能验证的精简版 player，建立了规范的调试流程。这套方案不仅支持测试未公开状态的稿件及其不同清晰度，还可以实现音视频清晰度的自由组合测试，显著提高了调试效率。

自动化音画不同步检测

音画同步一直是分布式音视频生产过程中的一项挑战，而新快速直转点转码又是基于海量小分片进行转码，产生音画不同步的风险会更大。虽然新转码系统为此有过专门的优化，但是仍然需要较多case验证，同时，整个稿件生产并非只有转码一步，链路上任何操作都有可能引入不同步，其又是影响体验的关键因素，需要重点验证。同时音画同步又是所有媒体处理的常规要求，无论是为了本项目还是之后的开发，自动化地音画不同步检测都有很高的价值。

常规音画同步检测是开发人员肉眼观看产物是否音画同步，这个方法耗时且不利于开发人员快速迭代测试。基于转码操作不会改变场景变化时间点原理，我们开发了基于场景变化检测转码产物和原片音画同步的功能，并将其应用到新快速直转点平台投稿流程中，协助新快速直转点平台快速定位排查异常时间点和转码问题。新快速直转点平台录制投稿并且稿件开放完成之后，会自动化触发后台服务的音画同步检测任务，在音画同步检测完成之后，如果音画不同步则会自动向预设对象(如群机器人)发送音画不同步检测结果。

项目执行阶段

对项目验证最好的方法无疑是投入线上实战，由于开发进度得力，项目上线时距离春晚还有一段不短的时间，除了很早就involve当天实际操作剪辑的OGV同学，我们得以有机会邀请游戏赛事运营的同学在生产环境实际试用我们的新系统，同时老的系统作为兜底备份，保证生产安全。在这一过程中，我们根据试用的反馈意见持续打磨系统，提升操作便利度，解决诸如反复断流等边缘case，直至春节前一周封板前。

在春晚当天，我们在资源与流程2个维度做了专门的保障主要包括：

直播流3备份，3路同录，同转，都可以剪，都可以投稿
直播录制从边缘到中心准备3路传输，保障录像获取高效稳定
OpenBayes专项集群保障，集群在除夕前进行了重置，恢复到最佳状态。
保障群、机器人通知、业务监控大盘、故障处置SOP等

总结

最终项目执行的优化加速效果如下图：

老系统项目	预估耗时	新系统项目	实际耗时
常规转码	6分钟	极速转码	约30秒
运营后台操作	5分钟	新后台操作	小于10秒
合成点播虚拟原片	10分钟	合成虚拟原片	0秒
合成点播FLV	10分钟	合成点播DASH/MP4	7分14秒
合成点播DASH	10分钟
总计	41分钟	总计	约8分钟

相比优化前，我们获得了约5倍的加速，完成了这次"大考"。在这一过程中，以实际业务，验证了新一代流媒体基建系统。之后，我们面向大型活动之外的日常快速直转点工作，规划并执行了多项后续开发工作，

进一步从稳定性、易用性和性能提升系统能力，推进新一代流媒体基建的建设、迭代与应用，支撑业务的持续发展。

-End-

作者丨老王、彳亍口巴、岛民阿强、Francis、红帽子、黑桐、JerryTang、杰克欧、小辉辉、小邢、尹壮、Judy、静希