2018 年仅仅过去了一个礼拜，就迎来了今年的第一个风口--直播答题闯关赢现金。这场由国民老公点燃的战火一触即发，大有愈演愈烈之势。不仅有思聪力挺的冲顶大会，更有作为花椒直播背后的老板周鸿祎，西瓜视频老板张一鸣等大佬也纷纷加入到这场「大撒币」中来。直播答题的具体规则如下：
从以上规则中可以看出，直播答题的最大难点在于实时性和高并发性。实时性是指每道题目只有 10s 的作答时间，运营方对题目的下发需要精确到秒级。时间太长会导致作弊，时间太短则对用户不公平。高并发性是指单场直播会突然涌入百万级的用户观看，我看过的某平台最高单场有两百多万人参与。这对服务器架构设计和流量成本就有很高的要求。
说实话，我算不得「内行」，但也来凑凑这里面的「门道」。
直播自从 16 年成为风口后，到现在已经涌现出许多平台，其中不乏映客、花椒、美拍等行业标杆。在技术上已经比较成熟。一场完整的直播从主播发起直播到观众观看直播包括 采集--编码--传输--源站处理--分发CDN--解码观看 这几个步骤。
一般对流媒体的采集包括视频和音频的采集，分别通过手机摄像头和麦克风设备来完成。摄像头在 1s 内连续记录的多个画面，称为「帧」，每一帧可以理解为一张图片，在播放端快速播放多个连续的帧就形成了视频。而音频则是对人发出的声波进行采样，然后进行模数转换，将之转换为数字信号。
采集到音视频数据后，还需要进行编码才能在网络上传输。我这里所说的编码不仅仅是指将音视频数据按照一定的格式进行组织，也包括对视频的压缩。试想一部时长两小时、分辨率为 1920x1080，每秒 20帧 的电影如果不经过压缩，其大小将达到 2224G！这简直是不可想象的。 以视频为例，摄像头采集的原始数据数据为 YUV帧，对这些帧进行宏块划分、帧内和帧间预测、运动估计和运动补偿、再将得到的稀疏矩阵经过离散余弦变换，就可以得到 H264 裸码流。最后再将其封装为 flv 格式，就可以进行传输了。
流媒体在网络上的传输是比较重要的一个环节，尤其是对直播来说。因为直播类音视频的一个基本要求就是实时性，因此要尽可能缩短在网络上的延迟。包括从传输协议、传输链路、各端之间处理等方面的选型和优化。
现在普遍选用的传输协议是 RTMP 协议，称为实时消息传输协议，是 Adobe 公司发布的。从功能和命名上看，他就是为实时传输消息而设计的，因此很适合于直播流的传输。对应的开源项目一般有 nginx-rtmp-module、SRS、CRTMPD、FMS、WOWZA 等。
在链路层面，主要是尽可能去优化路由，避免跨网络跨运营商情况，缩短数据包在主播和观众之间的跳数。一般来说，跨运营商和跨地区会导致丢数据的现象。跨运营商会带来两个问题：
因此在观众观看直播时，需要就近拉取，同时也需要尽可能保证电信用户走电信通道，联通走联通通道等。
同时，主播和观众往往是一对多的关系。若主播所以在观众端可以通过 CDN 来进行拉流分发，以缓解源站的压力。CDN 全称为 Content Delivery Network，即内容分发网络。在另一方面，观众观看直播时，会到就近的 CDN 边缘节点进行拉取，也可以提升连接质量，缓解因链路而引起的丢帧问题。
解码是编码的逆过程。观众端拿到直播数据后，需要进行 解封装--解码 的过程，然后将得到的音视频数据分别送到扬声器和屏幕上。
而直播答题是在直播的模式之上，加入的一种新型互动玩法。这就要求在技术上不仅要达到直播的低延迟要求，同时也要满足题目和直播流的同步。题目出现过早或过晚都不行，过早，主持人还没开始念题，题目已经弹出；过晚，主持人都念完了，题目才弹出，容易导致作弊。而题目通常是通过 IM 通道下发的，与直播属于两个不同的通道，这之间的同步如何保证？
答案就是 SEI。SEI 称为补充增强信息（Supplemental Enhancement Information），是 H.264 和 H.265 协议中规定的一种 NAL unit，用来向视频中加入一些额外信息，如视频版权等。可以在视频编码端或传输端加入。
这里我们需要在 SEI 中加入时间戳相关信息。在观众参与答题时，为尽可能保证时间戳的准确性，可在 CDN 边缘节点上再加入，同时在 IM 通道中设定题目在哪一个时间点应该出现。这样，客户端就可以根据这个时间戳进行同步，精确到某一帧再弹出题目或答案，保证了答题时间的准确性。