概述
本文将陈述现有HTTP自适应流(HAS)主要的比特率自适应算法。HAS比特率自适应算法的重要特点是主要部署在客户端，目标是在带宽波动的情况下保证高质量的用户体验(QoE)。比特率自适应算法可能考虑的因素包括：带宽预测、缓冲区长度、设备特征、用户偏好以及内容特征等等，这些因素拥有不同的权重比例。用户的QoE需要在播放过程中实时的确定，常用的度量包括缓冲时长、启动时延、质量波动的数量和频率以及视频不稳定性等。HAS标准没有指定任何特定的自适应算法，而是留给了系统的设计者来创新和实现适合业务需求的方法。
研究背景
由于过去十几年网络技术的进步、设备能力的提升、音视频压缩机制的优化，视频传输已经成为今天互联网流量的主要部分。Cisco的报告[1]指出：预计到2021年，全球互联网的视频流量占比将达到80%。这种趋势对于尽最大努力交付和传输非实时数据的互联网提出了巨大挑战。2005年，Move Networks提出了HAS协议，使用渐进式下载的方式同等对待常规的Web内容和音视频媒体内容，很快便流行开来，成为流媒体的主导协议。如图1所示，是HAS协议的体系结构。
HAS在应用层使用HTTP协议，运输层使用TCP协议，客户端主动从服务器拉取数据，并使用动态自适应逻辑来应对动态网络变化，提供一个流畅清晰的播放体验。当一个媒体文件需要发布时，原文件被切分为许多相同长度的segment(或称chunk)，每个segment表示1~10秒可播放的媒体内容。每个segment存在不同质量（如不同的码率、分辨率、帧率等）的版本，称为representation。同时，服务器会生成一个索引清单manifest，列出了不同representation和segment的相关信息，可以借此获得媒体文件的基本信息以及每个segment的URL。在一个典型的HAS会话期间，客户端首先从服务器获取媒体文件的manifest，然后持续测量特定的度量，如可用带宽、缓冲区状态、电池、CPU等级等信息，根据这些度量，自适应逻辑做出比特率决策，使得客户端不断获取最合适的下一个segment，在本地将它们存入缓冲，拼接组成一个完整的视频。
图 1：HAS机制
由于HAS的流行，涌现出许多商业化的解决方案，包括微软的MSS[2]，苹果的HLS[3]，Adobe的HDS[4]，为了避免碎片化，MPEG和3GPP制定了HAS的通用标准化协议Dash(Dynamic Adaptive Streaming over Http)[5]。Dash是一个开放式的标准，具体实现尤其是自适应逻辑留给了开发者实现，研究人员为Dash设计了许多各具特色的比特率自适应机制ABR[8]，manifest有特定的格式，称为MPD文件。开源社区实现了许多符合Dash协议的实现，包括dash.js[6]、Shaka[7]等。如今，Dash已经广泛应用于各大流媒体平台，包括Netflix、YouTube、Bilibili等等。
图 2：Dash协议架构
以上是毕业论文文献综述，课题毕业论文、任务书、外文翻译、程序设计、图纸设计等资料可联系客服协助查找。
