DIY编程器网

标题: HTTP ABR 视频传输质量测量说明 [打印本页]

作者: admin 时间: 2014-10-13 10:30
标题: HTTP ABR 视频传输质量测量说明
一、前言

HTTP ABR (Adaptive Bit Rate)是目前最热门的OTT (Over-The-Top)传输技术，典型的有Apple HLS (HTTP Live Streaming)、Microsoft Smooth Streaming、Adobe Zeri Streaming和DASH (Dynamic Adaptive Streaming over HTTP)。

HTTP ABR是以HTTP/TCP协议进行无损传输，且会根据网络带宽自动调整视频码率的视频技术，与传统的UDP承载或广电广播网络承载的有损传输视频业务有很大区别。在网络性能变化，如路由器拥塞丢包时，传统的MOS-V等图像质量指标对于HTTP ABR却保持不变，失去了指标的意义。因此HTTP ABR业务需要全新的一套测量体系来进行视频传输质量测量。Spirent针对该业务所设计的以AS Score为代表的一套指标体系已成为该业务测量的新标杆，并即将成为IETF标准。

二、为什么传统的IPTV视频质量分析方法不适用于HTTP ABR业务？

有损传输的视频与HTTP ABR视频对比

传统的网络视频IPTV业务主要是基于UDP承载视频流的，UDP承载的特点是实时性好，但出现丢包则不会重传，抖动和时延过大的包会被丢弃，对视频流而言是一种有损传输。所以当网络损伤出现时，解码后视频质量会出现劣化，导致马赛克、图像模糊等问题，见下图1。

　　图1、UDP承载视频流出现马赛克和图像模糊

HTTP ABR视频业务是基于TCP承载视频流的，TCP承载的特点是可靠连接，无损传输。丢包后会进行重传，抖动和延时会被客户端的下载缓冲所消化，一般情况下客户不会感知。只有缓冲区的视频播放完又没有及时下载到新的视频片段时，才会出现画面等待并缓冲，见下图2。

　　
　　图2、TCP承载视频流

传统的网络视频质量分析指标是针对视频画面损伤时对视频质量评估的，而当网络性能劣化，例如有路由器出现拥塞导致丢包时，HTTP承载的视频业务是不会丢失媒体包的，画面质量跟发送端是完全一致的，那原有的一些分析指标是否还适用呢？

有损传输的视频质量常用测量指标是否适用HTTP ABR业务？

基于UDP的IPTV视频业务，或广电广播网络的视频业务常用于衡量视频质量的指标常用有如下几种，Spirent VQA视频质量测量方案均已支持：

MOS-V

MOS-V原本是指通过观测者人眼观察视频质量，进行主观1-5分的打分，参见ITU-T P.910（04/2008）。目前广泛在视频质量测试中所使用的MOS-V指标，即通过算法分析客户端所收到的视频编码、帧率、丢包分布、以及图像组结构等，通过算法换算得出等效于人眼主观评价测量的MOS-V得分。

MOS-V适用于HTTP ABR业务吗？

只适用于进行实时视频编码阶段，对于网络传输则失去意义。

如前所分析的，ABR业务采用TCP无损传输，已编好码的视频流（如H.264码流）进入网络（如CDN）后，发送端发出的媒体片段和接收端收到的片段是完全一致的。传输过程中TCP丢包会重传，对于视频流而言即不存在丢包，所以MOS算法所计算的丢包分布是无意义的。即在出现网络层面的丢包时，对于TCP承载的视频业务而言，MOS值是不会改变的。

所以MOS在ABR业务中，充其量只能适用于视频发送前进行视频编码的阶段，即做初步的编码器编码质量对比。

在某些特殊场合，在传输网络中有实时视频转码的网元情况下，MOS也可用于单独衡量转码设备的编码质量。但对于HTTP ABR业务而言，本身就具备提供多种不同的码率码流，适应不同的用户情况，客户端自动选择下载码率，在网络上再做实时转码并不经济，所以该场景在HTTP ABR业务中并不常见。

要特别指出的是，视频传输质量测量目的是以仪表模拟大量用户访问，衡量网络在大流量情况下的服务质量。而编码质量则取决于编码算法，与用户量或网络状态是无关的。例如VOD业务，它是编码软件离线编码后，把文件以非实时的方式送入网络存储（如CDN），再由网络向用户提供服务的。

关键是，对于运营者最关心的传输网络上各个网元的服务质量，例如出现丢包、抖动、延时等，由于不存在视频损伤，MOS指标保持不变。即网络质量变化，用户感知发生变化时，MOS指标无法反应，失去了指标的意义。

MDI

MDI:DF延迟因素指标，指示被测试视频流的延迟和抖动状况。DF单位是ms。DF将视频流抖动的变化换算为对视频传输和解码设备缓冲的需求。

MDI:MLR媒体丢包率指标，网络传输过程中每秒媒体包丢失数，指示媒体包丢失情况。

MDI适用于HTTP ABR业务吗？

完全不适用。

MDI:DF本意是为了指示对解码设备缓冲的需求，特别是电视机顶盒的缓冲有限，缓冲时间通常是毫秒级的。而对于HTTP ABR业务而言解码设备主要是PC和手机等智能终端，它是下载媒体片段的，终端本身就要求有容纳大量文件的缓冲空间，缓冲时间起码是分钟级。MDI:DF指标失去意义了。

而TCP的重传机制本身保证了不会有媒体层面的丢包， MDI:MLR必然为0，失去意义。

VSTQ

视频服务传输质量指标。伴随MOS而出现的，重点关注网络传输中的视频质量，对于TCP无损传输而言是不适用的。

另外还有PSNR峰值信噪比，也是同样，不再累述。

I/B/P帧统计

本意是统计在网络损伤下，视频编码的I/B/P帧分别的接收和丢失情况。同样由于TCP的重传机制，视频编码的I/B/P帧都是100%传送，不会丢失，统计失去意义。

小结

传统的视频质量分析是基于有损传输的，MOS等指标本意是进行初步的综合的视频质量指示，以便做服务质量对比，再进一步做深入的指标分析，例如分析媒体流损伤情况、网络层丢包、抖动、延时等问题，最终找到影响用户体验的原因，并予以解决。

但由于HTTP ABR的特殊性，不存在图像损伤，网络丢包、抖动、延时等网络问题都无法影响到MOS指标，而HTTP ABR业务中，由于网络损伤而真正影响用户体验的主要问题，缓冲等待时间、等待次数、视频码率降低等都无法反应出来。

那么HTTP ABR业务需要怎样的视频质量测量体系呢？

三、需要怎样的指标体系来测量HTTP ABR业务？

HTTP ABR视频传输质量测量体系分为三个层面，Spirent测试方案对应给出了测试的方法和指标：

用户感知层面

Adaptive Streaming Score

Spirent提供了一个综合评估用户体验的，专门针对HTTP ABR设计的指标Adaptive Streaming (AS) score。AS score指示了有多少比例的用户收到最高速率的码流，并持续播放。AS score的范围是0-100，极端情况下“0” 表示所有用户都在最低码率下， “100”表示所有用户都在服务器能提供的最高码率下。

该指标综合指示了用户实际感知：码率包含了分辨率、帧率、色阶、清晰度等图像细节信息，而持续播放与否也反应了网络和服务器原因导致的延迟、丢包、抖动等传输情况。AS反应了用户在HTTP ABR业务中的 QoE。该指标便于测试者作为测试分析的入口。也便于将不同的测试结果进行对比。

在下图的例子中，视频被编码成多个码率，最低码率是64K，最高码率的1.5M。一开始用户都集中在64K最低码率，随时间推移有更多用户从低码率跳到了高码率的视频，在播放一分钟后，所有用户都在使用1.5Mbps的码率视频，对应的Adaptive Streaming Score也从0一直上升到了100。

图3、Adaptive Streaming Score

媒体服务层面

Adaptive Streaming Buffering Wait Times

在线的HTTP ABR媒体流Buffer等待时间，Buffer等待时间是指在这个时间内视频处于图像静止的Loading状态。

Adaptive Streaming Avg. Fragment Response & Download Time

媒体文件片段平均响应时间（从发出GET到收到第一个数据字节）和下载时间（收到第一个字节数据到最后一个字节数据），统计显示两个时间之和，并检查该文件片段是属于哪个视频码率段的，对该码率段的所有响应和下载时间取均值。该指标是指示在某个码率段中文件片段的响应和下载时间。

Adaptive Streaming Active Video Channels

实时显示在线的HTTP ABR媒体流在各个码率段分布情况

图4、HTTP ABR媒体流的码率分布

Fragment Run Statistic

Abort Fragment Request下载文件片段中断次数

Buffer Underrun Fragment用户等待视频下载才能播放的次数，除了用户刚发起新的视频请求播放的之外，在播放过程中该指标在网络理想情况下应为0，出现额外的Underrun则表示有卡顿。

Pre-Cached Fragment 预下载的文件片段数量

Bitrate Shift

码率向上升速的次数Total Upshifts、码率向下降速的次数Total Downshifts、码率维持不变的次数Total Rate Maintaining

其他统计计数
　　Sessions、Channels、Http Requests、Manifest Requests、Fragment Requests的计数统计

网络层面

网络流量、TCP连接统计、TCP SYN/ACK时间统计、Round Trip时间统计、TCP重传超时统计、TCP收到第一个数据包的时间统计、估算服务器响应时间统计、TCP Checksum fail、Bad header length、Bad data length、Duplicate、Out of sequence、Timeout统计等等网络参数，以分析网络层面的抖动、时延、丢包、错包等各种问题。

ABR Scores测量体系正在成为IETF标准

Spirent针对HTTP ABR业务所设计的整套ABR测量指标体系是业界领先的测量体系，已成为该业务测量的新标杆，并已提交IETF即将成为IETF标准。

注1：Spirent是The Internet Engineering Task Force (IETF 互联网工程组)的重要成员，先后制定过很多如RFC 2544等测量领域重要的标准文档。

ITU等标准组织现有的测量标准主要针对的是有损传输的应用场景，目前还没有针对HTTP ABR这种OTT Internet业务的已发布标准。

附录A：HTTP ABR传输机制说明

图8、HTTP ABR视频分发机制

视频源内容经编码器编码形成不同码率的视频文件，一个视频文件包含了一串文件片段和对应的列表。由客户端根据下载的速率情况选择下载什么码率的视频文件。以下以一个文件名为sample的视频文件在Apple HTTP Live Streaming服务器上播放为例说明其码率选择机制。见图9。

图9、码率选择机制

客户端向服务器发起GET请求获取sample.m3u8文件列表，服务器回复200 OK并将文件列表发给客户端。文件列表包含了sample视频所能提供的几种播放码率。

客户端根据自身设置的策略决定是先从最小码率开始，还是从最大，或者从中间码率开始获取视频。本例是设置了从最小码率开始，于是客户端向服务器请求64K码率的文件列表。服务器回复64K码率视频的文件串列表。

客户端根据收到的文件串列表请求获取第1个文件片段TS文件。

到达一定的时间间隔后，客户端自动计算第一个文件片段的下载速率，得知当前下载速率较高，例如下载速率达到500Kbps，则根据第一次所获取的码率列表，改为向服务器请求256K的文件列表，服务器返回256K码率视频的文件串列表。

客户端请求256K文件串列表中的第2个文件片段TS文件

再经过一定时间间隔后，客户端再次计算该文件片段的下载速率，并决定是否改变码率。

注：客户端参考的标准版本
• Microsoft IIS Smooth Streaming Client 1.1
• Apple HTTP Live Streaming draft-pantos-http-live-streaming-06, IETF
• Adobe Flash Video Specification 10.1

欢迎光临 DIY编程器网 (http://diybcq.com/)