自适应比特率在移动应用中——这是什么、算法与协议

什么是自适应比特率？

自适应比特率（ABR）是一种流媒体内容的方法，其中视频文件以不同比特率和分辨率编码为多个版本，播放器实时自动选择合适的版本。用户在当前互联网速度下获得无缓冲的最佳可能质量。

与传统渐进式下载（progressive download）不同，ABR不需要加载整个文件——播放器请求短段所需质量，并可以在段之间切换到其他比特率。这使得该技术在网络速度不断变化的移动应用中不可或缺。

ABR的发展历史

自适应流媒体技术首次由Move Networks于2006年商业化实施，用于ABC频道的广播。2009年，Apple推出了HTTP Live Streaming（HLS），成为第一个广泛使用的基于HTTP的ABR标准，至今仍在iOS生态系统中占据主导地位。

2012年，MPEG发布了MPEG-DASH（Dynamic Adaptive Streaming over HTTP）标准，作为不依赖于特定供应商的通用ABR格式。DASH受到所有主要平台的支持，是唯一被ISO采纳的ABR标准。

ABR如何工作？

ABR流媒体过程从内容准备阶段开始：原始视频被编码为多个不同比特率的版本——例如144p、360p、720p、1080p和4K。每个版本被分割为相同持续时间的段，通常为2、4、6或10秒。

在服务器上创建清单文件，描述可用的表示（representations）、其比特率、分辨率、编解码器和段的链接。播放器下载清单，分析它，并从最低比特率开始播放以实现快速启动。

ABR清单结构（MPEG-DASH MPD）

<!-- MPEG-DASH MPD manifest -->
<MPD profiles="urn:mpeg:dash:profile:isoff-live:2011">
  <Period>
    <AdaptationSet mimeType="video/mp4">
      <Representation id="720p" bandwidth="2800000"
                     width="1280" height="720">
        <SegmentTemplate duration="4"
                        media="seg_$Number$.m4s"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

动态比特率切换

在播放期间，客户端上的ABR算法持续监控网络和缓冲区状态。如果带宽下降，播放器以较低比特率请求后续段以避免缓冲。当网络改善时，比特率增加。

比特率之间的切换发生在段边界处，这使得质量变化对用户几乎不可察觉。现代播放器可以在不同版本之间同步关键帧，以便切换在没有视觉伪影的情况下发生。

ABR协议：HLS、MPEG-DASH、Smooth Streaming

三种主要ABR协议在视频流市场中占主导地位：Apple的HLS、作为开放标准的MPEG-DASH和Microsoft的Smooth Streaming。每个协议定义清单格式、分段方法和加密机制。

HTTP Live Streaming（HLS）

HLS——使用最广泛的ABR协议，内置于iOS、tvOS和macOS上的Safari。清单格式基于扩展的M3U播放列表，其中主播放列表（master playlist）包含指向不同比特率和分辨率版本（variant streams）的链接。

每个版本引用其自己的带有段列表的媒体播放列表。HLS通过滑动窗口机制支持直播，其中旧段被删除，新段随到达而添加。

MPEG-DASH

MPEG-DASH——2012年被ISO/IEC 23009-1采纳的唯一ABR标准。与HLS不同，DASH使用XML清单（MPD——媒体呈现描述），不依赖于特定的容器格式——支持fMP4、WebM等。

DASH提供灵活的分段：段在同一流内可以有不同的持续时间，从而优化延迟和HTTP请求开销之间的比率。对于直播，DASH支持段模板（SegmentTemplate）。

协议性能比较

根据Bitmovin（2025）的测试，HLS和DASH在启动时间和比特率切换频率方面表现出可比的性能。HLS由于硬件支持在iOS上提供更低的延迟，DASH由于更灵活的ABR算法配置在Android上更受青睐。

自适应比特率算法

ABR的核心——比特率选择算法，确定接下来请求哪个版本。存在三个主要算法系列：基于吞吐量（throughput-based）、基于缓冲区（buffer-based）和混合（hybrid）。每种方法都有其优点和局限性。

基于吞吐量的算法

基于吞吐量的算法基于先前段的下载速度估算网络带宽。算法选择不超过测量带宽80–90%的最大比特率，为波动留出余量。

这种方法的缺点是对短期速度飙升的敏感性。如果网络在段下载期间急剧下降，带宽估算会偏低，质量会不必要地降低。

基于缓冲区的算法

基于缓冲区的算法根据播放器缓冲区的填充程度做出决策。如果缓冲区填充超过70%，算法提高比特率；如果缓冲区低于20%——急剧降低质量以防止缓冲。

主要优点是短期网络下降时没有虚假降低，因为缓冲区平滑了波动。缺点是响应带宽稳定变化的反应缓慢。

混合算法和机器学习

现代播放器，如ExoPlayer和AVPlayer，使用混合算法，结合带宽估算和缓冲区状态。ExoPlayer默认使用DefaultTrackSelector ABR算法，该算法考虑两个参数。

在2024–2025年，基于历史数据预测未来网络变化的基于ML的算法正在积极部署。Netflix、YouTube和Twitch使用自己的机器学习模型优化比特率选择，将切换次数减少30–40%。

移动应用中的ABR

移动应用由于蜂窝网络（4G/LTE、5G）的不稳定性和设备计算能力有限，对ABR提出了特殊要求。播放器必须快速适应网络变化，同时最小化能耗和数据流量使用。

根据OpenSignal（2025）的数据，城市条件下4G平均速度在5到50 Mbit/s之间变化，移动中可能降至1 Mbit/s。ABR算法必须在1–2个段内切换比特率，以避免进入隧道或电梯时的缓冲。

ExoPlayer中的ABR配置（Android）

val trackSelector = DefaultTrackSelector(context).apply {
    setParameters(buildUponParameters {
        setMaxVideoSizeSd()
        setAllowVideoMixedMimeTypeAdaptiveness(true)
        setPreferredVideoRoleFlags(
            roleFlags(C.ROLE_FLAG_DESCRIBES_VIDEO_AND_AUDIO)
        )
    })
}

val adaptiveTrackSelectionFactory =
    AdaptiveTrackSelection.Factory()
val player = ExoPlayer.Builder(context)
    .setTrackSelector(trackSelector)
    .setMediaSourceFactory(
        DashMediaSource.Factory(dataSourceFactory)
    )
    .build()

移动设备的ABR优化

对于移动应用，快速初始加载（time-to-first-frame少于2秒）至关重要。建议从最低可用比特率开始播放，然后随着缓冲区填充提高质量——start-low-and-rise策略。

能耗也很重要：硬件解码加速应该用于所有比特率。在旧设备上软件解码高比特率（1080p及以上）可能导致过热和节流。

ABR和性能分析

ABR质量的关键指标：比特率切换次数（switches）、到第一帧的时间（TTFF）、切换次数与总观看时间的比率。QoE（体验质量）质量指数计算为比特率、切换惩罚和缓冲惩罚的加权总和。

为了监控ABR，建议从播放器收集分析数据：当前比特率、缓冲区大小、带宽、切换次数和类型。数据帮助内容提供商优化可用比特率集，并针对特定受众调整分段。