直播场景
1. 直播场景的普遍框架与工作原理
主播端：即各类主播（游戏、网红歌手、户外达人等），通过手机端或者个人电脑在线直播录制个人活动。
编码服务器：主播端上传视频流以后，编码服务器根据相应的编码转码协议将视频转化为 蓝光、高清、低清、流畅等码率。
CDN(内容分发网络)：CDN节点是用户访问相对集中的一些边缘服务器。转码服务器的流被传送到各个CDN节点，便于用户就近访问。
智能设备(手机、PC)：观看用户在自己的APP或者Web网页上缓冲相应的直播间的流。
观看端： 播放器应用（等待buffer缓存足够数据后，即可正常播放。）
完整的直播过程：
1、主播端的手机或PC把视频流实时录制后经过编码上传于转码服务器。
2、转码服务器将视频流转码为流畅、低清、高清、超清等多种码率。
3、转码服务器将不同码率的视频分发到各个CDN节点，其中CDN节点含有同一视频所有码率的视频流。
4、观看者客户端发起拉流请求。就近选择CDN节点进行拉流。每次拉流决策是自己需要的视频流的码率
5、视频流被缓冲到了直播软件（如斗鱼、映客）的缓冲区中，客户端需要决策缓冲到多久可以播放。
直播特点：视频实时产生——转码——分发——播放
观看体验：清晰度、卡顿、切换、时延
时延主要来源：客户端缓冲区
- 直播所需要做的决策
2.1.码率选择
Video Server: 视频服务器
Video Client: 视频客户端，如youtube、斗鱼、虎牙等客户端
CHUNK(竖行矩形条)：等间距的矩形条代表时间长度为1s的视频,但由于不同码率，其高度不同，码率越高矩形条越高。
Buffer(客户端缓冲区，即由n个矩形条组成的缓冲区)：当buffer中有一定的视频内容时，右端下载，左端播放。只要保证整个buffer不耗尽，视频就不会发生卡顿。一旦由于网络状态不好，buffer则会被消耗完，则会行程卡顿.
码率切换的本质是：如何在不卡顿（buffer不空）的基础上，尽可能的选出高码率。本质上是根据网络吞吐量的抖动来匹配切换相应的码率。
2.2时延控制
直播平台经常伴随着与用户的弹幕交互，所以时延就显得十分重要。如果缓冲的过长，则用户观看到的内容存在较大延迟。则影响了用户和主播的交互，如果缓冲的过短，则用户在不短的时间内又会发生卡顿，影响观看体验。
直播系统中对时延的控制会引入两种区别于点播的机制：（1）快慢播；（2）跳帧
(1) 快慢播
a) 慢播：为了避免卡顿事件时，在buffer即将为空的时刻，对视频进行慢播放，样就一定程度上延缓了卡顿的到来。
b) 快播：在buffer很充足的时刻（即时延变大），对视频进行快播放。这样就通过追赶的方式使得时延减小。
(2)跳帧
系统中默认向CDN下载帧均为按序下载，所以一旦发生卡顿，由于下载一定是按序下载，时延一定会被拉大。由于直播的互动性，目前系统默认端到端时延超过7s时，发生跳帧事件。即向CDN请求的视频不再是当前帧，而转而请求时延约为3s的较新的帧。使用目标缓冲区大小（Target_buffer）来辅助控制时延。Target_buffer可以认为是一个三元组[慢播放阈值、目标缓冲区容量、快播放阈值]
1.目标缓冲区容量：假设取值为2s，其作用为如果此刻视频发生卡顿，需要缓冲到目标缓冲区容量的内容（即buffer缓冲2s的内容），才可以播放，否则一直缓冲。
2.慢播放阈值：即buffer小于此值时，触发慢播放。
3.快播放阈值：即buffer大于此值时，触发快播放。
3.SIM 模拟平台系统架构
图3 系统框架图
蓝色阴影部分为系统环境，系统环境的核心为仿真器选手只需要完成ABR Algorithm部分。仿真器的输出即为ABR Algorithm的潜在输入，即Observation; ABR Algorithm的输出即为仿真器的输入，即Decision。
3.1仿真器SIM
功能:类似于一个播放器系统，模拟播放器在不同网络环境下下载视频帧、并动态播放的过程。每次调度为下载了一帧。
仿真器输入，输入分为三部分:
1.Frame Trace,视频数据集，此数据集重在模拟视频源的动态变化情况。
2.Network Trace,网络数据集，此数据集重在模拟网络的动态变化情况。
3.ABR算法的决策，即码率和目标缓冲区大小
仿真器输出:仿真器的各个指标的状态。所含指标有：物理时间、当前下载帧、当前播放时间、客户端缓冲区大小、当前网络RTT等。详细请看下表：
3.2ABR Algorithm的输入输出
3.3环境配置
运行环境:Python2 or Python 3 Linux/Mac or Windows
安装:我们已经在python的官方源中将仿真器封装好。大家只需要执行以下命令：
pip install LiveStreamingEnv==0.5.2
ABR Algorithm根据仿真器提供的状态信息，做出码率和目标缓冲区大小决策。
下载地址: git clone https://github.com/NGnetLab/LiveStreamingDemo
用户体验质量（QoE)
QoE分两部分：一部分为frame QoE，一部分为dunk QoE
QoE = QoE1 + QoE2
1、对于每一帧，公式为：
QoE1 = play_time_duration（播放时长） * Bitrate - 1.5 * rebuff- 0.005 * latency
2、对于每一块，公式为：
QoE2 = - 0.02 *smooth
4.相关问题
1、为什么只有在I帧时刻才可以做决策？
编码中，所有的frame被编码为I帧和P帧。I帧即为关键帧，你可以理解为这一帧画面的完整保留。P帧:前向预测编码帧。P帧表示的是这一帧跟之前的一个关键帧（或P帧）的差别，解码时需要用之前缓存的画面叠加上本帧定义的差别，生成最终画面。P帧时刻选择切码率，并不能找到与上一帧的关系，无法解码
2、为什么Target_buffer也要在I帧才可以做决策？target_buffer理论上是不是应该是连续的，如果按照仿真器的实现来做的话，算法决策的target_buffer作用是不是有限？
理论上来说target buffer 应该是时时刻刻都在决策。而不应该随着码率在I帧间隔的时候决策。由于比赛和现实系统的overhead要求，target buffer模块也不能很高频率的去调用，所以现在暂时做成了和码率一起。
3、本比赛和pensieve-sigcomm 2017的仿真器有何区别?
区别有三：
1、pensieve是一个chunk或者GOP级别的的仿真器，而本比赛是一个frame级别的仿真器。（无数个frame组成一个chunk）
2、pensieve是一个点播的场景，即它的源端视频信息全部保存在CDN，pensieve不考虑源端变化。而本比赛直播场景中源端变化更像一个生产者和消费者的动态变化。
3、本比赛有极为苛刻的时延约束，pensieve没有对时延进行考虑。
可阅读文献
TIAN Z, ZHAO L P, NIE L H, et al. Deeplive: QoE optimization for live video streaming through deep reinforcement learning[C]//2019 IEEE25thInternational Conference on Parallel and Distributed Systems (ICPADS). Piscataway: IEEE Press, 2019: 827-831.
