从种草到世界杯，小红书的技术实力藏不住了

编辑｜杜伟

「比赛已经结束，球迷还在等 4K 回放。」

这是四个月前，小红书首次以世界杯官方持权转播商的身份，站到 2026 美加墨世界杯台前时，面对的真实考验之一。

小红书这个以内容分享见长的社区，首次承接世界杯转播，就要直面海量观众集中涌入带来的流量压力。「世界杯的观播量是小红书直播日常流量的 50 倍以上，互动量更是超过了 100 倍。」

如此庞大的观赛需求对小红书多媒体团队提出了严苛的要求。

直播侧既要在千万级并发下保障稳定运行，也要兼顾高画质、低延迟与多终端的播放体验；回放侧需要大幅提升 4K 转码效率，让错过直播的球迷尽快看到高清回放。

面对这场大考，小红书实现了多项突破：直播消费码率提升约 50%，端到端延迟降低约 30%，4K 增强回放转码提速近 60 倍。而要同时改善画质、延迟与效率这些指标，需要在整条音视频处理链路中寻找平衡。

足球直播

要过画质和延迟两道关

足球直播对画质算法的要求，远比把一张静态图片处理得清晰更复杂。球场上的一次高速反击，镜头会同时扫过密集的草坪纹理、快速移动的球员以及场边广告。插帧稍有偏差，人物边缘就可能出现重影。超分增强不稳定，草坪细节会随镜头移动忽强忽弱。不同球场的明暗和球衣颜色，也会增加色彩处理的难度。

直播又限制了算法等待数据的时间。参考更多帧有助于判断运动，却可能增加缓冲。计算速度跟不上输入，队列便会持续积压。提高码率虽然能够保留更多细节，但也会加重分发和弱网播放压力。

赛事直播从信号制作、云端画质增强与转码到终端播放的完整链路。

多媒体团队选择将超分与画质修复结合，在增强细节的同时处理输入中的噪声和编码瑕疵。时序因果模型参考历史帧的运动信息，减少增强后细节闪动。另外，面对草坪等敏感区域，根据内容调整增强强度，抑制呼吸效应。计算方式也围绕低延迟展开。单帧图像被切成多个块，交给多张 GPU 并行推理，无需等待多帧画面集中处理，减少超分引入的额外延迟。

插帧模型使用足球场景数据进行专项微调，重点处理急停、切镜以及台标和记分牌等叠加元素。系统仅依赖已到达的帧进行处理，避免等待未来帧带来的额外缓冲，并对插针过程中可能出现的鬼影、画面破碎等异常情况展开优化。

色彩增强采用内容感知型局部色调映射。阳光下的草坪与背光看台同时出现在画面中时，算法会针对不同区域调整增强强度，改善明暗反差；对于颜色鲜艳的球衣，避免色彩过度饱和，同时对人脸区域进行保护，让人物看起来更加自然（下图左）。球场边线还有一类问题：镜头移动时，原本平直的白线边缘不断闪烁、抖动，看起来像锯齿（下图右）。多媒体团队使用时序修复模型参考历史帧的运动趋势，并在修复前增加场景检测，只对需要处理的画面启用相应算法。

画质算法之外，信号接入、演播制作和播放器缓存也会产生等待。减少总延迟，需要先测清楚同一帧在各环节停留了多久。多媒体团队通过网络时间协议（NTP）对齐可控设备的系统时钟，在演播输出编码链路中利用补充增强信息（SEI）携带时间锚点，使时间信息随视频帧进入转码、分发和终端播放。测量时还需识别各环节对应的同一帧，确保设备时钟对齐，必要时校正时钟偏差，这样才能准确计算视频在不同环节的处理和传输延迟。

基于 NTP 时钟对齐与 SEI 时间锚点的直播延迟测量框架。

具体到演播联调侧，专业编码设备的输入到输出延迟一度超过 1.2 秒。排查发现，较大的编码预分析配置和较高的编码复杂度增加了处理耗时，造成队列积压。调整后，同帧编码处理延迟降至 400 毫秒以内，平均码率与图像组（GOP）保持不变，主观评测确认画质持平。云端通过异步算子设计和编码器缓冲调优提高吞吐，保留应对输入抖动的处理余量。多项增强与编码串联后，云端处理延迟稳定控制在数百毫秒

播放器侧根据带宽、网络类型以及码率与带宽比，联合调整启播水位、最大缓存及追帧参数。单独缩小缓存会增加卡顿风险，需要结合不同网络和机型进行灰度验证，出现异常时回退。协议选择也保留了兼容与容量上的余地，其中 HTTP-FLV 作为主链路，复用成熟内容分发网络（CDN）的覆盖能力；符合网络、机型和版本条件的用户使用实时通信（RTC）低延迟链路。

上述一系列优化最终达成了「直播消费码率提升约 50%，端到端延迟降低约 30%」的效果。这也说明，高画质和低延迟之间的取舍，并非只能依靠牺牲其中一方来完成。

三周极限交付

扛住千万级并发

直播画面的清晰度和实时性有了保障，承载这些画面的直播间还要经受更大考验。开赛前后，大量球迷会在短时间内集中进入直播间。比赛开始，评论、礼物和赛事玩法又带来持续的交互请求。这些功能与视频播放运行在同一个页面上，彼此存在交互，一处改动可能牵动多个模块。

更紧迫的是，留给小红书直播客户端团队的交付时间只有三周。他们需要在这段时间内完成数十个需求，并为千万级峰值并发做好准备。

直播客户端团队利用组件化将礼物、评论等业务拆成独立模块，模块内再进行数据与 UI 分层。组件通过标准服务接口输出能力、声明依赖，框架约束初始化、服务注册与获取的先后顺序，减少模块加载时机不同带来的调用问题。另外，动态化用于缩短等待版本覆盖的时间。交互较复杂的二级面板和弹窗使用 React Native，对首帧敏感的卡片与常驻挂件使用轻量 DSL。

模块化拆分与数据、UI 分层架构。

功能按时交付，只是第一道关。开赛前后观众集中进房，考验资源加载效率与服务端的并发承载能力。设备没有缓存赛事特效素材时，下载请求可能同时涌向 CDN。直播客户端团队选择将部分预加载安排在 App 启动或上一场结束等时机，再配合下载间隔和请求随机打散，让下载动作尽量避开峰值。

每项功能还配有服务端接口控制、客户端止损开关和核心接口限流。进房链路支持接口与即时消息（IM）双降级，必要时通过 SafeMode 裁剪非必要请求；长连接异常则采取隔离措施，防止单条非法消息影响主流程。相关降级预案均在赛前完成演练，赛中调整通过配置完成，无需临时发版。

直播信号的传输与处理链路也建立了独立的容灾机制。接入层支持主备切换，源站通过跨云互备降低单点故障风险，转码环节配置主备冗余，CDN 则采用多厂商并行分发与调度。这部分保障与客户端的功能开关相互配合，分别处理媒体链路和页面业务中的异常。

直播客户端的稳定性防线及对应手段。

扛住开赛前后的流量高峰，接下来还要让用户稳定看完整场比赛。比赛持续进行，设备负载也会变化。直播客户端团队通过长时间仿真压测观察内存累积与热节流，再从基础播放逐层叠加互动、礼物和新功能，定位主要开销。结果发现，互动业务层是重要的性能压力来源，中高端机型长时观播也可能进入热节流。

相应降级按体验价值安排：基础播放和用户自己的操作反馈优先保留，其他用户的高频点赞、弹幕动画与特效适当限频。设备压力继续增加时，再关闭部分动画或裁剪非核心功能。对应策略下，CPU 负载和设备升温得到有效缓解。

不同降级措施的恢复方式也有所区别。限频策略会根据运行状态实时调整，一旦触发关闭部分特效、动画等有损降级措施，本场观看期间便保持该状态，避免设备温度在阈值附近波动时，相关功能反复开启和关闭。

直播间体验价值分层与降级顺序。

面对紧迫的交付周期和高并发压力，直播客户端团队保证了直播间的稳定运行。

错过直播

同样享受 4K 流畅回放

直播需要实时处理不断到达的画面，比赛结束后，多媒体团队又要与另一种时间压力赛跑：一场完整比赛的 4K 增强转码，可能需要耗费远超比赛本身的时间。

美加墨与中国存在约 12 到 15 小时的时差，不少比赛落在北京时间的凌晨或上午。对于无法熬夜、需要上班的球迷，赛后补看是重要的观赛方式。相比直播，回放可以使用计算量更大的离线模型，修复更多细节；处理效率也必须跟上，才能让错过直播的观众尽快看到 4K 画面。

超高清增强是第一步。多媒体团队将超分、插帧与 SDR + 色彩增强算法接入点播媒体处理引擎，以滤镜模块的形式组成增强链路。编码环节结合自研的高压缩编码与通用兼容编码，输出不同清晰度的回放视频，包括 4K/50fps 超高清、高帧率档位。

回放增强前后的边线细节对比。

4K/50fps 增强转码的计算开销尤其大，单个视频片段的处理耗时高于切片、传输和拼接等固定开销，因此适合通过并行计算提速。多媒体团队先利用单机多张 GPU 并行处理同一任务的前处理环节，将处理速度提升约 2.3 倍；再提高分布式任务的分片上限，让更多视频片段同时处理，进一步缩短整体转码时间。

视频分片还要解决帧间依赖问题。在开放式图像组（Open-GOP）编码中，部分视频帧需要参考相邻图像组中的画面。如果直接将视频物理切开，可能导致参考帧丢失，引发解码异常。多媒体团队采用逻辑分片，在划分处理区间的同时保留完整解码上下文，确保各片段能够正常处理。

物理分片与逻辑分片方案的差异。

各个分片能够正常处理之后，不同清晰度档位在切换时还要保证时间上对齐。如果输入视频采用可变帧率，单纯按固定帧数设置关键帧间隔，可能导致各档位的关键帧落在不同时间点，切换时出现跳帧。

多媒体团队将可变帧率输入统一转换为恒定帧率，将关键帧间隔设为 5 秒，让不同帧率档位的关键帧落在同一时间点。同时各档位共用预先计算的分段边界。即使增强档经过插帧、帧数增加，各片段的起止时间仍与其他档位对齐，实现自适应码率（ABR）切档所需的分段时间 100% 对齐。拼接时再依据片源真实时长处理，避免时间误差累计造成音画不同步。

一系列优化进行下来，超高清档位的增强转码速度提升约 57 倍

超高清档位的优化路径。

回放转码还要兼顾后续分发成本。多媒体团队采用「先快后精」的策略：先快速生成各档位，让球迷尽快看到回放，再在观看高峰前进行高压缩重转。在主观画质持平的条件下，4K 增强档码率进一步下降 13.3%

云端完成 4K 增强转码之后，终端播放也需要进一步适配。多媒体团队通过流式读取减少 Web 端的缓冲等待，完善第三方投屏和多端播放，4K 回放覆盖iOS、Android、鸿蒙、Web 和投屏。同时通过上变换技术将立体声转换为杜比全景声，增强赛场音效的空间感，并兼容不支持全景声的设备。

从世界杯实战

到技术能力沉淀

世界杯结束后，这场赛事留下的价值，远不止于几项性能指标的提升。

在千万级峰值并发和极短交付周期的约束下，小红书完成了从直播画质增强、低延迟传输，到 4K 回放生产、多端播放和客户端稳定性保障的一系列技术攻关。这些工作横跨音视频算法、流媒体工程与终端架构，让多媒体团队的综合技术能力得到了一次高强度实战检验。

从交付结果来看，小红书在顶级赛事技术保障方面，已经展现出了行业第一梯队的综合实力

对于多媒体技术行业而言，大型赛事正在成为检验平台综合实力的重要场景。随着高分辨率、高帧率和低延迟成为用户的常态化期待，技术竞争也越来越深入到全链路协同和规模化交付层面。未来，小红书世界杯期间积累的工程经验仍有机会在直播、点播和实时音视频等日常业务中发挥作用。

最后，安利一下多媒体团队。这是一支长期深耕多媒体算法与工程的团队，支撑起小红书海量图片、点播、直播及实时音视频业务。世界杯只是其中一个高强度的实战场景。

目前，多媒体团队正在招聘 2027 届毕业生和有一线研发经验的技术人才。如果你喜欢钻研技术难题，并希望把前沿算法用到用户的日常体验中，该团队值得关注。团队欢迎算法、数据结构和系统基础扎实，善于用数据分析和解决问题的人才，尤其期待在图像增强、音视频编解码、网络传输、音频处理等方向有深入积累的同学。另外，具备 NeurIPS、ICML、ICLR、CVPR、ACM MM、SIGCOMM、SIGGRAPH 等顶会论文的第一作者或核心贡献经历，或拥有优秀的 GitHub 项目、持续参与开源社区，都会是加分项。