一种基于移动互联网视频用户感知和分析的方法及系统

技术领域

本发明涉及移动互联网技术领域，特别涉及一种基于移动互联网视频用户感知和分析的方法及系统。

背景技术

随着4G网络的全面普及和终端性能不断提升，视频业务也随之迅速发展，视频业务在全网业务流量占比和重要性不断提升，从16年初的统计结果来看，视频播放类业务已占4G业务总流量的40％以上，并且还在不断上升。视频业务客户感知不仅取决于网络质量，更取决于“端管云台”各环节共同发挥的作用，亟需从基于网络本身的质量管理向注重客户感知的端到端横向一体化质量保障机制转变。建立视频业务端到端质量管理机制是确保客户视频业务感知的关键，是4G时代集中性能管理的重要应用之一。

现在视频业务在网络中表现出来的特点如下：

1、越是用户密集处、网络质量覆盖越好的地方，视频访问量越多；

2、视频类业务的用户感知对于网络情况最敏感，对于网络质量的依赖度也最高。

3、移动互联网中视频协议类型以HTTP为主，辅以少量的RTSP、RTMP

视频种类：正规视频访问请求中mp4、ts、flv格式最多，占据所有被访问视频类型的80％以上，之后依次为mpg/mpeg、3Gp等格式类型；另外，还有swf、gif等使用较多，此两种可归纳为“非典型”的类(似)视频媒体文件。

现有技术方案

关于视频业务流量的筛选，现在的主流厂家都主要通过从url中过滤关键字或者依赖content-type的类型来判断视频业务流量。

而现在运营商中流行的视频用户感知方案主要有两类：

第一类主要依赖于移动集团下发的《中国移动集中性能管理应用落地手册第XX分册—视频业务端到端业务质量分析V1.0》。

此方案几个关键指标定义如下：

1)指标名称：视频播放成功率

指标定义：统计时间段内视频播放成功比例。

指标算法：∑(传输足够初缓时间播放数据的次数/合成视频请求总次数)/N×100％

1、初缓时间：首次播放视频所需的缓存时间。不同网站模型略有不同。需要分网站做不同的配置。

2、足够数据：流媒体码速*初缓时间。

3、合成视频：一个视频文件，根据不同网站的播放模型，可能分成多个会话和get请求，需要对一个视频的多次请求进行关联合成。

2)指标名称：视频播放等待时长

指标定义：从点击视频链接到视频开始播放的时间。若视频前播放广告，则广告时间不算在内。

指标算法：Σ(传输足够初缓时间播放数据的时刻-合成视频请求时刻)/N

1、足够初缓时间播放的数据：见上

3)指标名称：视频播放平均停顿次数

指标定义：从视频开始播放算起，在播放过程中由于各种网络原因产生停顿的次数。

指标算法：Σ(停顿次数/合成流媒体成功播放次数)/N

1、停顿次数＝流媒体码速*(传输时长-二次缓存时长)>＝传输时长内的实际数据量的次数。

2、传输时长：从上次停顿判断到此次停顿判断的间隔时间。

3、二次缓存时长：首次播放后，出现停顿时视频所需缓存时间。一般小于初缓时间，需要分网站做不同的配置。

4、合成流媒体成功播放次数：即传输足够初缓时间播放数据的次数，定义详见“视频播放成功率”指标。

4)指标名称：初始缓冲成功率

指标定义：SP向MS发送“TCP媒体数据(初始缓冲器为满)”消息的次数。

指标算法：∑(传输足够初缓时间播放数据的次数/Get响应成功的合成视频请求总次数)/N×100％

5)指标名称：初始缓冲总时长

指标定义：从TCP媒体数据消息到TCP媒体数据(初始缓冲器为满)消息的平均时长。

指标算法：Σ(TCP媒体数据消息到TCP媒体数据(初始缓冲器为满)消息的平均时长)/N

第二类为安徽移动主导的漏桶算法：

1)指标名称：缓冲区定义

指标定义：已经下载的流量中尚未播放的内容需要播放的时间

指标算法：缓冲区大小＝视频下载量/视频播放速率-视频播放时间

1、视频下载量由探针直接获取；

2、视频播放速率可通过FLV文件头中videodatarate获取或视频总大小/总时长

3、视频播放时间＝当前时间-视频开始播放时间-中断时长，视频开始播放时间则是下载量达到播放器定义的缓冲区门限时的时间；

2)其它视频播放状态及KQI指标统计判定

1、初始缓冲状态：用户请求视频资源后，视频播放时间为0、视频下载量逐渐增加，因此缓冲区大小由0开始增长。当缓冲区大小达到缓冲区门限时，视频开始播放。此时可统计得到视频初始缓冲时长；

2、播放状态：随着下载、播放的进行，缓冲区大小逐渐增加后开始减少，当缓冲区量减少到0时视频播放中断。此时可统计得到视频中断次数，并得到视频中断起始时间点。

3、暂停状态：视频播放暂停后，播放不再进行、下载继续，当缓冲区大小重新大于门限后重新开始播放。此时可计算获得播放中断时长。

4、缓冲区门限值：需要根据各个播放器进行分析获取。

5、缓冲区大小＝视频下载量/视频播放速率-视频播放时间

现有技术方案存在的问题

移动集团算法存在的问题如下：

1、初缓时间和二次缓冲时间是根据网站不同做的纯人工设定；

2、视频卡顿判断算法是一种“妥协方案”，满足这个条件不一定会卡顿(因为未考虑之前缓冲足够仅仅只是某个判断周期内下载量不够的情况)，不满足这个条件也可能会发生卡顿(因为如果之前的缓冲消耗了，“流媒体码速*传输时长>＝传输时长内的实际数据量”就可能会发生卡顿)

3、还有一些指标定义，如初始缓冲成功率、初始缓冲总时长的定义只适合部分协议(如RTMP和RTSP)，因为“从TCP媒体数据消息到TCP媒体数据(初始缓冲器为满)消息”的行为并不是所有协议或者所有SP都会存在的。

4、未考虑各种不同格式的视频中的参数对于缓存和用户感知的影响，导致算法一开始依赖的参数即不准确。

以上几个问题都会直接导致其它所有指标都不准；

安徽算法的问题如下：

虽然考虑到了“不同SP、不同播放器版本存在的缓冲设置不同、需要进行单独分析进行优化”，但漏桶模型未完全考虑实际情况，比如都是按照漏桶放完了再开始补充流量考虑的；

未考虑各种格式文件真正有用的数据块到来对算法判断的影响；

未考虑操作系统、文件格式中指定缓冲对整体算法的影响。

总之，无论是采用移动集团算法还是安徽移动算法，都无法精确地反应移动互联网视频用户的访问行为和用户感知情况。

发明内容

为了更加精准地反应移动话联网视频用户的访问行为和用户感知情况，提高网络业务质量，提高数据准确率和可用性，针对现有技术的缺陷，提供一种基于移动互联网视频用户感知和分析的方法和系统。通过精确筛选视频流量、拆分各种视频格式中的特定字段、设计视频感知分析方法，可获得网络中较为精确的用户端感知情况，再结合用户位置信息(基站、GPS信息)可对运营商网络进行问题定位，提升网络质量。

本发明所采用的技术方案如下：一种基于移动互联网视频用户感知和分析的方法，其包括如下步骤：

步骤100：视频业务定义，采集http里头的URL信息、content-type消息及内容特征字段，通过content-type、URL及内容特征字段综合判断用户通过移动互联网访问的内容是否为视频；

步骤200：视频内容解析，通过对各种视频内容格式进行组包、拆解和分析，取出与视频感知有关的关键参数和关键包到达时间点，其中，与视频感知有关的关键参数包括：视频初始缓冲时间及视频初始缓冲对应的缓存大小、视频二次缓冲时间及视频卡顿之后二次播放时的已缓冲的数据大小、视频二次缓冲或卡顿开始时剩余缓存大小；

步骤300：解析用户访问的SP以及用户使用的终端操作系统情况，并对上述与视频感知有关的关键参数进行修订和调整；

步骤400：对用户观看视频时的上述各种指标数据进行分析，通过该指标数据判断该以判定互联网的网络状况并输出，其中，该指标数据包括：初始缓冲成功率、初始缓冲时长、视频播放时长、视频卡顿或中断时长及次数。

在上述步骤100中，对视频内容的判断具体包括：

步骤101：获取URL信息中的关键字参数；

步骤102：采集http头部的content-type消息，判断content-type指定的业务类型，搭配业务类型库和视频格式的对应关系表；

步骤103：采集http头部之后的body内容中的内容特征，对于压缩或编码过的数据要进行实时解压或反编码工作，取出内容特征字段；

步骤104：根据上述步骤101、102及103采集到的特征，判定视频流量。

在上述步骤200中，对视频内容进行解析具体包括：

步骤201，将视频内容收下来后，在内存中进行组包，将网络包负荷中的内容组成后面可以完整分析的视频格式内容；

步骤202，拆视频格式结构，从视频内容格式中取出分辨率，码率、缓冲时间；

步骤203，拆解视频包，判断视频包中结构的类型，其中，判断的类型包括信息头、索引头、音频段及视频段；

步骤204，取出与视频感知有关的关键参数和关键包到达时间点，其中，取出的与视频感知有关的关键参数至少包括：视频初始缓冲对应的缓存大小、视频卡顿之后二次播放时的已缓冲数据大小、视频缓冲或卡顿时剩余缓存大小。

在步骤300中，对用户访问的SP信息的解析的具体过程包括：

步骤301、通过移动终端app上报的信息、http user-agent字段、手机imei与系统对应关系表获得操作系统信息；

步骤302、通过host、IP、url库、App特征，识别出不同的SP，并针对不同的SP进行参数微调；

步骤303、获取到操作系统和SP信息后，对视频初始缓冲对应的剩余缓存大小，视频二次缓冲对应的剩余缓存大小以及视频卡顿之后二次播放所需缓存的大小进行综合调整。

在上述步骤202中，拆解视频结构的方法包括：

从视频格式为mp4、mov、3Gp、mpg、Avi中直接解析出分辨率、码率、视频时长；

从视频格式为wmv、rmvb中获取视频指定的初始缓冲时间值；

从TS格式的视频PMT_Stream结构中解析出视频的编码方式，以及视频内容对应的TS结构的PID，根据PID找到指定的PES结构，取出所有payload_unit_start_indicator为1的PES头包，取出里面的PTS信息；从TS的PMT_Stream结构中获取到的编码方式中可获知相应的视频编码方式，进而获得相应的分辨率和码率；

对H.264格式的视频内容，对NALu头进行解码，根据ProfileIDC字段的不同，套用不同的解析方式，获得分辨率，码率信息。

在步骤301中，优先使用app上报的信息以及user-agent信息来判断操作系统信息，手机imei与系统对应关系表作为判断操作系统类型的依据或者辅助判断依据。

基于本发明的另一方面，还提供一种基于移动互联网视频用户感知和分析的系统，所述系统包括:

视频内容判定模块，用于采集http里头的URL信息、content-type消息及内容特征字段，综合判断用户通过移动互联网访问的内容是否为视频；

视频格式分析模块，通过对各种视频内容格式进行组包、拆解和分析，取出与视频感知有关的关键参数和关键包到达时间点，其中，与视频感知有关的关键参数包括：视频初始缓冲时间及视频初始缓冲对应的缓存大小、视频二次缓冲时间及视频卡顿之后二次播放时的已缓冲的数据大小、视频二次缓冲或卡顿开始时剩余缓存大小；

调整模块，用于解析用户访问的SP以及用户使用的终端操作系统情况，并对上述与视频感知有关的关键参数进行参数修订和调整；

视频感知分析模块，对用户观看视频时的上述各种指标数据进行分析，通过该指标数据判断互联网的网络状况并输出网络状况结果，其中，该指标数据包括：初始缓冲成功率、初始缓冲时长、视频播放时长、视频卡顿或中断时长及次数。

进一步地，上述视频内容判定模块对视频内容的判断具体包括如下步骤：

获取URL信息中的关键字参数；

采集http头部的content-type消息，判断content-type指定的业务类型，搭配业务类型库和视频格式的对应关系表；

采集http头部之后的body内容中的内容特征，对于压缩或编码过的数据要进行实时解压或反编码工作，取出内容特征字段；

根据上述采集到的特征，综合并判定视频流量。

进一步地，上述视频格式分析模块对视频内容进行解析具体包括如下步骤：

组包处理，将视频内容收集下来后，在内存中进行组包，将网络包负荷中的内容组成后面可以完整分析的视频格式内容；

拆视频格式结构，从视频内容格式中取出分辨率，码率、缓冲时间；

拆解视频包，判断视频包中结构的类型，其中，判断的类型包括信息头、索引头、音频段及视频段；

取出与视频感知有关的关键参数和关键包到达时间点，其中，取出的与视频感知有关的关键参数至少包括：视频初始缓冲对应的缓存大小、视频卡顿之后二次播放时的已缓冲数据大小、视频缓冲或卡顿时剩余缓存大小。

进一步地，上述调整模块对视频感知的关键参数进行修订的过程包括：

通过移动终端app上报的信息、http user-agent字段、手机imei与系统对应关系表获得操作系统信息；

通过host、IP、url库、App特征，识别出不同的SP，并针对不同的SP进行参数微调；

获取到操作系统和SP信息后，对视频初始缓冲对应的剩余缓存大小，视频二次缓冲对应的剩余缓存大小以及视频卡顿之后二次播放所需缓存的大小进行综合调整。

本发明所公开的一种基于移动互联网视频用户感知和分析的方法及系统，达到了如下技术效果：

1、重点参数的取值更加科学，更贴近真实情况；如初始缓冲，二次缓冲，预留缓冲等都考虑到了视频本身、SP、操作系统的影响，以及网络带宽和SP的人为行为(广告)对于主视频播放本身的影响都考虑在内，尽量使得参数更精准；

2、KQI指标定义更科学；相比之前的算法依赖的KQI指标算法只能针对一小部分流量来说，我们的KQI定义更加全面地考虑了各种协议，各种场景，指标定义和指标算法本身都更加贴近真实场景。

3、判断方式更精准；区别于一般传统的按周期监控周期内的下载整流量的方法来说，我们的流量判断方式考虑到了视频文件本身的包结构，去除了包结构中对于用户感知影响较小但是对于算法准确性影响较大的部分。比如考虑初始缓冲的时候我们就看到达客户端的视频段的量是否满足了初始缓冲的要求，而不是看所有的视频流量是否满足了初始缓冲播放的要求，虽然这里面的区别可能不到1秒钟，但是对于整体初始缓冲大部分小于3秒的视频行为来说，占比是很高的。

4、判断方法整体更加精确；除了以上3点，本方法本身考虑的流程就尽量模拟了视频播放的流程，而不是简单的对流量的判断。比如考虑到了视频播放时有时会预留一部分缓冲而不是全部耗尽缓存后才停止播放，又如考虑到了二次缓冲会因为网络情况不好在多次卡顿后自动增长，考虑到了视频播放广告对于主视频初始缓冲下载的影响等。

5、本发明的技术方案能够提高对移动上网用户单业务流量最大的视频业务用户感知定义的准确性，并且通过分析得到的业务指标体现移动互联网网络状况及辅助问题定位。

附图说明

图1为本发明所述的基于移动互联网视频用户感知和分析的方法的流程示意图。

图2为本发明所述的基于移动互联网视频用户感知和分析的系统的原理示意图。

图3为本发明实施例应用“压力阀门漏桶”原理对视频业务感知分析方法的原理图。

图4为为本发明实施例应用“压力阀门漏桶”原理对视频业务感知分析方法的模拟结构图。

具体实施方式

以下结合附图对本发明作进一步详细说明，但不作为对本发明的限定。

本发明通过精确筛选视频流量、拆分各种视频格式中的特定字段、设计视频感知分析算法，可获得网络中较为精确的用户端感知情况，再结合用户位置信息(基站、GPS信息)可对运营商网络进行问题定位，提升网络质量。

参照图1所示，图1示出了本发明所公开的一种基于移动互联网视频用户感知和分析的方法，需要说明的是，该方法不限于2/3G和LTE网络，其它有类似行为的网络(如互联网)均可使用。该方法主要包括如下步骤：

步骤100：采集http里头的URL信息、content-type消息及内容特征字段，通过Content-type、URL及内容特征字段综合判断用户通过移动互联网访问的内容是否为视频；

步骤200：视频内容解析，通过对各种视频内容格式进行组包、拆解和分析，取出与视频感知有关的关键参数和关键包到达时间点，其中，与视频感知有关的关键参数包括：视频初始缓冲时间及视频初始缓冲对应的缓存大小、视频二次缓冲时间及视频卡顿之后二次播放时的已缓冲的数据大小、视频二次缓冲或二次卡顿开始时剩余缓存大小，还可以包括视频分辨率，其中，视频的初始缓冲时间为可选；

步骤300：解析用户访问的SP以及用户使用的终端操作系统情况，并对上述与视频感知有关的关键参数进行修订和调整；

步骤400：对用户观看视频时的上述各种指标数据进行分析，通过该指标数据判断该以判定互联网的网络状况并输出，其中，该指标数据包括：初始缓冲成功率、初始缓冲时长、视频播放时长、视频卡顿或中断时长及次数。

参照图2所示，基于本发明的另一方面，还提供了一种基于移动互联网视频用户感知和分析的系统，该系统包括:

视频内容判定模块，用于采集http里头的URL信息、content-type消息及内容特征字段，综合判断用户通过移动互联网访问的内容是否为视频；

视频格式分析模块，通过对各种视频内容格式进行组包、拆解和分析，取出与视频感知有关的关键参数和关键包到达时间点，其中，与视频感知有关的关键参数包括：视频初始缓冲时间及视频初始缓冲对应的缓存大小、视频二次缓冲时间及视频卡顿之后二次播放时的已缓冲的数据大小、视频二次缓冲或二次卡顿开始时剩余缓存大小；

调整模块，用于解析用户访问的SP以及用户使用的终端操作系统情况，并对上述与视频感知有关的关键参数进行参数修订和调整；

视频感知分析模块，对用户观看视频时的上述各种指标数据进行分析，通过该指标数据判断互联网的网络状况并输出网络状况结果，其中，该指标数据包括：初始缓冲成功率、初始缓冲时长、视频播放时长、视频卡顿或中断时长及次数。

本发明的技术方案通过精确筛选视频流量、拆分各种视频格式中的特定字段、设计视频感知分析方法，可获得网络中较为精确的用户端感知情况，能够提高对移动上网用户单业务流量最大的视频业务用户感知定义的准确性，再结合用户位置信息(基站、GPS信息)可对运营商网络进行问题定位，提升网络质量，并且通过分析得到的业务指标体现移动互联网网络状况及辅助问题定位。

下面来详述本发明的对视频感知和分析的步骤：

步骤100，视频内容判断；通过Content-type+URL+内容特征字段综合判断用户通过移动互联网访问的内容是否为视频。

其中，在步骤100中，对视频内容的判定，具体包含如下步骤：

步骤101，获取URL信息中的关键字参数；但仅凭此参数还具有不确定性，有的URL未必会具备关键信息，或者有时还会存在迷惑性，如路径中混杂有视频后缀的关键字但实际访问内容非视频，单独使用此放法对于判断视频流量的充分性和必要性都不足；

步骤102，采集http头的content-type消息，判断content-type指定的业务类型，搭配业务类型库和视频格式的对应关系表，作为判断http视频流依据之一，此参数因为可选字段以及受浏览器影响较重，故单独使用充分性和必要性也略显不足和不准确，需进行进一步判定；

步骤103，采集http头部之后的body内容中的内容特征，对于压缩或编码过的数据要进行必要的实时解压或反编码工作，取出内容特征字段(如MP4的开头几个字节可能为0x00 00 00 1C 66 74 79 70或者0x00 00 00 18 66 74 79 70或者0x00 00 00 20 66 74 79 70，其中第四个字节不固定，为控制长度的字节)。此为最强判断因素，作为对url和content-type指定的业务类型存在疑问或者无明显特征时的业务类型判断依据。

步骤104，根据101、102、103步骤采集到的特征点，判定视频流量。通过上述三个因素的结合，基本能够判定视频流量。

步骤200，视频内容解析；通过对各种视频内容格式进行组包、拆解和分析，取出对后面的视频感知方法定义时需要的关键参数和关键包到达时间点。其中，取出的与视频感知有关的关键参数至少包括：视频初始缓冲对应的缓存大小、视频二次缓冲对应的缓存大小、视频二次缓冲或二次卡顿开始时剩余缓存大小；

视频初始缓冲时间，即为视频初始播放时需要缓冲的数据对应的视频播放时长；二次缓冲时间，即视频卡顿之后二次播放时的已缓冲数据对应的视频播放时长；视频时长为视频本身可供播放的时长属性，体现到视频格式上时，即为视频的Duration(持续时间)参数。

在步骤200中，还具体包括如下步骤：

步骤201，组包，将视频内容收下来后，在内存中进行必要的组包，将网络包负荷中的内容组成后面可以完整分析的视频格式内容。

步骤202，拆视频格式结构，从视频内容格式中取出分辨率(包含帧高和帧宽)、码率、缓冲时间。其中mp4、mov、3Gp、mpg、Avi等视频格式中可直接按照规范文档解析出分辨率(帧高、帧宽)、码率、视频时长；

Mkv格式是是基于EBML结构的，需解出EBML头下面的Segment头内部的SegmentInfo头中的Duration字段。

针对wmv、rmvb/rm等格式，可获取视频指定的初始缓冲时间值(为可选字段)。

TS格式的稍微复杂，从TS格式的视频PMT_Stream结构中解析出视频(video)的编码方式，以及视频内容对应的TS结构的PID，根据PID找到指定的PES结构，取出所有payload_unit_start_indicator为1的PES头包，取出里面的PTS信息，每个PTS信息都表示着这个PES包所包含内容的播放时间点，最后一个PTS信息减去第一个PTS信息，即为整个TS视频的播放时长。

从TS的PMT_Stream结构中获取到的编码方式中可获知相应的视频编码方式(如H.264，大部分的TS都是此编码方式)，进而获得相应的分辨率，码率等信息。

H.264格式的视频内容，可对NALu头进行解码，根据ProfileIDC字段的不同，套用不同的解析方式，获得分辨率，码率等信息。

步骤203，拆解视频包，判断视频包中结构的类型(信息头、索引头、音频段、视频段)，以提供算法根据到达的包的类型判断所需要缓存的数据量是否完整，而不是简单的按照整体的下载量是否满足初始缓冲时间*码率作为条件来判断用户是否已经开始正常播放，因为信息头和索引头所处的位置一般都在视频内容的前段，所以这一分析方法在精确分析初始播放时间上的作用尤其重要。

步骤300，解析用户访问的SP以及用户使用的终端情况，并对上述与视频感知有关的关键参数进行修订和调整。

在步骤300中，还具体包括如下步骤：

步骤301，通过手机app上报信息、http user-agent字段、手机imei与系统对应关系表获得操作系统信息(系统信息包含系统版本号、系统id、系统对应的硬件信息等)。其中，优先使用app上报的信息以及user-agent字段信息，手机imei与系统对应关系表仅作为判断操作系统类型(Android、IOS)的依据或者辅助判断依据。因为Android和IOS对于视频播放策略的不同(而且操作系统的不同也会影响软件版本的不同)，同一种操作系统不同版本之间对于视频播放策略的不同，比如Android4.0之前的默认值就和之后版本的不一样，所以有必要将操作系统识别后，再对视频初始缓冲对应的缓存大小(ready_buffer)，以及视频卡顿之后二次播放时的已缓存数据大小(cache_buffer)进行调整。

步骤302，获取SP信息，并对操作系统及SP进行分析。通过host、IP、url库、App特征，可以识别出不同的SP。同时分各视频格式中的结构(BOX)的，以每个存放视频内容的结构到达时间点为判断节点(而非简单的以周期性判断下载量为判断条件)，判断累计下传到客户端的视频内容是否满足初始缓冲时间的播放需求。不同的SP对于各种格式的视频有不同的播放策略，需要针对不同的SP进行参数上的微调，其中，此方法中的操作系统的不同以及SP软件的不同(包含软件版本的不同)主要影响到ready_buffer和cache_buffer两个基础参数的默认值，另外，SP软件的不同和视频源本身也同时对x_time_buffer产生影响，其中，x_time_buffer是“当缓冲的数据(Buffer)在播放过程中低于这个值时视频会停止播放”的一个阈值，也可以理解为二次缓冲(卡顿)开始时剩余缓存大小。

步骤303，参数调整。获取到操作系统和SP信息后，对ready_buffer、cache_buffer、x_time_buffer参数进行综合调整。

步骤400：对用户观看视频时的上述各种指标数据进行分析，通过该指标数据判断该以判定互联网的网络状况并输出各种指标数据体现移动互联网的网络状况，其中，该指标数据包括：初始缓冲成功率、初始缓冲时长、视频播放时长、视频卡顿或中断时长及次数。

以步骤100中所筛选出的视频流程作为步骤400的基本输入源，以步骤200中获取的码率、分辨率、视频格式以及步骤300中获取的参数所推算出来的ready_buffer、cache_buffer、x_time_buffer，设计本发明的“压力阀门漏桶”的计算方法。

参照图3所示，图3示出了本发明采用“压力阀门漏桶”原理进行视频业务感知分析的原理示意图。

图3中，各参数含义表示如下：

1、初缓时间

视频初始播放时需要缓冲的数据对应的视频播放时长；

2、二次缓冲时间

视频卡顿之后二次播放时的已缓冲数据对应的视频播放时长；

3、视频时长

视频时长为视频本身可以供播放的时长属性，体现到视频格式，即为视频的Duration参数；

4、Ready_buffer_size

视频初始播放时需要缓冲的数据大小

Ready_buffer_size＝初缓时间*bitrate

5、Cache_buffer_size

视频卡顿之后二次播放时的已缓冲数据大小

Cache buffer size＝二次缓冲时间*bitrate

6、实时缓冲区(Buffer)大小

Buffer大小即当前时间的全部已下载量减去已播放量，即上图中：

Buffer＝上面第一区段的面积-下面第二区段的面积；

7、X Time_buffer_size

当缓冲的数据(Buffer)在播放过程中低于这个值时视频会停止播放；

8、T0；

视频请求发起时刻；

9、T1

Buffer第一次>Ready_buffer_size的时刻；

10、T2

广告播放完的时刻；

11、Tx0

正式视频开始播放时刻；Tx0＝Max(T1,T2)；即无广告的时候即为传输足够初缓时间播放数据的时刻，有广告的时候为广告播放完时刻和传输足够初缓时间播放数据的时刻中的较大值；

12、TyN

N＝0,1,2…..

当Buffer从>X Time buffer size变为<X Time buffer size的时刻

13、TxN

N＝1,2,3……

当Buffer再次从<cache buffer size并且<X Time buffer size变为>cache buffer size的时刻

如图4所示，在步骤401中的各参数定义好之后，按照“压力阀门漏桶”原理，当第一次ready buffer充盈后(ready buffer一般略大于Cachebuffer，可视作阀门桶第一次压开阀门所需的压力要大一点)，视频开始播放，当buffer水位低于x_time buffer后，视频停止播放(视作阀门压不开了)，当水位再次充盈至cache buffer后，视频开始再次播放。Buffer是否达到相应水位线以“有效流量”来判断，即以视频内容段到达的多少来判断，以避免信息块、索引块等流量对精确判断的影响。

上述几个关键的指标输出规则如下：

1、视频播放等待时长

指标定义：从点击视频链接到视频开始播放的时间。在现有技术中，部分文献要求若视频前播放广告，则广告时间不算在内，但经实际测试，播放广告对于客户的感知有影响，视频播放等待时长应该考虑观看广告时间内下载的数据的影响；

指标算法：

a)如果无广告：视频播放等待时长＝Tx0-T0；

b)如果有广告，且广告时长计算入视频播放等待时长则：视频播放等待时长＝Max(0,T1-T2)+T2-T0＝Max(T2-T0,T1-T0)；此值考虑到了广告时长；

c)如果有广告，不考虑广告时长，只考虑广告播放完后用户等待时长，则：视频播放等待时长＝Max(0,T1-T2)；

2、视频播放停顿次数

指标定义：二次缓冲时长为Buffer量从低于X Time_buffer_size到满足Cache_buffer_size需要的下载时间。

指标算法：二次缓冲时长＝TxN-Ty(N-1)，N＝1,2……如第一段二次缓冲时长＝Tx1-Ty0；

最后，对上述应用“压力阀门漏桶”原理，分析得到的用户指标数据进行输出，以判定用户感知结果，最后输出的主要字段大体如下：

现有的视频用户感知分析算法存在三点明显缺陷：关键参数全是人工设定的固定值，仅区别了SP的不同，对操作系统、视频本身的属性影响未做考虑；一些算法的定义依赖的数据包基础不是普适存在的，只对很小一部分流量有作用；对视频业务本身的特点未考虑完全，比如设计的算法未考虑到视频播放时的余留，监控周期不科学，初始缓冲设定方法不对等，这样都使得算法本身的设计就存在问题，用户感知的准确性判断就更无从谈起。

与最接近的现有技术相比，本发明解决了上述三个主要缺点，本发明技术优点如下：

1、重点参数的取值更加科学，更贴近真实情况；如初始缓冲，二次缓冲，预留缓冲等都考虑到了视频本身、SP、操作系统的影响，以及网络带宽和SP的人为行为(广告)对于主视频播放本身的影响都考虑在内，尽量使得参数更精准；

2、KQI指标定义更科学；相比之前的算法依赖的KQI指标算法只能针对一小部分流量来说，我们的KQI定义更加全面地考虑了各种协议，各种场景，指标定义和指标算法本身都更加贴近真实场景。

3、判断方式更精准；区别于一般传统的按周期监控周期内的下载整流量的方法来说，我们的流量判断方式考虑到了视频文件本身的包结构，去除了包结构中对于用户感知影响较小但是对于算法准确性影响较大的部分。比如考虑初始缓冲的时候我们就看到达客户端的视频段的量是否满足了初始缓冲的要求，而不是看所有的视频流量是否满足了初始缓冲播放的要求，虽然这里面的区别可能不到1秒钟，但是对于整体初始缓冲大部分小于3秒的视频行为来说，占比是很高的。

4、判断方法整体更加精确；除了以上3点，本发明方法本身考虑的流程就尽量模拟了视频播放的流程，而不是简单的对流量的判断。比如考虑到了视频播放时有时会预留一部分缓冲而不是全部耗尽缓存后才停止播放，又如考虑到了二次缓冲会因为网络情况不好在多次卡顿后自动增长，考虑到了视频播放广告对于主视频初始缓冲下载的影响等。

上述说明示出并描述了本发明的若干优选实施例，但如前所述，应当理解本发明并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述发明构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本发明的精神和范围，则都应在本发明所附权利要求的保护范围内。