算法系列:视频播放器性能

2020-09-14 11:09:24 浏览数 (1)

本文为媒矿工厂编译的技术文章

原标题:The Algorithm Series: Video Player Performance

原作者:Tim Siglin

原文链接:https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/The-Algorithm-Series-Video-Player-Performance-142545.aspx

翻译整理:郝明月

当你完成了一个编码工作,其中需要为一些复杂场景作额外质量控制,并准备好了向外界发布,但是首先你需要向上层展示,因此你将媒体流上传到预发布服务器上,并向老板发送URL链接地址。几分钟后,你收到一条短信,询问为什么视频质量如此得差。

视频看起来质量不好意味着什么,以及应如何解决该问题?是某些特定场景的问题,或是媒体服务器中的故障,亦或是老板用来观看视频的移动设备上播放器过时,甚至是公司V**上的带宽的问题?

欢迎来到错综复杂的流媒体世界!

CDN可以准确地提供给定的内容,并且通常会做得很好。但是有时,获取方(例如,点播内容的编码端)会引入异常,该异常会通过CDN传递到最终用户,从而导致播放质量不佳。

在刚才提到的场景中,编码,传输和播放的算法在最终用户的播放器中应该如何相互联系?这就是我们在本文中关注的播放器性能问题。

编码和传输

“一次编码,随处交付”是我们在流媒体历史上一直听到的一项口号, 目前已经取得了不同程度的成功。在早期,这意味着使用正确的编解码器和播放器组合,因为编码器,媒体服务器和最终用户播放器都是同一生态系统的一部分,例如Adobe,Microsoft或Real提供的付费解决方案。

问题是“无处不在”仅意味着其中一种专有解决方案。如果一家公司使用Microsoft,但其客户使用Real,则每个流平台必须对内容进行编码。

H.264(又称高级视频编码,AVC)的出现改善了编码方面的情况,H.264通常以MPEG-2或MPEG-4容器格式存储。但是随后,出现了各种不同的基于HTTP的交付方式,例如Smooth Streaming,Adobe HDS或Apple HTTP Live Streaming(HLS),它们需要以一定的比特率(称为自适应比特率或ABR)进行多种编码或多个媒体分段,根据这专有的分段大小和manifest文件基于HTTP进行传输。

这些问题中的大多数已经通过一些专有格式解决,这些专有格式构成了行业标准MPEG-DASH的基础。同时,我们已经看到Apple的HLS转向了DASH使用的分段MP4(fMP4)方法。

因此,在对ABR内容进行编码时,可以认为所有内容都能随时基于可用带宽进行传送了,事实上是这样吗?实际情况中,将ABR内容传送到支持ABR的播放器时,需要考虑以下三件事。

1. 有多大的可用带宽?

这是ABR播放器性能正常的主要问题之一。这不仅是在某个时刻的问题,而且还是在这个特定时刻之前的问题,请记住(正如大多数股票经纪人在向潜在客户的推销中所提到的那样),过去的表现并不能保证未来的结果。之所以这很关键,是因为当需要根据MPD文件决定要请求哪个比特率的媒体片段时,很多研究都假定播放器具有最佳决策。

在PV’18,第23届Packet Video Workshop, 来自Brightcove的Yuriy Reznik和他的同事展示了他们题为“OptimalDesign of Encoding Profiles for ABR Streaming”的论文,这篇论文描述了网络带宽建模和决定某一个ABR视频被选中的概率的方法(稍后进行介绍),有两个值得考虑的解决调度问题的算法。

第一个是引入平滑滤波器来估计带宽,正如Stephan Hesse在Fraunhofer/HHI工作期间撰写的文章“Design of Scheduling andRate-Adaptation Algorithms for Adaptive HTTP Streaming”中所提到的(如下图)。Reznik及其合作者在他们的论文中引用了这一点,作为ABR客户端估计可用带宽并决定下一个请求的编码流以利用尽可能多带宽的一个实际方法。

“我们发现适合我们目的的一种众所周知的平滑滤波器是指数滑动平均滤波器(exponential moving average filter)”Hesse在文章中写道。“使用该滤波器,当前的平滑带宽估计值Ck为当前带宽测量值Tk和先前的平滑估计值Ck-1的加权平均值,”得出以下公式:

Ck =(1−α)Tk αCk−1

公式中α ∈ (0, 1), 为滤波器参数,或者“平滑因子”。Hesse继续指出,将递归扩展得到下面的式子:

其中

实际上,这允许将权重分配给特定的测量数据,然后针对“参数α的几个可能值”进行最可靠地带宽估计。

Hesse写道:“平滑因子α的值会影响带宽估计值对过去测量的依赖程度。”“如果α接近0,则滤波器变为全通,它会忽略所有过去的测量。”

但是,如果α增加,则对最近测量的依赖将减少,而对先前测量的依赖将增加。为什么会这样呢?Hesse指出,客户端缓冲区可能能够吸收带宽的某些间歇性,而不需要切换到其他ABR段带宽速率。

他写道:“另一方面,如果传输速率测量表明信道带宽发生永久性变化,我们还希望滤波器足够迅速地做出反应。这对即使切换比特率避免卡顿等情况的出现很重要。”

2. 如果我们(某种程度上)忽略带宽呢?

Hesse在其dispar.at博客中指出的第二种处理卡顿的方法可能是一个更好的方法,该方法是使用Lyapunov优化技术,一个基于缓冲区的算法以“最小化卡顿,最大化视频质量”——BOLA。这种方法不测量带宽,而是根据某一时刻用户播放器缓冲区片段占用百分比来推测带宽可用性。

BOLA是2016年由Kevin Spiteri (University ofMassachusetts–Amherst),Rahul Urgaonkar (Amazon),和Ramesh K. Sitaraman (Akamai)提出的。他们认为,目前对有相关算法的现代视频播放器理解甚少,所以算法在决定下一个HTTP传输的片段时没有得到适当应用。他们在论文中写道,“我们将自适应比特率当作一个效用最大化问题,其中包含了QoE的两个关键要素:用户体验到的视频的平均比特率和卡顿事件的持续时间。”

此外,他们引用Sitaraman在2013年所做的有关网络性能及其对观看者的影响的研究,他们说:“我们考虑了影响用户总体QoE的两个主要性能指标。” 第一个是“时间平均播放质量,它是用户观看的块的比特率的函数”,第二个是不重新缓冲所花费的总观看时间的占比。

他们认为,BOLA是一种限制整个缓冲区避免持续耗尽(欠载)或填满的方法。(如下图)缓冲区的大小是有限的,可以用队列中可以播放的块或段的数量来度量。如果缓冲区已满,播放器将等待请求下一个块;但是,如果可用带宽在请求之间的间隔中下降,则请求的块(数据速率更高)下载时间可能更长。这可能会级联成缓冲区欠载情况。作者认为这种重复循环(由于缓冲区已满而导致欠载或下载暂停)是通常(但并非总是)由可用带宽波动引起的振荡。

然而,为了避免我们以为当观看者以恒定比特率观看内容时不会发生带宽选择更改,BOLA的作者指出了一个问题,该问题是早在Burst Technologies的Windows Media Player中就存在的缓冲区填充方法的困惑:即稳定带宽缓冲选择。他们写道:“拥有稳定的网络带宽和宽广的阈值仍然无法避免所有比特率的切换。”

以一个拥有2Mbps带宽和一个节目两种ABR选项(1.5Mbps, 3Mbps)的播放客户端为例, 作者认为,当缓冲区填满时,播放器的性能实际上可能是下降的:“播放器下载1.5Mbps的块时,缓冲区不断增长。当缓冲区超过阈值时,播放器切换到3Mbps,耗尽缓冲区。缓冲区充分耗尽后,播放器切换回1.5Mbps,并重复循环”。

如果最终观看者想要保持恒定的质量,则可以选择以下两种选择:以较低质量的1.5Mbps观看整个节目,或者使用旧的Burst Technologies技巧,以比用户更高的带宽观看整个节目。BOLA的作者称此选择为“以更大的振荡成本来最大化效用并以3Mbps的更高比特率播放视频的一部分”,但提供了针对振荡(BOLA-O)或效用(BOLA-U)的解决方案。有关BOLA算法如何响应缓冲区级别的说明,请参见下图。

BOLA算法的最后一部分通过引入比特率上限来实现该算法在可用内容比特率之间切换时在较高或较低振荡之间进行选择的能力。我问Spiteri,将比特率上限描述为将MPD或清单文件中的选择限制为比特率低于视频播放器设备当前可用带宽的再现形式是否准确?他确认这是一个准确的描述,而不是某些人试图将比特率上限错误地等同于“带宽限制”的描述。

BOLA作者写道:“ BOLA-O通过将较高的比特率与下载前一个块时测得的带宽进行比较,验证了较高的比特率是可持续的。” “由于目的是限制振荡而不是预测未来的带宽,因此这种调整不会将比特率降低到比上次下载时更低的水平”,以此来限制缓冲区的增长。

第二种选择是使用BOLA故意选择一个高于持续带宽的内容比特率,而BOLA-U遵循的原则是不要过多地填充缓冲区。作者写道:“通过将比特率提高到比可持续带宽高一个水平,可以避免缓冲区的过度增长。” “当使用较小的缓冲区大小时,BOLA-U的附加稳定性会得到回报,并且BOLA-U的效用要比BOLA-FINITE大。实际上,丢失的效用受到编码比特率之间的距离的限制;如果下一个较低的比特率级别 距离网络带宽不远,那么实用性将丢失。”

Spiteri向我详细说明了这一点。他说:“ BOLA-U偶尔会使用比设备带宽更高的比特率,从而获得更高的平均比特率。” “当然必须是偶然的;始终以较高的比特率下载会导致卡顿。BOLA-U仅在缓冲区级别足够高时才以如此高的比特率进行下载,因此不会有卡顿的风险。”

Spiteri还表示,有经验证据表明,当内容以更高的比特率和分辨率呈现时,用户会持续观看,并引用ACM SIGCOMM 2011上发表的论文“Understanding the Impact of Video Quality on User Engagement”。

因此,实际上,编码比特率之间的距离是否会引起实际问题?Melissa Licciardello,MaximilianGrüner和Ankit Singla于2020年1月发表的论文“UnderstandingVideo Streaming Algorithms in the Wild”似乎表明,在使用更多可用带宽以提高最终用户观看质量方面,还有改进的余地。它衡量了各种在线平台上播放器ABR视频流算法的实际使用情况。

作者说:“我们发现证据表明,大多数部署的算法都针对稳定的行为进行了调整,而不是快速适应带宽变化;有些算法针对视觉感知指标进行了调整,而不是基于比特率的指标进行了调整,其中许多算法浪费了可观的可用带宽。” 作者没有解决BOLA最大效用方法带来稳定性的有意识选择,但他们指出了另外一个难题:视觉感知指标。

在某些方面,这可能是语义上的区别。例如,BOLA的作者讨论了“经验证据,当视频以更高的比特率呈现时,用户会更加投入并观看更长的时间”,但是讨论围绕的是标准清晰度和高清内容之间的差异,所以,和更高带宽相比,这种差异可能是由视觉效果带来的。

但是,使用视觉感知指标来调整播放可能会十分不合理,尤其是在早期的指标(例如峰值信噪比(PSNR))方面,存在视觉上错误的图像被评价为可接受。

3. 下一步如何走?

在调整播放器性能方面还有更多的算法工作要做吗?

Licciardello,Grüner和Singla最近写了“Reconstructing Proprietary Video Stream­ing Algorithms”,该论文详细介绍了他们对包括BOLA在内的许多专有调度算法进行反向工程的研究尝试。他们在7月的2020 USENIX年度技术会议上展示了它。

在2019年,BOLA原始论文的两位作者(Spiteri和Sitaraman)以及他们在论文中感谢的同事Daniel Sparacio发表了“From Theory to Practice:Improving Bitrate Adaptation in the DASH Reference Player”。许多针对ABR内容的播放器调度算法通常分为两类:基于吞吐量和基于缓冲区。他们认为,更好的模型是一种混合算法,该算法使用“吞吐量预测和缓冲区级别,以试图利用两者的优势”。

三位作者对BOLA算法进行了更新,增加了一个称为BOLA-E的增强版本。该版本引入了一些概念,例如不包含视频数据且可用于更改缓冲区级别的“虚拟段”,以及“占位符算法”以更好地允许BOLA做出明智的比特率切换决策。更重要的是,BOLA现在已经实现到dash.js中,该视频是DASH行业论坛(DASH-IF)的参考视频播放器。

此外,作者提出的一种称为“Fast Switching”的新算法已在DASH-IF参考播放器中实现。快速切换有一个非常新颖的概念:如果带宽突然提高,并且有时间用这些更高质量的段重新填充缓冲区,则可以通过“用较高位的段替换客户端缓冲区中的较低位的段”来提高视频质量。这有可能提高低延迟吞吐量,同时又不会强迫观众在整个内容观看体验中忍受不确定的较低质量的体验。

最后,Spiteri告诉我,2016年BOLA论文的更新版本已经发布,该论文讨论了理论部分的更多细节,并将BOLA与许多其他算法进行了比较。它还包括符号的更改。Spiteri说:“虽然原始版本使用比特率m = 1表示最高比特率,但是新版本使用比特率m = 1表示最低比特率,”他补充说,这种转变“主要与dash.js播放器一致,其中较低的比特率具有较低的索引。”

结论

随着2020年上半年流媒体的激增,包括隔离期间在家观看点播内容以及越来越多地使用低延迟多参与者的网络会议软件,对播放器性能优化的需求从未如此迫切。本文试图用一些基本术语进行解释,而播放器性能背后的数学正继续构建新颖和增强版本的算法,以提供越来越好的用户观看体验。

附上文中提到的论文链接:

Reconstructing proprietary video streaming algorithms

https://www.usenix.org/conference/atc20/presentation/gruener

0 人点赞