文章目录
前言
FESTIVE（Fair, Efficient, and Stable adapTIVE）是DASH点播视频中最经典的ABR算法之一，也是基于吞吐量的（Rate-based）ABR算法的代表作。FESTIVE基于过去20个视频块的调和平均数（HM）预测吞吐量，进而通过一系列附加机制确定视频块的码率和请求时间。本笔记是基于原论文的翻译、梳理和总结。
论文总结：
- FESTIVE延续自先前的测量工作（以下两篇论文），针对多播放器共享瓶颈链路的场景进行优化
- 提出了三个指标：公平性、效率（码率）、稳定性（码率切换），但是没有考虑卡顿
- 不局限于ABR算法（码率选择），还包含了后续的码率调整和视频块请求控制，这些方面有点像BOLA (INFOCOM '16)
注：“【】”内的文字为个人想法；本笔记仅关注FESTIVE背景及设计，省略了实验评估等其他部分内容。
Introduction
多个播放器共享瓶颈链路时，需要满足三个目标：
- 公平：共享瓶颈链路的多个竞争播放器应该能够收敛到网络资源的公平分配
- 效率：一组播放器必须选择最高可行的码率集以最大化用户体验【视频质量】
- 稳定性：播放器应避免不必要的码率切换，因为这会对用户体验产生不利影响【质量切换】
本文中的测量及发现：
- 三个组件实现：(1) 调度要下载的特定视频“块”，(2) 为每个块选择码率，(3) 估计带宽
- 问题根源：应用层不准确的吞吐量估计和码率选择之间的交互作用
- 与当今播放器使用的无状态码率选择结合使用的周期性块调度可能会导致带有带宽估计的不良反馈循环，并导致不必要的码率切换和码率选择中的不公平
解决方法：FESTIVE，在公平性、效率和稳定性之间进行权衡
- 随机块调度：避免在对网络状态进行采样时出现同步偏差
- 有状态的码率选择：可以补偿码率和估计带宽之间的偏差交互
- 延迟更新方法：权衡稳定性和效率
- 带宽估计器：使用最近块的下载速度的调和平均值来对异常值具有鲁棒性
实现：使用开源媒体框架（Open Source Media Framework，OSMF）实现FESTIVE
评估：
- 环境：真实 & emulate仿真，改变整体带宽和用户数量
- 对比方法：商业播放器
- SmoothStreaming[12]、Netflix[8]、Adobe OSMF[2]和Akamai HD[3]
- 效果：FESTIVE提高了40%的公平性、50%的稳定性和至少10%的效率；FESTIVE对共享瓶颈的播放器数量、带宽可变性的增加以及可用的码率集具有鲁棒性
贡献：
- 以公平、稳定和高效为目标，系统地探索了自适应视频算法的设计空间
- 确定了当今最先进的播放器采用的码率选择和块调度的主要因素，这些因素会导致不良的反馈循环和不稳定
- 为块调度、带宽估计和码率选择设计了稳健的机制，这些机制为设计一套适应算法提供了信息，这些算法在稳定性、公平性和效率之间进行权衡
- 从这一系列算法中确定一个具体设计作为此权衡空间中的一个合理点，并表明它在大多数考虑的场景下都优于最先进的播放器
背景&动机
三个指标：总共 N N N个播放器，共享瓶颈带宽为 W W W，其中播放器 x x x在 t t t时刻选择的码率为 b x , t b_{x,t} bx,t
- 低效性： ∣ ∑ x b x , t − W ∣ W \frac{|\sum_{x} b_{x,t} - W|}{W} W∣∑xbx,t−W∣，接近0表示每个播放器都能选择尽可能高的码率
- 不公平性： 1 − J a i n F a i r 1-\sqrt{JainFair} 1−JainFair，其中 J a i n F a i r {JainFair} JainFair表示每个播放器的Jain公平性指数[43]，该值越低表明越公平
- [43] A quantitative measure of fairness and discrimination for resource allocation in shared computer system
- 不稳定性： ∑ d = 0 k − 1 ∣ b x , t − d − b x , t − d − 1 ∣ ⋅ w ( d ) ∑ d = 0 k − 1 b x , t − d ⋅ w ( d ) \frac{\sum_{d=0}^{k-1} |b_{x,t-d} - b_{x,t-d-1}| \cdot w(d)}{\sum_{d=0}^{k-1} b_{x,t-d} \cdot w(d)} ∑d=0k−1bx,t−d⋅w(d)∑d=0k−1∣bx,t−d−bx,t−d−1∣⋅w(d)，表示最近 k = 20 k=20 k=20秒内观察到的所有码率切换的加权和除以该段时间内码率的加权和，使用权重函数 w ( d ) = k − d w(d)=k-d w(d)=k−d为最近的码率切换增加线性惩罚
*类似于TCP的性能评估指标，但是HAS和TCP的场景很不一样，所以不能直接照搬TCP的接近方案
商业播放器的性能：不公平、低效、不稳定
FESTIVE设计
自适应流播放器包含三个组件：
- 调度（Schedule）下一个块的下载时机
- 为下一个块选择合适的码率
- 估计网络带宽
FESTIVE设计：仅关注稳定阶段（steady-state）（*启动阶段行为与其他播放器一致）
- 估计网络带宽：基于过去20个块的调和平均数（HM）
- 在视频流开始的20个块内不进行码率切换，可能只选择最低码率
- 有状态的码率选择：并非直接按照预估吞吐量进行码率选择，而是在选择更高的码率时进行限制（为了提升公平性）
- 每次只能切换到下一个相邻的高/低码率级别，并在较高的码率下使用较低的向上切换速率（该速率随码率线性下降，避免快速切换到高码率导致不公平）
- 如果需要调高码率，则在 k k k个块之后增加 k k k个级别的参考码率；但如果需要降低码率，则可以立即切换（与 p = 0.85 × p = 0.85\times p=0.85×预测带宽进行对比，避免VBR的视频块大小波动）
- 延迟更新：将先前的码率选择视作参考值，根据对于效率/公平性和稳定性的衡量退出实际的码率切换
- 计算当前 ( b c u r b_{cur} bcur) 和上一步计算的参考码率 ( b r e f b_{ref} bref) 与高效或稳定分配的接近程度
- 整体得分： s c o r e e f f i c i e n c y ( b ) + α × s c o r e s t a b i l i t y ( b ) score_{efficiency}(b) + \alpha \times score_{stability}(b) scoreefficiency(b)+α×scorestability(b)，选择得分较低的码率（其中 α = 12 \alpha = 12 α=12）
- efficiency cost： s c o r e e f f i c i e n c y ( b ) = ∣ b min ( w , b r e f ) − 1 ∣ score_{efficiency}(b) = |\frac{b}{\min (w,b_{ref})} - 1| scoreefficiency(b)=∣min(w,bref)b−1∣
- b b b为目标码率， w w w为预测带宽，当 b = b r e f b=b_{ref} b=bref时该式值最小（为0）
- stability cost： s c o r e s t a b i l i t y ( b ) = { 2 n + 1 if b = b r e f 2 n if b = b c u r score_{stability}(b) = \begin{cases} 2^n+1 &\text{if } b=b_{ref} \\ 2^n &\text{if } b=b_{cur} \end{cases} scorestability(b)={
2n+12nif b=brefif b=bcur
- b b b为目标码率， n n n为最近 k = 20 k=20 k=20秒秒内码率切换的次数
- 使用指数函数是因为 s c o r e s t a b i l i t y ( b r e f ) − s c o r e s t a b i l i t y ( b c u r ) score_{stability}(b_{ref}) - score_{stability}(b_{cur}) scorestability(bref)−scorestability(bcur)随 n n n单调递增
- efficiency cost： s c o r e e f f i c i e n c y ( b ) = ∣ b min ( w , b r e f ) − 1 ∣ score_{efficiency}(b) = |\frac{b}{\min (w,b_{ref})} - 1| scoreefficiency(b)=∣min(w,bref)b−1∣
- 随机视频块调度：不再基于固定的target buffer，二是从(target buffer-Δ, target buffer+Δ]的区间内随机选择目标buffer大小，其中Δ为视频块时长【不过如果target buffer远大于视频块时长，这在强网下几乎没什么用】
- 过去的方法：立即调度（连续请求视频块）or周期调度（类似于dash.js的实现，即ON-OFF）