CN104349220A - 一种用于智能电视终端的服务质量监测系统 - Google Patents

Abstract

本发明公开了一种用于智能电视终端的服务质量监测系统。该系统主要包括服务质量监测模块、服务质量分析模块及质量监测控制模块。服务质量监测模块负责无差别地抓取所有经过网络端口的数据包，进行丢包、端到端时延的计算和流媒体协议解析，进行服务服务质量监测实现按节目流的计算和监测。服务质量分析模块收集从其他模块传送过来的参数进行分析并定时上报业务商的服务器。质量监测控制模块负责接收来自控制服务器的信令以调整监测策略，如改变上报周期、统计周期、ftp服务器地址等等。该系统具有实时性，对CPU和内存的消耗少，获得的服务质量参数更加接近于播放的实际效果。

Description

一种用于智能电视终端的服务质量监测系统

技术领域

本发明涉及视频点播技术领域，特别涉及一种用于智能电视终端的服务质量监测系统。

背景技术

随着中国数字电视产业的飞速发展，有线数字电视用户继续保持大幅增长，双向改造及网络整合正在快速推进，基于有线网络的增值服务也有了较大的应用推广；电信运营商加大交互式网络电视(International Protocol Television，IPTV)用户发展力度，带宽提升也促进了用户数量的增长。在广电、电信等运营商的大力推动下，数字电视、交互式网络电视等业务的覆盖范围也越来越广，这也对网络的服务质量提出了更高的要求。

目前对于普通网络应用所使用的诸如丢包、时延等离散的服务质量(QoS)评估难以完整刻画视频业务质量是否满足需要。一方面，对于网络服务质量监测往往采用网络数据包的抓取与分析，而现有的网络服务质量监测系统是以解码器输出的数据作为网络数据进行分析，如果解码器包含流媒体数据的纠错功能，就会使得评估不准确。另一方面，相比于客观的服务质量(QoS)参数，用户体验质量(QoE)能够从用户的角度有效地反应视频质量的表现，从而为服务商提供可靠的监测数据。QoE是基于用户的体验来进行衡量的，主要采用主观评测方法，即利用观看人员对图像质量进行主观计分，然而由于主观评测需要有大量人员参与且实时反馈性较差，所以近年来逐步被实时性能较好的无参考客观评测方式所替代。客观评测是一种将监测质量的软探针集成到接收端测试设备中，收集相关参数进行分析的单端评测方法，但是这种方式一般需要复杂的计算，很难集成到智能电视这种弱终端。同时机顶盒或者智能电视作为视频业务的载体，内存和CPU的性能远远不及PC，导致现有的PC抓包软件无法直接在机顶盒上运行。

发明内容

为了克服上述现有技述的不足，本发明的目的在于提供一种可在智能电视用户的终端接收设备上评测用户体验质量的服务质量监测系统。该系统具有实时性，对CPU和内存的消耗少，获得的服务质量参数更加接近于播放的实际效果。

本发明中，作为流媒体业务中间件的可选插件之一，服务质量监测系统通过实时监测设备上的解码缓存的状态以及缓存中的媒体丢失率作为参数，并基于统计和实验数据建立收集的参数和用户体验质量的函数关系，最终给出推算公式来量化当前流媒体视频的用户体验质量等级(平均意见得分，Mean Opinion Score，MOS值)，为服务器进行服务质量的改进提供了参考。本发明针对将来数字电视业务所要面临的复杂网络环境提供了一种可行的实时监测客户端视频质量的系统。通过在流媒体中间件中嵌入服务质量监测模块，封装了质量监控的调用接口，方便开发人员在开发播放程序时使用质量监测模块。同时也屏蔽了机顶盒硬件的差异性，方便移植。

本发明提供的一种用于智能电视终端的服务质量监测系统，主要包括服务质量监测模块、服务质量分析模块及质量监测控制模块。

本发明的技术方案具体介绍如下。

一、模块组成与功能划分

1、服务质量监测模块

服务质量监测模块主要负责监听网口，无差别地抓取所有经过网口的数据包以进行服务质量信息的收集；其通过对抓取的包按照控制协议进行归类，分别统计组播、点播不同点播类型及播放、暂停、快进及快退不同播放状态下流媒体数据包的传输情况。具体如下：

(1)首先将网卡设置为混杂模式，然后根据IP地址在抓取到的数据包中筛选出和本机相关的包进行分析。

(2)流媒体协议的解析。对抓取的包按照控制协议进行归类，如图1所示。其中Internet组管理协议(Internet Group Management Protocol)包用来传输组播命令；传输控制协议(Transmission Control Protocol，TCP)包根据不同的控制协议又分为超文本传送协议(Hypertext Transport Protocol，HTTP)和实时流传输协议((Real Time StreamingProtocol，RTSP)包，超文本传送协议用来传输认证信息和网页请求，实时流传输协议包用来传输点播命令；用户数据报协议(UDP)包中只对使用实时传输协议(Real-timeTransport Protocol，RTP)协议的流媒体数据包进行分析。即如果是实时传输协议/用户数据报协议(RTP/UDP)的流则进行服务质量参数统计，如果是实时流传输协议/传输控制协议(RTSP/TCP)则进行节目流的识别。然后将按流识别的服务质量信息打上时间戳交给服务质量分析模块处理。

(3)丢包计算。通过实时传输协议(RTP)包的序列号来判断单位时间内流媒体数据包的连续性并定量计算出当前网络环境下数据包的丢失率。每隔一定周期，以5秒为例，服务质量监测模块分别统计组播、点播不同点播类型及播放、暂停、快进及快退等不同播放状态下流媒体数据包的传输情况，转发给服务质量分析模块。只有在点播状态下，发送该周期统计数据，包括周期开始和结束时间、收到的数据包数、丢包数、数据量等；如果处于暂停、快进、快退状态，则发送一个填充包。如果一个统计周期内既有正常播放也有暂停、快进或快退操作，则舍弃该周期内的统计数据，只发送一个填充包。

(4)时延统计。对每一路视频流，记录其类型(组播或点播)及请求响应时间(RRT)。组播请求响应时间从发送Internet组管理协议(IGMP)开始，到收到第一个视频包结束。点播请求响应时间从发实时流传输协议(RTP)请求开始，到收到第一个视频包结束。对于时移电视情况则不进行统计。端到端的时延则是通过编码时间戳和相邻数据包的到达时间来计算。

(5)统计HTTP请求次数、HTTP请求失败次数、认证次数、认证失败次数。

2、服务质量分析模块

服务质量分析模块收集和分析服务质量监测模块传送的服务质量(QoS)参数，对播放终端缓冲区的统计信息作出基于用户体验质量(QoE)的评测。再将整理后的用户体验质量(QoE)和服务质量(QoS)信息写入日志文件，并上报服务器。具体介绍如下：

(1)服务质量(QoS)参数的统计与分析。依赖于网络参数侦测模块提供的丢包和时延信息来计算媒体传输指标(Media Deliver Index，MDI)。媒体传输指标对视频流的传输质量标识为延迟因素(Delay Factor，DF)和媒体丢失速率(Media LossRate，MLR)。延迟因素表明被测视频流的延迟和抖动情况，媒体丢失速率表明被测视频流的传输丢包速率。另外为了真实体现不同片源码率下丢包与时延对于视频质量的损伤，服务质量参数还对单位时间内网络实时速率与编码速率的比值进行统计和记录。

(2)用户体验质量(QoE)的评测。通过解码缓冲区内的媒体丢失率和缓冲区下溢时长在整个统计周期内的占比两项信息获得，最后拟合为平均意见得分(MOS)。

①基于缓冲区获取服务质量信息取代基于网络端口的信息

近年来随着智能电视及机顶盒等流媒体终端设备处理能力的上升，用户端在对接收到的媒体包进行解码播放前会进行一些损伤修复的处理。如机顶盒会提供一定大小的解码缓冲区用于缓冲当前的视频流，缓冲的存在可以吸收掉一部分因网络抖动而造成的视频质量损伤。有些终端设备除了抑制抖动的功能以外，还可以对一定程度的网络丢包进行修复，比如可以使用前向纠错(FEC)策略在编解码标准中加入容错逻辑，这样在网络传输时如果存在丢包，那么接收端可以通过冗余信息恢复部分丢失的数据。以上这些损伤恢复机制的出现使得原有的服务质量(QoS)-用户体验质量(QoE)关联模型会和预期的效果有所偏差。因为服务质量相关的参数是在接收端的网口部分探测到的，而网络数据在经过网口后进入解码芯片前还有相应的损伤处理过程，如图2所示，其中有向实线表示业务流程，有向虚线表示质量损伤的传递。所以我们将探测点从损伤修复环节前的网络端口移到损伤修复环节之后的解码缓冲区。

②终端解码缓冲区信息的获取

为了保持客户端视频的正常播放，在网络环境理想的状况下解码缓存中的数据量原则上应该相对稳定且完整的，此时用户的体验是最佳的。一旦缓存中的数据量出现波动或缺失，那么可以认为是网络传输不稳定造成的。比如传输信道的损伤造成了视频流的丢包，而存在丢包的视频流在经过机顶盒的纠错机制后未被完全修复，就会造成缓存中媒体丢失率的上升。除了丢包以外，数据包的时延抖动也会造成用户体验质量的下降。由于流媒体业务对与实时性要求较高，即使不存在丢包，当网络抖动过于剧烈而缓冲区发生下溢时，用户会明显感到画面的卡顿，同样会影响用户的体验质量。为此我们选择解码缓冲区的媒体丢失率及缓冲区下溢时间占比两项参数来衡量用户体验质量。这两项参数相对独立，可以分别获取，并在一个统计周期内将收集到的信息汇报给服务质量分析模块。终端解码缓冲信息的获取需要调用底层解码芯片的播放接口，这部分的代码段以动态库的形式封装在中间件播放器框架内，供播放器适时调用。

(a)媒体丢失率的监测

媒体播放器每将一组实时传输协议的传输流载荷放入缓冲时，需调用接口：

获取传输流服务质量(传输流的地址指针，传输流的长度)；

由于每个传输流包的长度固定为188字节，因此传输流的长度应为188的整数倍，播放器在串行调用了该函数后才可继续执行接下来的播放操作。

首先获取缓冲区中每个传输流包头的控制域的信息(一般复制前40字节)，然后将这组包头序列放入一个环形缓冲区中备用，而模块中的媒体丢失监测线程会从同一个环形缓冲中读取这些包头进行丢失率分析。由于填充环形缓冲的函数由播放线程调用，而读取缓冲的函数由统计线程调用，所以在代码中需要用到线程库的条件变量和线程锁来进行线程同步和互斥，这样当缓冲为空时统计线程会休眠直到有数据可读时才被唤醒。

在对传输流进行丢失率统计时由于传输流包头域的计数字段(continuity_counter)只有4位，因此每隔16个传输流包其序列号会回环。如果单纯依赖计数字段判断丢包的话，那么连续丢失16个整数倍的数据包的情况将不会被纳入丢失统计。

因此这里对于媒体丢失率的统计还需要依赖节目时钟基准(Programe ClockReference，PCR)。如前所述我们定义缓冲区中的媒体丢失率为传输流序列的丢包率,那么可以用如下公式进行定量计算：

${\mathrm{LostRate}}_{\mathrm{ts}}=\frac{{\mathrm{Num}}_{\mathrm{lost}}}{{\mathrm{Num}}_{\mathrm{lost}}+{\mathrm{Num}}_{\mathrm{recv}}}*100\%---\left(1\right)$

其中Num_recv表示已经收到的传输流包数，这是已知的。而为了获得Num_lost(丢失的传输流包数)我们可以进行如下操作。

先在网络无丢包时向传输流序列中截取第一个含有节目时钟基准的传输流包记为P1，然后再找到最后一个含有节目时钟基准的传输流包记为Pn，这样可以根据P1到Pn序列的字节长度近似得到编码速率code_rate。计算方式如下：

${\mathrm{code}}_{\mathrm{rate}}=\frac{{\mathrm{Byte}}_{P_n~P_1}*{{\mathrm{system}}_{\mathrm{clock}}}_{\mathrm{frequency}}}{{\mathrm{PCR}}_n-{\mathrm{PCR}}_1}---\left(2\right)$

其中表示从P₁开始到P_n截止的字节数。PCR_n和PCR₁分别对应P_n、P₁的时钟基准。

然后对于有网口丢包的环境下，计算实时的传输码流速率real_rate:

$\mathrm{real}\_\mathrm{rate}=\frac{{\mathrm{Byte}}_{P_{n^{\′}}~P_{1^{\′}}}*\mathrm{system}\_\mathrm{clock}\_\mathrm{frequency}}{{\mathrm{PCR}}_{n^{\′}}-{\mathrm{PCR}}_{1^{\′}}}---\left(3\right)$

其中表示在有损伤的网络环境下传输流包从P_1′到P_n′的字节数。PCR_n′和PCR_1′分别对应P_n′和P_1′的时钟基准。

那么Num_lost应该使得 $\mathrm{code}\_\mathrm{rate}=\mathrm{real}\_\mathrm{rate}+\frac{188*{\mathrm{Num}}_{\mathrm{lost}}*\mathrm{system}\_\mathrm{clock}\_\mathrm{frequency}}{{\mathrm{PCR}}_{n^{\′}}-{\mathrm{PCR}}_{1^{\′}}}$ 成立，又因为Num_lost＝Num′_lost+16*N(其中Num′_lost表示通过计数字段统计的丢包数，N为某自然数)。所以联立以上两式可以获得较为精准的传输流包丢失率。

(b)缓冲区溢出时长占比

播放器程序需要通过服务质量-初始化接口注册一个回调函数，当下溢情况发生时，播放器使用服务质量-异常中止函数通知服务质量监测模块，而服务质量监测模块的溢出统计线程在收到下溢通知后，调用回调函数获得溢出时长，并在一个统计周期内将溢出时长信息转发服务质量分析模块。

③解码缓冲信息到用户体验质量(QoE)，即平均意见得分(MOS)的映射

(a)平均意见得分函数的拟合

随着统计周期内媒体丢失率和缓冲区溢出时长的取值变化，画面质量也会随之发生变化。通过峰值信噪比(Peak Signal to Noise Ratio，PSNR)全参考对比算法评测用户体验质量，以此作为定量分析平均意见得分(MOS)的标准，会获得平均意见得分与媒体丢失率和缓冲区溢出时长的对应关系，即平均意见得分可视为媒体丢失率和缓冲区溢出时长的二维自变量函数。

(b)分区间一维自变量函数的简化

由于智能电视及机顶盒的处理能力有限，在播放流媒体视频时对系统的实时性要求又比较高，可对复杂的二维计算和拟合进一步简化，对于具有相似“媒体丢失率-平均意见得分”变化情况的溢出区间进行分类。每一具有相似“媒体丢失率-平均意见得分”变化情况的溢出区间进行一次一维拟合，得到函数：

QoE＝f_i(x)       (4)

上式中用户体验质量(QoE)用计算得到的平均意见得分表示，i对应不同的溢出时长百分比的区间，x为该区间上媒体丢失率。每一个溢出区间就对应一个计算平均意见得分的函数。如果用多项式函数来拟合用户体验质量的值，在m个分段的溢出区间上就需要拟合出m个多项式。本系统用最小二乘法构造了近似计算平均意见得分的六次多项式函数：

$\mathrm{QoE}=\left(\begin{array}{c}{\mathrm{\α}}_1\\ {\mathrm{\α}}_2\\ {\mathrm{\α}}_3\\ {\mathrm{\α}}_4\\ {\mathrm{\α}}_5\\ {\mathrm{\α}}_6\\ {\mathrm{\α}}_7\end{array}\right)\×{\stackrel{\‾}{x}}^T=\left(\begin{array}{c}{f}_1\left(x\right)\\ f_2\left(x\right)\\ f_3\left(x\right)\\ f_4\left(x\right)\\ f_5\left(x\right)\\ f_6\left(x\right)\\ f_7\left(x\right)\end{array}\right)---\left(5\right)$

(3)质量参数的同步。服务质量(QoS)参数和用户体验质量(QoE)的评测按照统一的周期进行，本发明中默认值是5秒。由于解码缓冲区的数据和服务质量分析模块的数据来自于不同的进程，两者数据需要根据时间戳标记进行同步，把相近时间戳的节点放到一起进行分析。

(4)日志的上传。将来自网口的服务质量参数和评测用户体验质量的平均意见得分(MOS)按节目分类，并打上时间戳，记录到日志文件中，定时通过文件传输协议(FTP)上报服务器。

3、质量监测控制模块

质量监测控制模块接收远程服务器的控制信令，对质量监测模块的运行模式和相关参数进行更改，如改变上报周期、统计周期、文件传输协议(FTP)服务器地址等等。它还可以获取当前统计周期内的实时质量信息通过超文本传输协议(HTTP)上报给服务端。心跳连接功能主要是向控制服务器定时传送心跳包以确保网络连接正常，服务器亦可通过心跳包判断当前网络中活跃的机顶盒数量。与系统内其他程序的交互过程如图3所示。质量监测控制模块运行以后开启两个线程：信令监听线程和控制命令转发线程，其中信令监听线程通过阻塞调用接收消息(RecvInfo)接口等待控制服务器下发的质量监测信令，一旦信令下发并由质量监控加载进程转送到质量监测控制模块以后，质量监测控制模块会根据信令协议解析服务器所希望进行的操作。控制命令转发线程根据监听线程解析后的命令含义对系统内相关模块执行操作。如果控制信令是要求修改监测参数(如上报周期、统计周期等)，那么质量监测控制模块会将系统内部配置文件中的相关项改为服务器所要求的值，然后通知服务质量分析进程和服务质量监测进程重新载入配置文件、修改全局变量，并使用新的参数工作。如果控制信令是要求获得当前周期的实时质量信息，那么质量监测控制模块会通知服务质量分析进程立即上报当前的网口及用户体验质量的各项参数。

二、模块间的通信机制

服务质量监测系统是为数字电视及ITPV服务商提供视频质量反馈，而对终端用户来说该系统应该是透明的。因此我们需要把这部分的功能集成到电视终端或机顶盒的流媒体业务中间件当中，一方面能够面向上层应用提供统一的调用接口，一方面又不改变用户的操作习惯。本发明中，服务质量监控系统需要实现以下设计目标：1)可以屏蔽底层平台的差异性向上提供统一接口。2)能够方便地实现功能上的裁剪和扩展以满足不同业务商的需要，并且可以方便地从中间件移除和装载功能模块。3)保证监测程序在后台运行的稳定性，其运行逻辑不能影响其他进程的运行。

大部分的流媒体中间件来说其内部逻辑大致可以分为三个层次：业务层、基础服务层、平台适配层。其中业务层为上层应用提供了完整的开发框架和大部分的接口，它按照职责的不同用模块封装了必要的操作系统和播放器调用，使得上层应用可以和底部平台进行沟通。而基础服务层则实现了中间件在应用过程中通用的后台管理功能，比如日志管理、资源管理、安全管理、升级认证、系统配置、图形适配等等。平台适配层主要是为了消除硬件平台、编译器和操作系统的差异以此来解决平台相关性的问题。

1、服务质量监测系统的内部信息传递

(1)质量监控加载进程通过进程间通信来转发功能子进程数据

为了减小流媒体业务中间件模块之间的耦合和互相依赖，方便服务质量监测系统对不同终端的剪裁或扩展，对质量监测系统采用质量监控加载进程来处理，进程本身不负责任何具体的业务处理，而是针对相应的业务逻辑启动不同的子进程来完成，这些由质量监控加载进程启动的子进程需要处理固有业务逻辑，并与质量监控加载进程进行进程间通信(IPC)。子进程之间数据交互通过质量监控加载进程转发，子进程管理示意图如图4所示。

(2)子进程间共享内存管理

由于消息队列和管道方式的数据共享都需要在有限缓冲的内核中保存，而智能电视或机顶盒终端由操作系统分配的可用内核空间非常有限，因此子进程间的内部消息传递采用共享内存管理的方式，同时采用信号量作为辅助的同步机制。这样的设计使得单一功能的内部接口都被绑定到了质量监控加载进程上，如果在系统裁剪时需要取消某一功能，只要在质量监控加载进程处启动子进程时删除对应进程即可，而不需要进行繁琐的模块间接口调整工作。可以方便地开关和控制系统内部数据流的走向。并且由于都和质量监控加载进程打交道，所以通信机制只需要同一套收发函数(RecvInfo和SendIfno)来实现，这组接口函数封装了用信号量来同步的共享内存的通信方式。

(3)内部接口定义

质量监测系统内部所有独立进程模块均通过质量监控加载进程来与内部或外部的其他模块通信，因此模块间的唯一内部接口就是质量监控加载进程与其子进程的通信方式，子进程间的通信则由质量监控加载进程转发。为此所有的质量监测进程要实现统一的通信接口。具体接口定义如下：

发送接口：int发送信息(int共享内存的ID号，(void*)需要传输的数据的缓存地址，int需要传输的数据的字节长度，int接收数据的进程编号)。当一个进程需要向另外的进程传输数据时需调用该接口，这个接口的实际通信对象是质量监控加载进程，质量监控加载进程会根据接收数据的进程编号将接收数据转发给目标进程。返回值为0表示失败，成功则返回发送的字节数。

接收接口：int接收信息(int共享内存的ID号,(void*)用来接收数据的缓存地址,int*用来存储收到的数据长度的变量地址,int*用来存储发送方进程编号的变量地址)。当一个进程需要接收来自另外进程的数据时需调用该接口，这个接口的实际通信对象是质量监控加载进程。返回值为0表示失败，成功则返回接收的字节数。

2、服务质量监测系统的外部接口

外部接口定义了服务质量监测系统与本机或远程服务器上其他进程的通信方式、传输规范和数据流向。服务质量监测系统中具体实现各项功能的子模块并没有对外通信的职责，所有的外部接口都交由质量监控加载进程来接收和转发。图5描述了质量监控加载进程与外部程序和模块的接口。

(1)与控制服务器的接口

用来对服务质量监控模块进行操作控制。它通过超文本传输协议(Http)传输字符串命令的方式与质量监控加载进程建立连接并将控制信令下发，质量监控加载进程中的转发逻辑会将信令传送给质量监测控制模块执行相应操作。每条字符串命令以换行符作为结束，命令中各个参数采用键值对的方式来表达，多个键值对采用固定分隔符”|”来分隔，例如cmd_type＝3|report_interval＝60。

服务控制端所能下发的具体信令有：

启动/停止质量监测：cmd_type＝1\r\n，cmd_type＝2\r\n

修改日志上报周期：cmd_type＝3|report_interval＝60\r\n

修改日志上报地址：

cmd_type＝10|ftp_server_url＝ftp://ftpuser:pwsd12345610.132.140.245:21？ftpperiod\r\n

修改数据统计周期：cmd_type＝4|calc_interval＝5\r\n

实时上报质量信息：cmd_type＝50\r\n

客户端对于控制信令的响应分为上报质量信息和心跳包。

质量信息指标值列表主要包含三个部分，点播指标(点播分组丢失率、比特率、前向纠错分组丢失率)、组播指标(组播分组丢失率、比特率、前向纠错分组丢失率)，终端设备指标(终端IP、内存及CPU使用)，无论是否有值都要一并上报。各性能指标之间用”；”隔开,指标名和值之间用”:”分隔，如果指标中存在回车符，那么将它置换成’^’符号。如果某项指标没有值，则显示[name]:[]。

上报心跳包：cmd_type＝55\r\n

(2)与日志服务器的接口

由业务提供商部署的收集用户终端质量反馈的设备。智能电视或机顶盒端的质量监测系统生成监测日志后通过文件传输协议(ftp)协议上报。

该日志主要涵盖了四部分的信息，第一部分是机顶盒的固有信息包括了ID号、厂商编号、软硬件版本、文件起止时间。第二部分是由服务质量监测模块收集的服务质量数据的分析，主要包括组播请求次数、点播请求次数及相应的失败信息，还包括一个上报周期内丢包率损失区间的统计以及码流损失区间的统计。丢包的损失区间由R1～R5五个等级表示(R1＝0％；R1<R2<＝R1+0.2％；R2<R3<＝R2+0.2％；R3<R4<＝R3+0.2％；R4<R5)。对于码流损失的判断分析进程使用同一时间段内实际码率与编码码率的比值来表征，其损失程度同样用R1～R5五个等级来表示(R1>＝100％,96％<＝R2<100％,92％<＝R3<96％,88％<＝R4<92％,R5<88％)。所有的丢包统计和码流损伤统计都需按照组播、点播、高清、标清分类。第三部分主要是基于节目流的时间戳计算单个统计周期内的丢包率、码流速率、和平均意见得分值。第四部分主要是系统资源消耗情况和系统错误情况的记录。包括CPU的占用率、可用内存大小以及播放出错信息。

(3)与终端主进程的接口

终端主进程是智能电视或机顶盒上最重要的进程，它在开机启动时负责与远端电子节目菜单(Electronic Program Guide，EPG)服务器通信，进行帐号认证和播放页面下载。在用户收看数字电视或IPTV视频节目时它负责调用通用播放器对媒体流进行解码。本发明的服务质量监测系统和终端主进程的外部接口主要有两个：一是开机启动时配置文件的设置与读取、二是缓冲区监测的调用接口。

在服务质量监测系统内部所有的子模块作为独立进程皆由质量监控加载进程启动，而质量监控加载进程则是在开机后由终端主进程启动。在终端主进程启动质量监控加载进程之前它会将监测系统所需要的一些终端配置选项写入文件系统中固定目录下，配置文件以键值对的形式记录相关配置信息，具体如表1所述。

表1 终端配置文件键值对的含义

键名	键值含义
		ftp_server_url	日志ftp服务器地址
stb_ip	终端ip地址
		quality_port	用来和服务器通讯的端口号<可选项>
stb_id	终端设备的身份id
		user_id	用户的ID
user_passwd	用户ID的密码
		pppoe_id	基于以太网的点对点协议用户的ID
pppoe_passwd	基于以太网的点对点协议用户ID的密码
		auth_url	认证平台地址
auth_url_bak	认证平台备份地址
		OUI	厂家编号
epg_url	电子节目单的服务器地址
		stb_sw_version	软件版本号
stb_hw_version	硬件版本号
		stb_upgrade_url	终端升级服务器的地址

stb_upgrade_url_bak	终端升级服务器的备份地址
		quality_upgrade_url	质量监测升级服务器的地址
quality_upgrade_url_bak	质量监测升级服务器的备份地址
		share_memory_key	用于监测系统和终端主进程间共享内存的键值

(4)与监测缓冲区信息模块的接口

服务质量监测系统中的缓冲监测模块是以动态库的方式封装给主进程调用的。它能够通过主进程的调用接口获得当前统计周期内解码缓冲区的媒体丢失率和下溢时长。

动态库提供了四个用于监测缓冲区的函数接口：

①初始化接口

函数原型：int Quality_Init(struct abendParam(*getDecodeBufferInfo)())；

输入参数：struct abendParam(*getDecodeBufferInfo)()为一个函数指针，该函数的功能是返回当前解码缓冲区的信息，函数本身由机顶盒程序实现且在初始化时被注册，在动态库中调用该回调函数后指针的返回值存储在结构体struct abendParam中，该结构体的定义如下：

Struct abendParam{

DWORD currentAvailableSize；//当前缓冲区可用空间大小

DWORD totalSize；//缓冲区最大空间上限

}；

功能描述：每次播放器缓冲区被重新初始化，则需要调用该接口。

返回值：成功返回0，失败则为负值。

②媒体丢失率统计接口

函数原型：int Quality_Get_TsStream(const char*ts_packet_addr,int ts_length)；

输入参数：ts_packet_addr:指向媒体流数据块的只读指针，ts_length:媒体流数据块长度

功能描述：机顶盒程序在每次将缓冲区数据送入硬件解码芯片之前调用该接口。质量监测库代码获得TS流的包头信息后返回。TS包头信息将被用于计算媒体丢失率。

返回值：成功返回0，失败则为负值。

③缓冲区溢出监控接口

函数原型：int Quality_Handle_Abend(int abendFlag)；

输入参数：abendFlag:上下溢出类型标识符，1为上溢，-1为下溢，0为无法识别。

功能描述：机顶盒能够根据底层芯片的回调函数获得溢出的类型是上溢还是下溢，接着调用嵌入库的接口，通过abendFlage进行类型设置。在该函数中动态库代码会根据在初始化接口中注册的函数获得当前解码缓冲区信息。

返回值：成功返回0，失败则为负值。

④注销接口

函数原型：int Quality_Close()；

输入参数：void

功能描述：当不再需要缓冲区监测模块的功能时。主进程调用该函数释放内存关闭处理线程。

返回值：成功返回0，失败则为负值。

本发明的有益效果在于：

(1)服务质量监测模块通过对流媒体协议及点播类型和播放状态的解析，过滤不必要的数据包，能降低终端对CPU和内存的消耗，并将丢包、端到端时延的计算传递给服务质量分析模块，实现按节目流的计算和监测；

(2)服务质量分析模块考虑到终端播放器的纠错功能，将由网口探测的丢包率等服务质量参数模式改进为播放器端解码缓冲区探测方式，通过接收解码缓冲中媒体丢失率和缓冲区下溢时长来评测用户体验质量，使获得的服务质量参数更加接近于播放的实际效果。

(3)所述质量监测控制模块接收来自控制服务器的命令，可以及时地调整监测的策略。

附图说明

图1服务质量监测模块的流媒体协议解析流程图。

图2有容错机制的损伤传递示意图。

图3质量监测控制模块与外部进程的交互图。

图4质量监控加载进程的子进程管理示意图。

图5质量监测系统外部接口通信。

图6缓冲区的参数与平均意见得分的映射关系测试架设图。

图7终端CPU和内存占用率统计。

图8丢包率的统计。

图9请求响应时间(RRT)统计。

图10本发明服务质量监测系统各模块间联系的逻辑视图。

具体实施方式

本发明服务质量监测系统各模块间联系的逻辑视图如图1所示。服务质量监测模块实现无差别地抓取所有经过网络端口的数据包，进行丢包、端到端时延的计算和流媒体协议解析，实现按节目流的计算和监测。服务质量分析模块收集从其他模块传送过来的参数进行分析并定时上报业务商的服务器，包括网口服务质量参数的分析与统计、用户体验质量(QoE)的评测、检测日志的生成与管理、监测信息的上报。服务质量参数的统计与分析依赖于服务质量监测模块提供的丢包和时延信息来计算媒体传送指标(MDI)，用户体验质量通过接收解码缓冲中媒体丢失率和缓冲区下溢时长在整个统计周期内的占比信息来评测。质量监测控制模块负责接收来自控制服务器的信令以调整监测策略，如改变上报周期、统计周期、ftp服务器地址等等。

一、缓冲区的参数与平均意见得分(MOS)的映射关系建立

缓冲区的参数与平均意见得分(MOS)的映射关系可以通过图6所示的架构图来完成。其中视频的原始画面存储在视频源端服务器中，该服务器通过网络链路串联一个网络损伤仪(软件版本IPWave 3.0)连接到华为5108IPTV高清机顶盒上，损伤仪可以模拟网络损伤的情况，机顶盒上已经集成了质量监测系统的缓冲区监测模块，可实时反馈缓冲区的媒体丢失率和下溢时长。用户体验质量(QoE)测试仪通过无损伤网络链路同时连接到流媒体的源端和输出端，对两端的画面质量使用峰值信噪比(PSNR)全参考对比算法，可以获取用户体验质量(QoE)，进而获得平均意见得分(MOS)，也就确定了缓冲区的媒体丢失率、下溢时长和平均意见得分的映射关系。实验中视频编码采用h.264格式，码率是8Mbps，统计周期为5秒。

缓冲区的参数与平均意见得分(MOS)的对应关系如表2所示。水平值表示丢包率从0到200的变化，倍数是1/2000。垂直方向表示了溢出时长从0增加到10毫秒的变化。

表2 缓冲区的参数与平均意见得分(MOS)的映射关系  丢包率：1/2000

以表2为数据，可以拟合出媒体丢失率和下溢时间占比到平均意见得分的二维映射关系函数。由于智能电视及机顶盒的处理能力有限，在播放流媒体视频时对系统的实时性要求又比较高，可对复杂的二维计算和拟合进一步简化，对于具有相似“媒体丢失率-平均意见得分”变化情况的溢出区间进行分类。每一具有相似“媒体丢失率-平均意见得分”变化情况的溢出区间进行一次一维拟合。用最小二乘法构造了近似计算MOS值的六次多项式函数，式5的具体系数为

α₁＝(2.1*10^-4 -0.0067 0.082 -0.471 1.336 -2.261 5.029)

α₂＝(2.6*10^-3 -0.0083 0.103 -0.624 1.955 -3.333 4.864)

α₃＝(3.0*10^-4 -0.0099 0.127 -0.803 2.642 -4.517 4.781)

α₄＝(4.0*10^-4 -0.0131 0.166 -1.033 3.283 -5.129 4.385)

α₅＝(4.3*10^-4 -0.0141 0.180 -1.126 3.554 -5.312 4.040)

α₆＝(2.8*10^-4 -0.0096 0.128 -0.841 2.825 -4.463 3.482)

α₇＝(3.1*10^-4 -0.0103 0.134 -0.858 2.774 -4.143 3.113)

$\stackrel{\&RightArrow;}{x}=\left(\begin{array}{ccccccc}{x}^6& x^5& x^4& x^3& x^2& x& 1\end{array}\right)$

在用户体验质量的评测中函数f₁～f₇分别对应适用于近似溢出区间在[0,1)、[1,2]、(2,4]、(4,5]、(5,7]、(7,9]、(9,10]的平均意见得分。由于在平均意见得分(MOS)评级标准里最小值取1.0，因此实际运算时对于1.0以下的计算值仍算作1.0。

二、服务质量监测系统性能测试

为了测试服务质量检测系统的性能以及分析结果的准确性，我们将系统放在华为高清机顶盒EC5108上运行，机顶盒配置为：CPU为BMIPS4380V4.4FPU V0.1，CPU主频为404.48MHZ，内存为125M，并在网络环境中加入仿真模拟器，模拟网络的丢包和延时。

1、CPU及内存消耗

在程序运行过程中，对机顶盒进行随机的操作，如点播、直播、快进、快退等，并以5s为周期对CPU和内存的占用率进行记录，如图7所示。在程序运行过程，程序对CPU的占用率基本稳定在0.2％-3％之间，满足电信规定的CPU占用率维持在10％以下的要求，而内存占用率始终维持在0.2％，即消耗内存0.25M，满足电信规定的内存占用率在5％以下的要求。

2、丢包率的统计

在程序运行中，使用损伤仪对网络丢包进行模拟，模拟结果如图8所示。在测试中，使用损伤仪分别对网络进行0.2％的丢包，0.5％的丢包和1％的丢包模拟，程序以5秒为一个周期对收到的数据包总数和丢包个数进行统计，并依此算出丢包率。对于监测到的丢包率做出统计：在0.2％丢包的情况下，测试结果基本稳定在0.2％左右；在0.5％的情况下，测试结果在0.46％-0.52％的范围内；在1％的情况下，测试结果在0.95％-1.05％的范围内。在使用损伤仪模拟的过程中，损伤仪给出的模拟丢包率是一个平均值，而包的丢失在整个程序运行过程中是随机出现的，这就使得模拟丢包率越大，而在实际抓包过程中丢包率的计算结果波动也会越大。

3、请求响应时间的统计

同时在程序运行过程在正常情况下和增加时延的情况下对请求响应时间(RRT)进行了统计，对于统计情况描述如图9所示。正常情况下组播请求响应时间(RRT)的测试结果大部分都是在0-300ms范围内，点播请求响应时间(RRT)的测试结果大部分是在200-700ms范围内，电信规范给出的正常RRT应该维持在1秒以内，超过1秒将会造成用户体验质量的下降。在增加时延后的网络，在请求响应时间(RRT)的测试中也有所反映，如在增加网络延时1秒和2秒的环境下，请求响应时间(RRT)的测试结果完全能够反应出增加的时延。

4、实测与监测平均意见得分(MOS)的对比

在播放的过程中对比机顶盒的实时监测策略与用户体验质量测试仪的数值，如表3和表4所示，可以发现本系统的平均意见得分(MOS)和测试仪的真实结果非常接近，效果较为理想。

表3 终端质量监测系统给出的平均意见得分(MOS)

媒体缺失率：单位(1/2000)

表4用户体验质量测试仪给出的平均意见得分(MOS)

媒体缺失率：单位(1/2000)

说明书附录：术语与缩略词列表

Claims (5)

1.一种用于智能电视终端的服务质量监测系统，其特征在于，其包括服务质量监测

模块、服务质量分析模块及质量监测控制模块；其中：

所述服务质量监测模块负责收集服务质量信息，其无差别地抓取所有经过网络端口的数据包，进行丢包、端到端时延计算和流媒体协议解析，以实现按节目流的计算和监测；

所述服务质量分析模块分析服务质量监测模块传送的服务质量参数，对播放终端缓冲区的统计信息作出基于用户体验质量的评测，再将整理后的用户体验质量和服务质量信息写入日志文件，并定时上报业务商的服务器；

所述质量监测控制模块接收远程服务器的控制信令，对质量监测模块的运行模式和相关参数进行更改，如改变上报周期、统计周期、文件传输协议FTP服务器地址；此外，该模块还获取当前统计周期内的实时质量信息通过超文本传输协议HTTP上报给服务端。

2.根据权利要求1所述的服务质量监测系统，其特征在于，所述服务质量监测模块进行服务质量信息收集时，其对抓取的包按照控制协议进行归类，分别统计组播、点播不同点播类型及播放、暂停、快进及快退不同播放状态下流媒体数据包的传输情况；具体流程如下：

（1）将网卡设置为混杂模式；

（2）根据IP地址在抓取到的数据包中筛选出和本机相关的包进行筛选；

（3）流媒体协议的解析：对抓取的包按照控制协议进行归类；其中Internet组管理协议包用来传输组播命令，传输控制协议TCP包根据不同的控制协议又分为超文本传送协议HTTP和实时流传输协议RTSP包，超文本传送协议用来传输认证信息和网页请求，实时流传输协议包用来传输点播命令，UDP包中我们只对使用实时传输协议RTP协议的流媒体数据包进行分析；

（4）丢包计算：只有在点播状态下，发送该周期统计数据，包括周期开始和结束时间、收到的数据包数、丢包数和数据量；如果处于暂停、快进、快退状态， 则发送一个填充包；如果一个统计周期内既有正常播放也有暂停、快进或快退操作，则舍弃该周期内的统计数据，只发送一个填充包；

（5）时延统计：对每一路视频流，记录其类型及请求响应时间RRT，其类型为组播或点播，组播请求响应时间从发送Internet组管理协议开始，到收到第一个视频包结束，点播请求响应时间从发实时流传输协议请求开始，到收到第一个视频包结束；

（6）统计HTTP请求次数、HTTP请求失败次数、认证次数、认证失败次数。

3.根据权利要求1所述的服务质量监测系统，其特征在于，所述服务质量分析模块中，将由网口探测的丢包率服务质量参数模式改进为播放器端解码缓冲区探测方式；同时建立了缓冲区探测信息与用户体验质量的映射关系，采用缓存中的媒体丢失率和缓冲区的下溢时长作为影响用户体验质量的输入。

4.根据权利要求1所述的服务质量监测系统，其特征在于：所述质量监测控制模块中采用定时向控制服务器发送心跳包的方式确保网络的正常连接，以便控制服务器获得网络中活跃的智能电视终端的数量。

5.根据权利要求1所述的服务质量监测系统，其特征在于：所述服务质量监测系统中进程采用内存共享通信机制及外部接口的定义方式。