1.1.1 帧内预测模式

帧内预测是利用当前待编码宏块周围的已编码并重建的宏块预测当前宏块的值。亮度块帧内预测根据亮度块大小分为16× 16和4× 4两种。

16× 16亮度预测模式包括4种不同的预测模式。如图1所示, 垂直预测模式是通过上一行的像素点得到待编码宏块的像素值; 水平预测模式通过左一列的像素得到宏块的像素值; DC直流预测模式通过上一行和左一列的像素均值得到宏块的像素点; 平面预测模式利用“ plane” 函数、左一列像素点及上一行像素点得到宏块的像素点^[9]。

图1

Fig.1

	Figure Option ViewDownloadNew Window
	图1 16× 16亮度预测模式Fig.1 Brightness of 16× 16 prediction model

4× 4亮度预测模式由8种不同方向的预测模式和DC直流预测模式组成^[9]。图2为除DC预测外的8种预测模式的方向。

图2

Fig.2

	Figure Option ViewDownloadNew Window
	图2 4× 4预测模式的8种不同方向Fig.2 4× 4 prediction of 8 different directional patterns

1.1.2 动态选择算法

采用基于宏块特征和缩减预测模式选择范围的思想, 实现帧内预测模式选择速度的提升。首先根据宏块特征对4种不同的16× 16亮度预测模式进行判断, 选出能够满足宏块特征的16× 16帧内预测模式。如果没有能够满足的, 根据宏块特征选择合适的4× 4亮度预测模式候选集, 最后根据遍历候选集中的亮度预测模式, 求得最适宜的亮度预测模式。

本文对宏块特征的计算受到了文献[10, 11]的启发。对4种不同的16× 16亮度预测模式分别进行分析, 垂直预测模式计算待编码宏块的像素点在垂直方向上的平滑度, 这里采用方差来衡量平滑程度:

var_v=116∑y=015116∑x=015[p(x, y)-my]21

式中:p(x, y)为宏块(x, y)处的像素值; m_y为宏块第y列像素点的均值。

水平预测模式计算水平方向上的平滑度为:

var_h=116∑x=015116∑y=015px, y-mx22

式中:m_x为宏块第x行像素点的均值。

DC预测模式计算宏块整体的平滑度为:

var_dc=1256∑y=015∑x=015px, y-mxy23

式中:m_xy为宏块的所有像素点的均值。

平面预测模式适用于水平或垂直方向有倾斜纹理的图像。这里分别使用两条对角线及周围的像素点的方差来预测平面模式的适用程度, 公式为:

var_l=1146∑x=015[p(x, y)-ml]2+varls4varls=∑x=15∑y=015-xpx+y, y-mx02+py, x+y-m0x25

式中:m_l为宏块左上到右下对角线上像素点的平均值; m_x0为宏块从(x, 0)点出发到底边的与对角线平行的斜线上像素点的平均值; m_0x为宏块从(0, x)点出发到底边的与对角线平行的斜线上像素点的平均值。

var_r=1146∑x=015[p(x, y)-mr]2+varrs6varrs=∑x=15∑y=015-xp15-x-y, y-m'x02+p15-y, x+y-m'0x27

式中:m_r为宏块右上到左下对角线上像素点的平均值; m'_x0为宏块(15-x, 0)点出发到上边的与对角线平行的斜线上像素点的平均值; m'_0x为宏块从(0, x)点出发到上边的与对角线平行的斜线上像素点的平均值。

得到4种16× 16的亮度预测模式的宏块特征的计算公式之后, 需要确定阈值来决定该16× 16亮度预测模式是否适用, 并且确定采用何种具体模式, 即依次比较var_dc、var_v、var_h与三个阈值大小来确定DC、垂直和水平三种模式之一。对于平面模式的选择, 是进一步地将var_l、var_r与两个阈值比较大小, 满足其中一个条件就可以确定。若16× 16模式不适用, 则在4× 4亮度预测模式候选组中选择开销最小的亮度预测模式作为最佳模式。通过比较4个候选组{0, 5, 7, 2}、{1, 6, 8, 2}、{4, 5, 6, 2}、{3, 7, 8, 2}对应的var_v、var_h、var_l和var_r值, 选择值最小的对应组作为候选组。

由于16× 16的预测方向在4× 4中同样会进行预测, 仅选择可能性较高的模式作为当前块的候选模式, 这样可以在很大程度上减少帧内模式的计算量。采用16× 16预测模式中的预测方向对4× 4预测模式进行分组, 同时根据16× 16的结果在4× 4的预测模式中选出一组预测模式作为候选组, 再在候选组中选出最佳的预测模式即可。由于DC预测是在任何条件下都能使用的预测模式^[2], 于是将DC预测加入到所有组中。接下来直接使用X264中提供的方法计算候选分组中的各个模式的代价, 选择出代价最低的预测模式作为最佳预测模式。

1.2.1 传输速率调整方式

目前, 根据网络状况进行传输速率调整的方法主要包括基于试探和基于预测两种^[12]。由于基于试探的传输速率调整方式在网络状态发生改变时速率改变过大, 会引起比较明显的网络波动, 对实时性要求较高的视频数据的传输非常不利, 所以本文选择基于预测的传输速率调整方式作为拥塞避免阶段的码率自适应方法。这种方法主要根据网络模型, 使用预测公式来预测网络的有效带宽。当前应用最广泛的是文献[13]中提出的计算公式, 如下:

br=PacketSize/[RTT×2Ploss/3+RTO×3×3Ploss/8×Ploss×(1+32Ploss2)](8)

式中:br为传输速率; RTT为往返时间; RTO为重传间隔, 取4倍的往返时间; P_loss为丢包率; PacketSize为发送的数据包的大小。

1.2.2 码率自适应算法

本算法所需参数主要依靠由接收端周期性向发送端发送的接收端报告RR数据包。RR包是RTCP数据包的一种, 其中包含了间隔抖动、已接收报告数、累计丢包数等重要参数。服务器根据这些参数计算检测当前网络状况, 并根据检测结果进行码率的自适应调整。本文的码率自适应算法主要使用丢包率P_loss和传输的往返时间RTT。

计算丢包率P_loss首先需要获取RR数据包中的fraction lost字段, 并将该字段数值除以256。往返时间RTT的计算公式如下:

RTT=T_rev-LSR-DLSR9

式中:T_rev为接收到该RR包的时间; LSR为RR包中最新SR的时间戳; DLSR为从最新SR到发送RR的时间间隔。

基于网络状况的码率自适应是为了避免网络拥塞, 而TCP协议对于网络拥塞进行的控制算法又是成熟而且得到实践检验的, 所以本文受到TCP协议的启发, 对数据传输过程细化为慢启动和拥塞避免两个阶段。

(1)慢启动阶段。在此阶段, 将TCP协议的慢启动思想应用到监控视频开始的传输阶段。通过量化参数QP的动态改变来实现码率的调整。QP值越大, 码率越小, 图像的质量越差, 从图像质量和性价比的角度考虑, 设置QP_MAX和QP_MIN为量化参数最大值和最小值。

首先初始化QP=QP_MAX, 然后根据RTCP包反馈的丢包率P_loss进行操作选择。当P_loss=0时, 使用公式:

QP=max(QP-2×(1-QP')-τ, QP_MIN)(10)

进行QP的调整(QP'为QP的均值, τ 为参数), 由于QP越大, 发送到网络上进行传输的视频数据量越少, 网络状况也就越好, QP的变化速度在QP越大的情况要快一些, 所以设定的QP变化公式中随着QP值变小, QP变化速度是减慢的。否则, QP不变, 统计接下来连续5个RR包中有3个丢包率非0或者QP减小到QP_MIN, 则进入拥塞避免阶段。

(2)拥塞避免阶段。当本算法码率与网络带宽达到适应后, 进入到拥塞避免阶段。根据网络状况的变化进行码率的自适应调整。

首先, 根据求出的传输速率br可计算得到当前网络状况满足的起始帧量化参数start_qp^[14]:

start_qp(br)=a×brb+c11

式中:a、b、c为常系数。

再根据start_qp和THR对QP的值进行调整, 当start_qp< QP-THR时, 说明网络处于轻载状态, 需要降低量化值, QP取start_qp和QP_MIN中较大值。当start_qp> QP+THR时, 说明当前网络处于过载的状态, 需要提高量化值, QP取start_qp和QP_MAX中较小值。

当QP-THR≤ start_qp≤ QP+THR时, 说明网路处于满载状态, 无需改变编码量化值。其中, THR是调整QP的阈值。设置THR的计算公式为:

THR=14×1+QPQP+κ12

式中:κ 为参数。

从式(8)可以看出, 当丢包率为0时, 无法预测网络的有效带宽, 所以当本系统收到第一个丢包率为0的包, 量化参数不变, 当收到后面连续丢包率为0的RR数据包, 再收到后续的丢包率为0的RTCP包后, 则利用式(10)减小QP的数值, 从而提高网络带宽的利用率。

本系统服务器主要包括4个部分, 如图4所示。

图4

Fig.4

	Figure Option ViewDownloadNew Window
	图4 系统服务器结构Fig.4 Structure diagram of system server

首先, 服务器利用Linux关于视频设备内核驱动V4L2(video4linux2)提供的接口, 编写驱动程序驱动摄像头读取视频数据, 再对视频数据进行压缩编码; 由于本系统编码器是基于开源的H.264编码器X264实现的, 且X264要求输入的视频每帧图像都为YUV420格式, 所以在编码前需要将读入的YUYV图像格式视频数据转换成YUV420。然后, 将转换X264分别对每帧YUV420格式的图像进行编码, 编码后即可得到标准H.264格式的视频数据。将编码后的视频数据保存到服务器中作为回放的视频数据, 同时在有用户请求实时监控视频时, 通过开源流媒体服务器Live555将内存中的视频数据用于发送给用户。

X264和Live555作为开源的解决方案面向的对象是视频文件, 而本系统需要实现的是实时视频数据的处理, 所以本系统对它们的输入部分分别进行了修改。同时由于这两个开源项目是相互独立的, 而本系统需要它们作为服务器整体的两个部分, 所以本系统通过多线程的方式对它们的工作过程进行调整, 使用外部变量将使Live555能够获得X264编码后的视频数据。

本系统客户端以开源项目VLC为基础, 同时实现了Windows和Android两个平台下的客户端播放器。首先对VLC进行编译, 生成可调用的库文件, 然后通过调用VLC库函数实现客户端的整体功能。

Windows系统下VLC播放器的编译需要在由Cygwin仿真得到的Linux环境下进行, 图5为编译过程。

图5

Fig.5

	Figure Option ViewDownloadNew Window
	图5 Windows系统下VLC编译过程Fig.5 VLC compilation process in Windows system

图5中第4步需要清理的第三方库提供的Linux可执行文件都位于/usr/win32/bin文件夹中, 它们是moc、rcc和uic。第5步中源码和第三方库存放的位置为/cygwin/home/username(username为登陆的用户目录)。经过最后一步make package-win32-base后, 即可得到客户端实现所需的动态库文件libvlc.dll、axvlc.dll、libvlccore.dll和npvlc.dll, 同时还生成了VLC的插件库。

对于本系统中Windows系统下的客户端的实现, 首先需要创建一个MFC的工程; 然后, 将VLC的核心库、插件库以及客户端实现所需的头文件都加入到项目中; 接下来即可基于VLC和MFC进行代码实现。

客户端的代码实现过程如下:

(1)调用libvlc_new函数创建并初始化一个libvlc对象。

(2)调用libvlc_media_new_path函数根据libvlc对象和媒体路径(可以是多媒体文件的文件存储路径, 也可以是流媒体文件的网络路径, 如:rtsp://192.168.3.111/test.264)创建可播放的媒体对象。

(3)调用libvlc_media_player_new函数, 根据libvlc对象创建播放器对象。

(4)调用libvlc_media_player_set_media函数, 将播放器对象与媒体对象进行连接。

(5)获取播放窗口的句柄, 调用libvlc_media_player_set_hwnd将播放器对象与播放窗口进行关联。

(6)调用libvlc_media_player_play函数, 发送播放命令, 接收视频数据进行播放。

以上就是基于VLC实现Windows系统下客户端的主要步骤, 并且这些步骤有严格的先后顺序。