你负责看比赛，其他的放着我来 | 苏宁体育赛事直播频道化运营关键技术-InfoQ



 写点什么

频道化直播背景介绍

苏宁体育近年来购买了大量的体育赛事版权，尤其是足球赛事版权，囊括了欧洲五大联赛、中超、亚冠等顶级版权。此外还有 WWE、UFC、NFL 等热门赛事版权。

运营这些优质的赛事资源，给用户提供优质且方便的直播服务，我们依托苏宁视频云 (PP 云) 的直播编码平台，提出了频道化直播运营理念。根据赛事类别分门别类的建立专业化频道，比如：英超频道、亚冠频道、中超频道等，把同类比赛直播及其相关的花絮、新闻短视频集中在一个频道，通过高质量的节目编排，提供 24 小时连续直播服务。给用户提供优质服务的同时，一站化服务可节省用户精力，消除其选择困难。

PP 云直播平台介绍

PP 云直播平台架构

直播平台由管理后台、分布式直播转码系统、流媒体服务集群组成。

管理后台：面向运营人员提供频道管理面板，且与转码集群的 Master 通过 HTTP API 交互。

分布式直播转码系统：由 Master 和转码节点 Node 组成集群，Master 与 Node 间通过 WebSocket 进行通信，Master 控制任务的分发与调度。Master 通过主备实现高可用，Node 基于 FFMpeg API 开发，可通过加机器横向扩展算力。

流媒体服务集群：与 Node 间通过 RTMP 进行推拉流，作为直播源站为后续的切片服务或 CDN 平台提供直播源。三者间交互及架构如下图：

PP 云直播平台主要功能

直播平台提供直播流转码、本地视频转成直播进行轮播、无缝切换直播源、动态切换 logo、动态改变节目编排、多码流输出、动态改变频道参数等。

直播转码节点实现

直播转码节点基于 FFMpeg API 实现，其大致流程如下：对视频源进行解封装、解码，然后把音视频原始数据送入 Filter Graph，对音频进行重采样、变换声道等滤镜操作，对视频进行遮标、缩放、FPS 变换等滤镜操作，然后进行时戳调整、变换，最后加上 Logo 并分别送入不同档次的编码器进行编码、推流，流程如下图所示：

后台管理页面实现

后台管理页是供运营人员进行频道管理的操作面板，提供了频道新建 / 删除、参数配置、Logo 更换、节目列表更新、频道启用 / 禁用、直播流监控面板等功能，见下图：

频道化直播关键技术点

无缝切源

切换直播源时，要使用户端无感，不出现卡顿，就需要切换视频源时，尽量缩短打开下一个视频源的耗时。打开视频源最耗时的部分在于获取视频信息，在 FFMpeg 中对应 avformat_find_stream_info 函数，对有些无法从视频信息头中获取所需参数的视频，该函数会尝试解码音视频数据来获取，会大幅增加耗时，尤其是直播源，因此可优化该函数，如果一直某路直播源的一些信息，就可直接填充相关结构体而无需调用该函数，可降低耗时。

如果是循环直播某个本地文件时，可不重新打开该文件，而是通过 Rewind 的方式，seek 到文件开头重新解码，这时需要注意处理时戳。

时戳处理

时戳处理在直播转码中尤其重要，是消除直播卡顿或花屏的关键点。首先是切换视频源时的时戳处理，其过程如下：首先建立一个参考时间轴，记录直播流当前的时间点，该时间为视频源当前音频 / 视频时间戳的较大者，并变换到参考时间轴的时基，假设音视频时戳变换到参考时间的变换函数为 f(t)，则当前时间为： T_max=Max(f(t_a ),f(t_v )) 。当切换新的视频源时，以视频轨为例，当前时戳应为上个视频源的最大时戳加上当前视频的相对时戳，然后反变换到视频轨时基，假设视频轨起始时戳变换到参考时间轴为：T_start，经过整理得到视频轨当前时戳为：V_t=ftv(T_max-T_start )+t，同理可得音频轨的时戳。

当视频源中存在时戳突变时，也需要时戳处理，我们知道，直播中音视频时戳应该是单调递增的，如果直播过程中时戳突然变小，会导致直播花屏，如果时戳突然变大，虽然不会导致视频画面出问题，但会导致时戳变大，减小 RTMP 连续直播的时长，因为 RTMP 的时戳由于字段取值范围限制，最多能支持连续 24 天的直播。切换视频源的时戳处理过程如下图所示：

Buffer 管理

Buffer 管理分两部分：一是在 Encoder 里维护一个 Frame Buffer，解码线程与编码线程的交互即可通过该 Buffer 进行。当上行网络不好时，编码器需做丢帧处理，丢帧时，优先保障音频，先丢视频帧，这样可使直播中音频保持流畅且连续。

另外一个 Buffer 是在发布流的时候，维护一个 packet buffer，用于控制流的时延，有些应用场景，有延播需求，比如电视台的直播一般都会延迟 50 秒左右播出。

Logo 动态更换

采用 Front/Back 两个 Frame Buffer 来保存 Logo 图像，在往视频帧上叠加 Logo 的函数 (Render) 时，采用 Front Buffer，当接收到更换 Logo 的命令式，启动线程来加载新的 Logo 到 Back Buffer，加载完成时，通知 Render 函数交换 Buffer，Front Buffer 就是新的 Logo 图像 Buffer 了，就完成了 Logo 切换。这样可保证 Logo 切换无缝，做到让用户无感。

错误处理

直播过程中不可避免的会遇到错误，常见的有以下几类：

时戳无效或突变问题，可用上述时戳处理的方法加以修正。
推流遇到网络错误，比如 -10053、-10054、-104 等错误，这些错误需要重启编码器，但解码器保持不变。其中 -10054 可能是流媒体服务器宕机，这时重启编码器时需改变推流目标机器。
遇到解码错误，重启解码器，保持编码器不变。
遇到非致命错误时，可设定该错误连续出现 10 次再当做错误处理。

另外，当出现错误，经过处理恢复直播时，需全速转码，追赶处理错误消耗的时间，保证直播的流畅性。

稳定性与可靠性

高可用性

高可用性可由以下的架构及部署来保证：

直播转码集群多机房部署，从更高的层次上来保证服务的高可用性。
集群内的 Master 要有热备，方案为：用 zookeeper 服务 (ZK)，部署于两台机器上的 Master 向 ZK 抢主，成功者作为集群 Master，且定期向 ZK 发送心跳，当主 Master 挂掉后，备用 Master 则会抢主成功，这样可保证 Master 的高可用性。
流媒体服务器也用集群部署，防止单点。

故障转移

直播转码集群内，Master 会感知各个节点的状态，如果某个节点挂掉，则 Master 会自动将这个节点上的任务转移到其他空闲节点，保证任务及时恢复，故障转移可以在数秒内完成，基本不影响直播观感。

监控

对整个集群的服务状况及直播流的状态监控是保证系统可靠性的重要且必要的手段。

首先在 Master 及各个节点运行过程中产生日志，每个 5 秒钟记录一次各个输入流及输出流的码率及帧率状况，然后汇报给监控平台，再由监控平台进行计算分析，输出报表或者产生报警。如果系统中发生致命错误则直接报警，可最大限度的实时报出致命错误，比如宕机，以便运维人员及时处理。日志、监控及报警流程如下图所示：