ABR研究综述 | A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP(IEEE CST'18)阅读笔记

原文链接:https://ieeexplore.ieee.org/abstract/document/8424813

主题:基于HTTP的视频码率自适应方案综述

注:由于原文内容过长,省略了大部分背景内容,重点保留文章中对于各种ABR方案的介绍和评价。

以下为正文笔记,大部分为翻译或总结。

 


目录

I. INTRODUCTION

II. BACKGROUND AND DEFINITIONS

A. Video Coding Standards

B. Common Problems in HTTP Adaptive Streaming

1) Multi-Client Competition/Stability Issues

2) Consistent-Quality Streaming

3) QoE Optimization and Measurement

4) Inter-Destination Multimedia Synchronization

III. BITRATE ADAPTATION SCHEMES

A. Client-Based Adaptation

1) Available Bandwidth-Based Adaptation

2) Playback Buffer-Based Adaptation

3) Proprietary Solutions

4) Mixed Adaptation

5) MDP-Based Adaptation

B. Server-Based Adaptation

C. Network-Assisted Adaptation

D. Hybrid Adaptation

1) SDN-Based Adaptation

2) Server and Network-Assisted Adaptation

IV. COMPARISON BETWEEN BITRATE ADAPTATION SCHEMES

 


I. INTRODUCTION

HAS:HTTP adaptive streaming

 

非HAS的视频播放架构:由Media server主动push,在server端实现ABR,增大了server的复杂度和运算压力

ABR研究综述 | A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP(IEEE CST'18)阅读笔记_第1张图片

 

HAS:由client向HTTP server主动pull,在client端实现分布式ABR

ABR研究综述 | A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP(IEEE CST'18)阅读笔记_第2张图片

 

ABR研究综述 | A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP(IEEE CST'18)阅读笔记_第3张图片

 

Multiple versions (also called representations) of each segment:码率/分辨率/质量

 

HAS的优势:

  • HTTP简化了穿越NAT和防火墙的实现

  • 可以利用传统的Web server及网络缓存(如CDN)

  • clinet端维护播放会话状态,server端不需要维护任何状态,因此client可以从不同server下载视频且不会影响系统的扩展性

  • clinet与server间不需要持久连接,提高了系统的可扩展性,且降低了实现和部署开销

 

HAS的例子:

  • 微软:MSS(Smooth Streaming)

  • 苹果:HLS(HTTP Live Streaming)

  • Adobe:HDS(HTTP Dynamic Streaming)、OSMF(Open Source Media Framework)

  • Akamai:HD

 

DASH:MPEG和3GPP共同制定的标准(未规定ABR,允许第三方实现)

ABR研究综述 | A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP(IEEE CST'18)阅读笔记_第4张图片

 

MPD:Media Presentation Description,MPD是一个XML文档,它为服务器上的可用媒体段提供索引

 

基于JS的DASH客户端:

  • dash.js:DASH工业论坛推荐

  • DASH-JS

 

之前survey(A Survey of Rate Adaptation Techniques for Dynamic Adaptive Streaming Over HTTP)的分类:

  • client-side

    • DB

    • RB

    • Hybrid/Control Theory-Based

  • server-side

  • in-network

 

本文与之前survey的区别:

  • 不同机制的分类方式(基于ABR逻辑的独特特征)

  • 更多ABR机制以及比较

 

ABR方法分类(基于ABR逻辑在系统中的位置,以及涉及哪些entities):

  • client-side

  • server-side

  • network-assisted

  • hybrid

ABR研究综述 | A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP(IEEE CST'18)阅读笔记_第5张图片

 

 

II. BACKGROUND AND DEFINITIONS

A. Video Coding Standards

最常用的视频编码格式:H.264(MPEG-4 Advanced Video Coding (AVC))

每个视频段从intra/key帧开始

 

SVC(Scalable):AVC的扩展,允许将视频流分成多个比特流或层

通常将视频分为三个质量维度:【注:这里不是很懂】

  • 时间(temporal):帧速率(frame rate)。视频以给定分辨率的多个帧速率进行编码。 基础(base)层具有最低的帧速率,而增强(enhancement)层增加帧速率,这逐渐提高了质量

  • 空间(spatial):分辨率(resolution)。对于给定的帧速率,视频以多个空间分辨率进行编码

  • 质量/信噪比(quality/Signal-to-Noise Ratio, SNR):视频以单个空间分辨率编码,并且增强层改善质量,保持分辨率恒定

 

H.265(High Efficiency Video Coding (HEVC)):提供几乎两倍于AVC的编码效率

SHVC:HEVC的扩展

 

VVC:两倍于HEVC的编码效率,专门针对使用沉浸式和高动态范围(HDR)视频的应用和服务,预计2020年推出标准

 

 

B. Common Problems in HTTP Adaptive Streaming

影响HAS系统的四个主要问题:

  • 多客户端的竞争和稳定性问题

  • 恒定质量的流

  • QoE优化与衡量

  • 目的地间多媒体同步

 

1) Multi-Client Competition/Stability Issues

集中管理控制器的HAS系统有三个目标:

  • Stability/稳定性:避免频繁的码率切换

  • Fairness/公平性:竞争可用带宽的多个HAS客户端应根据viewer-,content-和设备特征平等地共享网络资源。 这里所需的公平性通常不会导致带宽公平

  • High Utilization/高利用率:尽可能高效地利用网络资源

 

一个流session一般由两种状态组成:

  • buffer-filling state:填充buffer使其达到可以开始或恢复播放的特定阈值

  • steady state:在带宽波动或中断时,仍能让buffer保持在最小阈值以上,以避免buffer为空或播放停止

    • ON:下载当前视频段,记录吞吐量

    • OFF:空闲

ABR研究综述 | A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP(IEEE CST'18)阅读笔记_第6张图片

 

ON的重叠情况不同,可能会引起客户端高估可用带宽,进而可能引起视频不稳定、质量震荡、码率切换、buffer耗尽、不公平、带宽利用不充分等问题,统称为HAS的稳定性问题

ABR研究综述 | A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP(IEEE CST'18)阅读笔记_第7张图片

 

 

2) Consistent-Quality Streaming

研究表明,视频码率与感觉到的视频质量呈非线性相关,且视频内容类型(运动快慢)对视频质量也有影响

 

 

3) QoE Optimization and Measurement

ABR研究综述 | A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP(IEEE CST'18)阅读笔记_第8张图片

影响QoE的因素:

  • perceptual(用户直接感知):视频图像质量,启动延迟,rebuffering时间,卡顿频率,质量切换的程度和频率

  • technical:算法,参数,硬件/软件

 

视频流的一个主要挑战是缺乏统一的量化方法来衡量QoE

三个metric:

  • 目标metric

  • 主观metric

  • QoS衍生的metric

 

 

4) Inter-Destination Multimedia Synchronization

(略)

 

 

 

III. BITRATE ADAPTATION SCHEMES

A. Client-Based Adaptation

目标:

  • (i) minimal rebuffering events when the playback buffer depletes

  • (ii) minimal startup delay especially in case of live video streaming

  • (iii) a high overall playback bitrate level with respect to network resources

  • (iv) minimal video quality oscillations, which occur due to frequent switching.

 

五类:

  • (1) available bandwidth-based

  • (2) playback buffer-based

  • (3) proprietary solutions

  • (4) mixed

  • (5) Markov Decision Process (MDP)-based

 

1) Available Bandwidth-Based Adaptation

  • [51] Rate adaptation for adaptive HTTP streaming(MMSys'11):使用基于SFT(块获取时间,从发送HTTP GET请求开始到接收到块的最后一个字节结束)的平滑吞吐量

  • [52] Rate adaptation for dynamic adaptive streaming over HTTP in content distribution network(Elsevier SPIC'12):[51]的扩展,通过使用一个比较ESFT(预期SFT)和SFT的度量,确定选定的码率是否与网络容量相匹配,在CDN中引入串行和并行的段获取方法

  • [14] A seamless Web integration of adaptive HTTP streaming(EUSIPCO'12):使用上一视频段的码率和之前估计的吞吐量来计算下一视频段的估计带宽。初始化基于下载MPD时测量的带宽

  • [53] PANDA(IEEE JSAC'14):准确估计可用带宽,并试图解决稳定状态下共享瓶颈链路的多客户端的ON-OFF异步产生的码率震荡问题

  • [54] piStream(MobiCom'15):LTE场景,使客户端能够根据资源监视器模块(物理层daemon)估计可用带宽

  • [55] Quality selection for dynamic adaptive streaming over HTTP with scalable video coding(MMSys'12):通过使用基于带宽倾斜(bandwidth-sloping)的启发式算法,预取未来视频块的base层或为已有视频块下载enhancement层,将SVC整合入DASH

  • [56] DASH2M(MM'16):直播场景,为使用HTTP/2服务器推送和流终止属性的移动流客户端设计,旨在提高QoE并减少客户端的电池消耗

  • [57] Low latency live video streaming over HTTP 2.0(NOSSDAV'14):自适应k-push方案,根据带宽增加/减少来增加/减少k,同时记录推送周期中的总功耗

  • [58] LOLYPOP(ACM TOMCCAP'16):直播场景,基于低延迟预测的ABR,在无线链路上,利用多个时间尺度(即1到10秒)上的TCP吞吐量预测来降低时延并改善QoE

  • [59] GTube(MMSys'14)

  • [60] A comparison of quality scheduling in commercial adaptive HTTP streaming solutions on a 3G network(MoVid'12)

  • [61] Improving QoS in high-speed mobility using bandwidth maps(IEEE TMC'12)

  • [62] Empirical evaluation of HTTP adaptive streaming under vehicular mobility(NETWORKING'11)

  • [63] Predictive buffering for streaming video in 3G networks(WoWMoM'12)

  • [64] GeoStream(MM'16)

 

[59]-[64]:运动中的移动客户端

  • [59]-[63]:在真实的移动网络中部署带宽查找服务,以指导移动客户端之间的带宽估计。不足:从带宽波动的空间角度入手,很少关注时间因素

  • [64]:利用了带宽波动的时间因素,使用地质统计学来估计未知位置的未来带宽

 

【缺点:由于缺乏可靠的带宽估计方法,该类算法取得的QoE相对较差】

 

 

2) Playback Buffer-Based Adaptation

  • [65] Oscillation compensating dynamic adaptive streaming over HTTP(ICME'15):将buffer大小与客户端metric工具集相结合,以实现准确的码率选择和平滑切换

  • [66] BBA(SIGCOMM'14):目标是最大化平均视频质量并避免不必要的rebuffering。缺点:在长期带宽波动时,QoE会发生下降

  • [67] BOLA(INFOCOM'16):将ABR视为效用最大化问题,将平均播放质量和rebuffering时间视为QoE的两大指标,从理论上证明了其近似最优。该算法已在dash.js中实现

  • [68] BIEB(IM'13):基于SVC优先级最大化视频质量,同时减少质量振幅,避免stall和频繁的码率切换。BIEB在提高视频质量(增强层)之前保持稳定的buffer。不足:在网络中出现动态交叉流量的高峰时间内,没有在QoE模型中考虑码率改变或stall的情形

  • [69] QUETRA(MM'17):将DASH客户端公式化为M/D/1/K队列,可以在给定码率、网络吞吐量、buffer容量时计算预期buffer占用率

  • [70] SVC-based HTTP adaptive streaming(Bell Labs Technical Journal’12)

 

【限制:较低的总体QoE&不稳定性问题(尤其是在长期带宽波动的情况下)】

 

基于SVC的方法的限制:SVC编码和解码的复杂性,处理资源和开销

[70]:尝试使用多个SVC流,使用少量增强层的分层编码和编码开销

 

 

3) Proprietary Solutions

  • [8] MSS(Microsoft'08):周期性检测网络情况以避免带宽波动,使用可用带宽、播放窗口分辨率、客户端CPU负载作为ABR的决策metric。MSS为每个流会话建立两个TCP连接,分别用于传送视频和音频,两个连接可以根据条件进行交换。用于北京2008年奥运会的直播中

  • [9][72] HLS(Apple'15):直播&点播(Video on Demand)场景,重点针对移动端,使用网络吞吐量、设备性能(如CPU、分辨率、内存等)做出码率决策。可以同时请求多个视频段,且提供了一个媒体加密的灵活框架。现用于iOS和macOS的Safari、win10的Edge和Android 3.0+中

  • [10] OSMF(Adobe'15):免费开源软件,适用于直播&点播,使用可用带宽及设备处理性能进行ABR决策,支持渐进式下载、串行及并行视频组合,目标是(1)简化播放器开发;(2)为渲染、广告、报告提供一系列第三方服务;(3)简化第三方开发。

 

【总结:以上算法在单客户端面对带宽波动时较为有效。但是,多客户端竞争瓶颈链路时会产生稳定性问题。】

  • 启发式ABR算法仅能做出次优决策,因为它们无法迅速适应快速的网络变化

  • 在某些情形下,它们不能确保公平的观看体验

  • MSS相对其他两种表现最优,因为它可以获得最高的播放码率,只产生少量的码率切换

  • 基于标准功能和特性,与这些专有格式相比,DASH提供了几乎所有功能

 

4) Mixed Adaptation

使用组合metric进行决策,包括带宽、buffer占用、视频段大小、视频段持续时间

  • [81] MPC(SIGCOMM'15):提出了一个控制论框架,使用模型预测控制(MPC),将带宽预测和buffer大小预测最优地结合起来

  • [82] A control-theoretic approach to rate adaptation for dynamic HTTP streaming(VCIP'12):与[81]类似

  • [32] Streaming video over HTTP with consistent quality(MMSys'14):将ABR公式化为优化问题

  • [83] A video bitrate adaptation and prediction mechanism for HTTP adaptive streaming(TOMM'17):使用模糊逻辑(fuzzy logic)机制

  • [84] ELASTIC(PV'13):基于反馈控制理论,生成long-lived TCP流,避免ON-OFF稳态时的带宽高估问题。用于确保带宽公平性,但是不考虑QoE

  • [86] Adaptation algorithm for adaptive streaming over HTTP(PV'12):使用当前buffer占用水平、估计可用带宽、所有码率级别的平均码率作为ABR决策metric。目标:(1)准确估计可用带宽,避免带宽高估;(2)最大化码率,同时最小化启动延迟、stall次数、视频质量波动及播放中断。可以提高多个竞争客户端的公平性,但不考虑QoE

  • [87] FESTIVE(CoNext'12):包含(1)带宽估计模块;(2)码率选择和更新方法;(3)。目标:提高效率、公平性和稳定性

  • [88] TFDASH(IEEE TCSVT'17):利用基于对数性增加乘性减少(LIMD,logarithmic-increase-multiplicative-decrease)的带宽探测算法来估计可用带宽,使用估计可用带宽及双阈值buffer来做出ABR决策

  • [89] Towards agile and smooth video adaptation in dynamic HTTP streaming(CoNext'12):利用支持向量回归(SVR)估计可用带宽,使用buffer中的视频时间作为反馈信号,根据估计可用带宽进行ABR决策。目标:平衡单个/多个CDN场景下的DASH带宽利用和平滑度

  • [91] SQUAD(MMSys'16):使用可用带宽和buffer提高视频的平均码率,同时最小化码率切换次数。启动阶段,使用保守方法选择更多低质量的视频段;之后,使用频谱(平均段码率的变化)和buffer选择下一个视频段的码率

  • [92] Receiver driven rate adaptation for wireless multimedia applications(MMSys'12):适用于无线网络的多路径ABR,通过在应用层实现类似逻辑避免TCP拥塞。相对单个TCP流,并行TCP流已被证明可以提高吞吐量,但会产生额外的请求/响应开销,还需要修改应用栈

  • [93] SARA(ICCW'15):基于视频段大小变化、可用带宽估计(使用视频段大小估计)、buffer进行决策。在HTTP中,吞吐量取决于文件大小,因此SARA在MPD文件中加入了每个视频段的大小

  • [94] ABMA+(MMSys'16):基于估计的视频rebuffering概率选择最高码率。利用buffer maps,它定义了在某些条件下满足rebuffering阈值并避免繁重在线计算所需的buffer容量

  • [95] GTA(MMSys'18):基于博弈论,使用合作博弈(cooperative game),将ABR公式化为议价过程(bargaining process)和共识机制(consensus mechanism),因此客户端之间可以建立协议并实现它们的QoE目标

 

[81]-[83]:仅考虑单客户端场景,不考虑多客户端竞争可用带宽时的公平性和内容类型/属性

[93]-[95]:包含更多的决策指标,比如当前视频段的质量、大小、下载时间

 

5) MDP-Based Adaptation

在基于马尔可夫决策过程(MDP)的ABR中,视频流过程被形式化为有限MDP

  • [97] A real-time adaptive algorithm for video streaming over multiple wireless access networks(IEEE JSAC'14):多接入网络上的实时最佳动作搜索算法。使用蓝牙和WiFi同时下载视频段,输入为buffer、SVC层index、蓝牙流量、可用带宽及每个视频段的index。奖励函数(reward function)包括平均播放质量、中断率、播放平滑度。不足:用户移动场景

  • [98] Optimizing HTTPbased adaptive streaming in vehicular environment using Markov decision process(IEEE TMM'15):解决用户移动性问题,将ABR建模为车辆环境中的MDP问题,引入了基于强化学习(RL)的三种变体算法,利用历史带宽样本构建精确的带宽估计模型

  • [99] A multi-agent Q-learning-based framework for achieving fairness in HTTP adaptive streaming(NOMS'14):解决多个客户端在瓶颈链路上竞争时的QoE和公平性问题。基于多agent的RL,使用中央管理器收集QoE统计数据(段码率)和协调竞争客户端,确保各客户端的QoE公平并提高QoE。不足:不考虑stall和质量切换

  • [100] Online learning adaptation strategy for DASH clients(MMSys'16):基于MDP的在线ABR算法,目标是最大化长期预期reward(QoE),奖励函数通过视频段质量、质量震荡、客户端经历的stall计算。使用RL进行决策,利用并行技术以避免RL的缓慢收敛和次优解

  • [101] mDASH(IEEE TMM'16):将ABR逻辑公式化为MDP优化问题,将buffer大小、带宽条件、码率稳定性视作马尔可夫状态变量,提出了一种低复杂度的贪婪次优算法

  • [102] Pensieve(SIGCOMM'17):基于A3C,不需要依赖对环境的预编程模型或者假设,而是从观察和经验中学习最佳策略

  • [103] D-DASH(IEEE Transactions on Cognitive Communications and Networking‘17):结合深度学习与强化学习(Deep Q-Learning),使用混合学习架构(包括具有高级策略的前馈和循环神经网络RNN),实现了决策过程中策略最优性和收敛速度之间的良好平衡

 

[102]-[103]:基于深度强化学习,展示了将DRL和ABR启发式*方法结合的优势。不足:当客户端数量增加时,可能会受到不稳定性、不公平、不充分利用(带宽)的影响。

*注:原文为“heuristics”,猜测意思是ABR决策使用的metrics,不知道此处怎么翻译比较好

 

B. Server-Based Adaptation

ABR研究综述 | A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP(IEEE CST'18)阅读笔记_第9张图片

在server端使用码率整形方法,不需要client端的任何协作。码率切换由码率整形器隐式控制,客户端仍可以做出码率决策,但最终决策或多或少地取决于服务器上的整形方法。

  • [106] Server-based traffic shaping for stabilizing oscillating adaptive streaming players(NOSSDAV'13)

  • [107] Shaping HTTP adaptive streams for a better user experience(MMSys'12)

  • [108] Tracker-assisted rate adaptation for MPEG DASH live streaming(INFOCOM'16):直播场景,存在网络cache时的跟踪器辅助(tracker-assisted)ABR,由多个客户端(通过共享代理与服务器通信)和一个服务器(具有管理客户端状态的跟踪器功能)组成,需要修改MPD

  • [109] Feedback control for adaptive live video streaming(MMSys'11):基于反馈控制理论,旨在保持每个播放器的buffer尽可能稳定,并使码率决策与可用带宽相匹配。目标:通过控制服务器发送buffer大小,为每个DASH播放器调整和选择最合适的码率

  • [110] MS-stream(CNCC'17):用于提高QoE的多源ABR,其中客户端从多个MS-Stream中获取视频段

 

[106]-[107]:分析多个HAS客户端竞争可用带宽时的不稳定性和不公平性问题,提出了一种流量整形方法,可以在家庭网关中部署,以优化公平性、稳定性、收敛延迟[107],并消除稳定状态下的OFF时期(引起不稳定性问题的根源)[106]

 

【不足:增加了服务器端的开销和复杂度(尤其是客户端数量增加时)。部分方案还需要修改MPD或特定的服务器软件,这可能违反DASH标准设计原则。】

解决方法:服务器+网络辅助([16] [111]),见III-D2

 

 

C. Network-Assisted Adaptation

ABR研究综述 | A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP(IEEE CST'18)阅读笔记_第10张图片

通过收集网络测量信息并通知客户端选择合适的码率,网络辅助方法允许客户端考虑ABR过程中的网内(in-network)决策

  • [112] QDASH(MMSys'12):QDASH是客户端与服务器间的代理,包括一个QDASH-abw模块(用于测量带宽)和一个QDASH-qoe模块。通过使用集成的中间级别(integrated intermediate levels)来保证码率级别的逐渐变化,进而提高QoE。不足:在网络中产生大量开销(尤其是客户端数量增加时),可能导致网络拥塞,从而降低QoE

  • [113] QoE-driven in-network optimization for adaptive video streaming based on packet sampling measurements(Elsevier CN'15):QoE驱动的网内优化系统,解决了多个DASH客户端竞争可用带宽的问题。系统由一组沿着客户端与服务器之间的路径部署的agent组成,这些agent均为代理(proxy),使用packet采样技术定期测量可用带宽,并通过解优化问题做出码率决策,最终将码率决策发给客户端。不足:可能会产生大量开销,且无法应对agent失效

  • [114] BUFFEST(MMSys'17):BUFFEST是一个从HTTP/HTTPS流量中预测客户端buffer状况的分类框架,由基于事件的buffer模拟器(负责准确跟踪/预测客户端的buffer状况)和自动训练的在线分类器(负责TCP/IP数据包级的流量分类)组成

  • [116] Price-based controller for utility-aware HTTP adaptive streaming(IEEE MultiMedia‘17):受[115] NUM(IEEE JSAC'06)的启发,是一个基于分布式价格的网络辅助HAS系统,用于共享瓶颈的多个并发HAS客户端。受拥塞控制算法的启发引入了价格定义(一个关于视频段下载时间的函数),中央协调器使用价格信息协助客户端做出决策,以最大限度地提高整体用户满意度和QoE公平性

  • [117] FINEAS(ACM TOMCCAP’16):QoE驱动的网内ABR,目标:减轻开销,解决多客户端的公平性问题。使用网内组件(如代理)提供网络状况(可用带宽等)的信息并给出码率建议,客户端可以基于建议做出码率选择。不足:尽管在同类系统中表现良好,但在现实世界中存在大量异构设备,可能会导致不同设备的QoE不同

  • [118] NOVA(INFOCOM'14):将多客户端竞争问题公式化为受buffer、网络状况、传递开销(delivery cost)约束的优化问题,为每个客户端选择最优码率。包含带宽分配和质量自适应两个主要元素。不足:虽然相对于DASH实现了良好的QoE,但其效率依赖于强大的统计假设(如静态遍历性stationary ergodicity),可能会对收敛世界产生影响

  • [120] AVIS(MobiCom‘13):蜂窝网络场景,基于网络的radio资源分配框架,为每个客户端最优地分配资源(将DASH流与其他流分开)并确保它们之间的公平性和稳定性,同时保持高资源利用率

  • [121] Quality-of-experience driven adaptive HTTP media delivery(IEEE ICC’13):蜂窝网络场景,QoE优化器和资源管理框架,在无线信道状况、buffer、可实现的QoE的约束下动态寻找最优码率。基于每个客户端的QoE为其分配可用带宽【[120][122]是均分带宽,但由于设备本身的性能差异,不是所有设备都能取得好的播放体验】

  • [122] Modeling stability and bitrate of network-assisted HTTP adaptive streaming players(ITC'15):蜂窝网络场景,在网关上安装HTTP代理,均匀分配客户端之间的可用带宽。若客户端请求的码率比代理指定的码率高,则代理会重写客户端请求【相当于不让客户端请求的码率超过代理指定码率】,并会在响应中添加HTTP头部通知客户端。将流过程建模为MDP,其中每个状态表示活动的客户端数量,状态间的切换与播放器的启动和停止相关联。出于对稳定性的考虑,switches的数量与MDP的状态转移频率有关

  • [123] RAGA(ICC'14):蜂窝网络场景,跨层buffer感知无线资源分配算法,仅使用buffer(level and rate of level changes)做出ABR决策

  • [124] Video-QoE aware resource management at network core(Globecom‘14):蜂窝网络场景,由网络核心的视频感知控制器(VAC,Video Aware Controller)组成,VAC作为中央智能单元,将视频质量、buffer级别转换为QoS参数。根据从反馈中获得的buffer级别,为每个客户端计算动态最大码率

  • [125] MP-DASH(CoNEXT'16):蜂窝网络场景,能够感知客户端网络接口设置的多路径框架,旨在改善MPTCP以支持DASH(考虑用户网络接口设置),从而在不降低QoE的情况下提高视频传输的效率。由MP-DASH调度器和视频适配器组成,调度器基于用户接口设置、视频段大小、视频段传递时间在多路径中选择获取视频段的最佳路径,视频适配器是现有client-based方案的多路径友好的附加组件,负责ABR方案与调度器间的交互

  • [126] Prius(IEEE TCSVT’17):蜂窝网络场景,由混合和边缘云和client-based自适应方案组成的框架。目标:减少蜂窝网络中的视频不稳定性、QoE的不公平性和卡顿

  • [127] SAP(MMSys'17):蜂窝网络场景,DASH客户端流量管理方案,利用网络和客户端状态信息优化每个播放器的QoE。目标:在有不同信道状况的多个DASH客户端竞争资源时,减少视频卡顿同时保持一致的QoE

  • [129] QoE multi-stage machine learning for dynamic video streaming(IEEE Transactions on Cognitive Communications and Networking’18):利用[128] (IEEE CST'08)中的ML(机器学习)机制,多个DASH客户端在共享信道中竞争可用带宽时的多级ML认知方法,使用无监督ML和有监督ML学习质量-速率(Q-R,Quality-Rate)的关系。通过部署认知HTTP代理(CHP,cognitive HTTP proxy),控制发往客户端视频流量,执行流量分类,帮助客户端做出决策,并根据Q-R函数应用资源分配

  • [131] Oboe(SIGCOMM'18):根据不同的网络状况自动调整ABR方案的参数配置

  • [132] OpenCache(Elsevier CC’15):基于OpenFlow的网内缓存服务,利用软件定义网络(SDN)为媒体内容提供缓存即服务(CaaS,cache-as-a-service)来优化视频点播(VoD)DASH流。通过尽可能靠近客户端推送视频段(无需修改传递方法)减轻last mile可扩展性问题,并提升网络资源利用率和QoE。此外,它还可以提供网络和DASH客户端的测量结果,帮助CDN提供商优化内容放置和传递机制

  • [133] Design and experimental evaluation of networkassisted strategies for HTTP adaptive streaming(MMSys'16):研究多个异构自适应流媒体播放器共享同一瓶颈链路下的视频质量公平性(VQF,video quality fairness),由视频控制平面(VCP)实施视频质量管理策略以确保公平性。作为网络控制器应用,VCP在SDN控制器之上实现,由三种网络辅助流方法组成:带宽预留、码率引导、码率引导和带宽预留的混合方法

  • [134] SABR(MMSys'17):SDN辅助架构,利用SDN功能来协助和管理HAS播放器,并收集各种信息(如可用带宽和客户端状态)以指导播放器的码率决策

  • [135] WVSNP-DASH(IEEE Transactions on Broadcasting‘15):用于小型化设备(包括传感器)的基于DASH的视频平台(无线视频传感器节点平台),使用替代方法对视频分段以便小型无线设备和传感器(传输、存储和播放?)。对视频段使用特定的命名语法(基于简化的Backus-Naur形式[136]),在其名称中嵌入视频播放所需的基本元数据,使得每个视频段成为可独立播放的文件,因此客户端不需要下载manifest文件和初始段也可以播放视频段。基于HTML5的核心元素(如HTML5文件系统)设计,此外还可以封装Web浏览器支持的任何容器、编解码器和DRM。不足:没有分析引入的开销,嵌入在每个段中的新数据可能严重影响网络效率和寿命

  • [137] Adaptive multimedia streaming in information-centric networks(IEEE Network‘14):研究将HAS整合到信息中心网络(ICN,Information-Centric Networking )上的可能性

  • [138] Adaptive video streaming over informationcentric networking (ICN)(RFC 7933’16):HAS over ICN

  • [139] Investigating the performance of pull-based dynamic adaptive streaming in NDN(IEEE JSAC'16):通过分析不同基于ICN的转发策略的网络级理论最优和应用层面各种基于客户端的ABR之间的性能差距,研究ICN上的DASH的性能。通过将ICN中的并发流客户端公式化为具有/不具有缓存的分数多商品流问题(MCFP)来得到理论最优的界限,表明ICN多路径和缓存功能可以提高HAS性能

  • [140] Towards SVCbased adaptive streaming in information centric networks(ICMEW'15):在ICN上结合HAS与SVC。使用SVC的原因:(i)可以充分利用ICN的优势,同时避免次优码率选择;(ii)有助于客户避免高估带宽;(iii)SVC的分层结构可以利用 ICN的多路径功能带来的好处

  • [141] EcoMD(Elsevier CC’17):基于ICN的成本效益(cost-efficient )多媒体内容传输解决方案,用于车载自组织网络(VANET),以降低高动态VANET中视频传输的成本。首先分析了内容移动性和供需平衡两个基本因素,其次将与视频传输相关的成本公式化为混合整数规划(MIP)优化问题, 最后提出了三种自适应启发式解决方案来解决优化问题:(1)基于优先级的路径选择;(2)最少需求的源维护;(3)按需路径内缓存增强

  • [142] Mobile peer-to-peer video streaming over information-centric networks(Elsevier CN'15):基于ICN的P2P流媒体应用,用于蜂窝网络的直播HAS系统,利用ICN功能提供良好的HAS服务并实现简化的部署过程。HAS客户端(或对等体peers)构建P2P单跳网状网络,允许协同下载相同的直播视频。 客户端使用蜂窝网络接口连接到HAS服务器,并通过邻近WiFi信道相互连接

 

[120]-[127]:蜂窝网络

[132]-[134]:将支持OpenFlow的解决方案与HAS相结合

[137]-[142]:ICN相关

  • 所呈现的基于ICN的解决方案使用启发式信息(从所请求的内容收集)来执行特殊节点的cache决策

  • 其中一些解决方案中会产生大量冗余副本,影响存储资源

  • 提供高效的内容管理,确保cache性能,以及在ICN上设计强大的HAS交付系统仍然是一个悬而未决的问题

 

 

 

D. Hybrid Adaptation

在混合ABR中,多个网络实体相互协作并收集有关网络状况的有用信息,这些信息可以帮助HAS客户端进行码率选择。 这种技术包括基于SDN的ABR及服务器和网络辅助的ABR。

1) SDN-Based Adaptation

SDN相关文献:[143][144]

将SDN与自适应视频流系统整合的出发点:

  • SDN允许网络资源控制和功能监管,从而简化网络资源编程和部署

  • 多客户端竞争共享链路时,单客户端ABR无法解决公平性和网络资源利用的问题,可以由具有全局网络视图的集中式机制来避免

ABR研究综述 | A Survey on Bitrate Adaptation Schemes for Streaming Media Over HTTP(IEEE CST'18)阅读笔记_第11张图片

方案:

  • [145] QFF(SIGCOMM FhMN'13):使用OpenFlow监视视频流质量并分配/管理网络资源,通过保证最后一英里的多个竞争的DASH客户端之间的视频质量公平性来优化QoE

  • [146] IQMF(INFOCOM WKSHPS'15):同作者对[145] QFF的改进。IQMF作为代理,目标是在视频会话期间提供对每个客户端的QoE的透明监控,并随后通过API向网络和内容提供商提供反馈。IQMF的提出是因为无法通过传统网络级指标(带宽、丢包率、抖动、端到端延迟等)估算视频质量。不足:QFF和IQMF在决策时都只考虑了设备分辨率和可用带宽两个指标,没有考虑buffer水平

  • [147] Towards QoE-aware video streaming using SDN(Globecom'14):目标是在多个客户端竞争共享容量时管理网络资源,同时监控网络状况和客户端反馈(QoE指标)。当QoE降低时(如卡顿),SDN应用程序使用SDN上的多协议标签交换(MPLS)流量工程机制动态地重新路由视频流。该方法可以通过选择服务器的最佳路径来改善整体QoE。不足:没有描述流传输会话期间动态改变路径的时间影响

  • [148] GC(ICNP'14):用于直播视频流的SDN辅助服务,使用基于GENI SDN的网络资源基础设施在校园内提供在线教育视频流直播,使客户端可以通过公开共享的Web protal上传及观看在线视频。GC能够使用SDN的特性动态监视和管理一条或多条路径上的视频流和资源,被证明具有可扩展性、稳定性和公平性

  • [149] Software-defined network-based prioritization to avoid video freezes in HTTP adaptive streaming(International Journal of Network Management'16):通过在视频段传递过程中使用优先级技术以减少由突发带宽波动引起的视频卡顿。该框架的主要组成部分SDN控制器通过收集网络状态信息(如带宽变化、延迟、HAS客户端的状态)决定是否优先下载某个视频段

  • [150] Delivering stable highquality video: An SDN architecture with DASH assisting network elements(MMSys'16):目标是确保稳定和高质量的视频传输,同时避免TCP机制与DASH流量的动态突发性质之间的不匹配。系统结构包括三层:1)SDN网络应用控制器:帮助多个竞争客户端进行码率选择;2)SDN网络管理:使用基于动态队列的机制进行QoS配置;3)可编程网络基础设施。不足:没有考虑设备异构性,而它对于确定可用带宽和QoE公平性的公平份额较为重要

  • [151] SDNDASH(MM'16):解决[150]的问题,利用SDN,基于每个客户端的QoE为其管理和分配网络资源。由应用层、控制层、网络层三层所组成,其中包含六个核心实体:DASH服务器、DASH客户端、基于SDN的外部应用程序、SDN控制器、基于SDN的内部应用程序、转发设备。 SDNDASH将码率的QoE最大化和网络资源分配的最优决策公式化为最大化优化问题,从而显着提高每个客户端的QoE,同时避免HAS稳定性问题

  • [152] SDNHAS(IEE TMM'17):解决[151] SDNDASH中未解决的可能影响ABR决策的三个限制:1)HAS播放器的大规模部署;2)通信开销;3)对系统异构性的更多支持

  • [153] ORL-SDN(ACM TOMM'18):支持SDN的HAS在线强化学习(RL)QoE优化框架,包括三个阶段:1)基于感知质量将HAS播放器分组为一系列不相交的集群;2)将码率选择公式化为部分可观察的MDP;3)实现了一个在线Q-learning算法以解决QoE优化问题,并行寻找每个集群的最优码率决策

  • [154] BMS(IEEE Transactions on Broadcasting'18):基于SDN的带宽代理解决方案,将码率决策公式化为凸优化问题,其依赖于凹网络效用最大化(NUM)函数。目标:满足每个会话和每个组的QoE目标

  • [155] A buffer-aware HTTP live streaming approach for SDN-enabled 5G wireless networks(IEEE network'15):在用于HLS服务的5G OpenFlow 无线网络中的基于SDN的管理器。目标:通过在进行码率决策时考虑视频段感知质量和客户端buffer大小,按需分配合适的网络资源(如带宽)以改善QoE。不足:既没有考虑到无线电的突发带宽波动特性,也没有考虑由于用户移动性而导致的切换情况

  • [156] C3(NSDI'15)

  • [157] CFA(NSDI'16)

  • [158] CS2P(SIGCOMM'16)

  • [159] Pytheas(NSDI'17)

[151][152][153]:背景相同

【总结:所有这部分研究的共同特征是都存在一个中央控制器来控制、管理、监控HAS流量。不足:不能很好地扩展并支持系统异构性,还会产生额外的开销,从而影响网络性能。】

 

 

2) Server and Network-Assisted Adaptation

 

  • [16] Enhancing MPEG DASH performance via server and network assistance(2017)

  • [111] SAND(IBC'16)

  • [160] Enhancing MPEG DASH performance via server and network assistance(IBC'15)

 

[16][111][160] SAND:出发点:DASH的客户端驱动方法对网络和服务提供商的控制较少,这为他们在服务差异化方面带来了新的挑战。SAND是一个控制平面,提供客户端-网络、网络-客户端、网络-网络之间的异步通信。SAND从系统(包括客户端)中的不同实体收集度量和状态信息,并向客户端和DANE(DASH感知的网络元素,包括服务器、cache和路径上的其他网络实体)发送反馈。这些反馈信息可以协助客户端进行码率决策,并改进DANE的媒体传送。SAND架构主要基于来自客户端(如QoE度量)和网络(如可用带宽)的反馈,主要由SDN推动实现。

 

 

 

IV. COMPARISON BETWEEN BITRATE ADAPTATION SCHEMES

四类ABR对比结论:

Scheme Class

Pros

Cons

Client-Based

在某些环境下表现出良好的性能

由于缺少中央控制器指导播发器进行码率选择,大多数方案不是全局最优,在多客户端共享瓶颈链路时会性能下降

Server-Based

具有中央控制的优势(如可以获取全局信息)

可能会在服务器上引入较高的复杂度并产生额外开销,进而降低网络效率。此外,这些方案需要修改manifests文件或服务器

Network-Assisted & Hybrid

可以获取网络的全面视图,从而帮助客户端进行码率决策。适用于小型到大型网络,能够显著提高QoE

实际部署较难,因为它们会引入一些可能降低网络性能的开销,且需要网络中其他实体的支持

 

ABR方案完整对比:

 

你可能感兴趣的:(#,ABR,阅读笔记,#,DASH,ABR,码率自适应,DASH,计算机网络,多媒体)