识别用户消费环境的 ABR 流媒体，改善 QoE 和资源使用权衡

本文介绍了确定用户消费视频时的使用环境的重要性，并介绍了一种识别用户使用环境并运用在 ABR 流媒体中的实践策略，以实现在用户体验和资源使用方面带来更好的权衡。

目前智能手机在播放视频时会被使用在很多复杂的场景中，包括使用自带的屏幕和扬声器，以及使用外接的屏幕、投影仪和环绕立体声扬声器系统、使用空间音频的耳机等设备。智能手机也可以通过 wifi 或是蜂窝移动网来接入互联网。演讲者将这一系列用户消费视频时复杂的使用环境称为 Comsumption context(C2)。

C2对于ABR流媒体来说较为重要，它能够决定服务器、CDN、客户端以及网络在内的端到端路径中的资源使用情况，并且也对用户的 QoE(Quality of Experience) 有重要影响。因此应当在 ABR 流媒体中对其进行考虑。下图展示了一个 ABR 流媒体服务的框架，客户端如智能手机可以向服务器请求不同质量与大小的视频与音频片段，并将这些片段整合在一起生成客户端播放的视频。

识别C2的必要性

考虑一个实际音频传输的场景，需要传输的音频轨道有4条，都使用 AAC-LC 编码，采样率为48kHz。其中包括2通道的音频A1(64Kbps),A2(128kbps)，以及6通道的音轨A3(196kbps),A4(390kbps)。虽然6通道的音轨码率更高，但只有在特定的C2和音频设备下才会使得A3-A4带来比A1-A2更好的音频体验。

针对这种情况，演讲者提出了针对立体声扬声器的主观音频质量评估方法。通过使用针对立体声的全参考感知质量模型来对音频质量进行打分。其中参考音频和测试音频都至少需要包含两个通道。模型的框架如下所示。

使用该模型，对上述的A1-A4的音频质量评估结果如下图所示。由于是针对立体声扬声器的场景，因此将A3-A4的音轨进行向下混音。图中的ViSQOL与PEAQ是两种主观评价指标。从图中可以看出，A3-A4需要占据更高的码率，但与A1-A2相比有着接近甚至更差的主观音频质量，且更大的音频码率会导致视频部分所能使用的码率上限降低，影响视频质量。因此对于立体声扬声器来说，使用6通道的音轨是有问题的。

如果识别出客户端所使用的设备为立体声扬声器，则选择传输A1-A2的音轨可以在给定码率上限的情况下提供更高的视频质量。

另一方面，对于显示设备来说，即使手机设备能够支持4K，受限于屏幕尺寸，主观质量提升有限，且4K流带宽要求和能量消耗都较高。而对于流媒体协议来说，目前两种主流的协议为DASH和HLS，二者之间存在明显的区别。DASH说明了不同的音频与视频轨道各自的带宽，而HLS则是说明音频与视频组合的带宽，并没有在Master Playlist中记录各自的码率大小。并且，DASH可以提供所有可能的音频与视频组合，而HLS只能提供一部分子集的组合。

目前使用C2的做法

在这一部分中，主要的目的是从客户端中获取C2信息，并使用这些信息来过滤出不合适的音视频轨道。

在演讲中，演讲者主要以ExoPlayers+DASH的音频轨道过滤为例进行讲解。首先需要将可播放的最大通道数设定为固定值8，这个值与实际设备能力无关。然后确定主音频轨道，即具有最高通道数、采样率、码率的轨道，并保留与主音轨匹配的音轨。在上述的A1-A4的例子中，则会选择A4作为主音频轨道，并排除A1-A2。然而对于智能手机来说，这种选择并不适用于手机上的立体声播放器，这样的操作会导致低比特率的音频轨道被排除在ABR轨道选择之外，导致在低带宽情况下QoE并不理想。

而对于视频轨道的过滤来说，则是以视频轨道的分辨率和宽高比，以及手机上的内置显示屏作为过滤的标准。这种方式的不足同样为没有将C2进行充分考虑，将可能导致高分辨率（和高码率）的视频流传输到小的手机屏幕，以及没有考虑到连接到手机的外部屏幕的显示能力。

在不同的流媒体协议方面，即使是适用相同的过滤规则，由于DASH与HLS之间的区别，客户端与服务器交换的信息不同，也会导致最后的播放体验差距非常大。

总而言之，目前的播放器在适用C2信息时都存在限制，具体表现为对设备能力的不了解，没有做出适合设备能力的选择，以及没有充分处理ABR协议的差异。这些限制极大地影响了在资源使用和QOE方面的权衡。

最佳实践指南

在服务器和客户端方面，服务器可以创建C2特定的清单文件以限制轨道的选择。如果C2在播放过程中发生变化，则需要重复这一过程。这一方案可以在今天的ABR工作流程中实现。而较长期的解决方案则是在ABR协议中建立这种通信能力。如果是基于客户端来实现，由于客户端更容易获取C2信息，因而更容易部署。

对于内部或外部播放器来说，外部播放器可以作为额外的定制策略供用户选择，这种方式下用户难以对C2进行适当的评定。而使用内部播放器则可以自动和动态地评定C2。

因此，针对以上考虑，演讲者采用了基于客户端的设计，使用内部播放器实现，并允许定制操作。整个高层设计如下图所示。

在客户端中，包括一个C2收集器和一个基于C2的过滤器。C2收集器从服务器以及操作系统等低层中收集C2信息，基于C2的过滤器则是根据当前C2信息以及外部的定制化策略来过滤出音频/视频轨道。该设计方案容易被纳入现有的播放器，且不改变ABR逻辑。基于C2的过滤使ABR逻辑更容易选择适当的轨道，即使对普通用户也能做出适当的选择。

在使用C2信息方面，播放器开始播放时就根据当前的C2执行基于C2的过滤。在播放的过程中，动态地确定当前的C2，并相应地更新过滤以及全面地考虑所有相关的C2因素。在具体的过滤策略上，考虑真正给用户带来价值的因素，而不是播放器能够播放的上限和可用的网络带宽。并且由于DASH与HLS之间存在的差别，为特定的ABR协议明确地定制基于C2的码率适应决策协议。

而在播放器如何获得相关的C2信息方面，演讲者表示在研究中展示了安卓以及Chrome平台确实有能力提供底层的C2信息给播放器。

原型验证与实验结果

原型实现方面使用了ExoPlayer进行验证，并将音频轨道数设定为音频播放设备能够允许的最大值，视频分辨率设定为播放设备的分辨率。这些默认的设置都可以被用户修改，并且引入动态的设定，能够获取通知并根据音频视频网络状态进行调整。

在实验的配置方面，实验设备为三星G21 Ultra 5G（立体声扬声器，3200x1440p显示屏），外设包括1080p显示器（24英寸），4K显示器（32英寸），环绕声扬声器（5.1声道）。播放器的选择为标准和原型的ExoPlayer。网络配置方面包括了10个LTE带宽配置文件，4个WiFi带宽跟踪并从一个负载的家庭网络中收集。实验场景方面分别测试了通过手机或家庭WiFi网络在手机上播放，连接到家庭WiFi网络中的外围设备时的播放情况，以及动态设置的情况。

不同网络带宽下的实验结果如下所示。

在蜂窝网络的低带宽下，该原型可以获得更好的视频质量，相近或更好的音频质量以及稍微低一些的资源使用。在蜂窝网络的高带宽下，该原型可以在所有指标下获得更好的音频和视频质量，并且相比于传送的ExoPlayer使用更少的资源，并且在上限为720P时可以获得最好的质量和资源使用的权衡。在家用Wifi下，相比于标准的Exo Player该原型可以使用少得多的资源，并且可以确保相近的音频质量。