问题现象：

1. 细微的、但是仔细看肉眼能感觉到的跳帧现象，也即Mars所描述的运动状态下，画面不够平滑的问题。
此问题需要在VideoPlayer.ocx再加一些Queue的机制，或者是直接根据每个frame里的timestamp去做播放控制。但是目前尚未实现。

2. Decode效能问题，在上海研发环境下测试（配置：P 4 2.0G, 512M RAM）同时解四路视频，CPU即会飙到35% 左右。
此问题尚在跟海康那边沟通，我们希望的结果是由海康提供他们的H.264的原始编码格式，再加上Clarence在D-Link 2.0版的做法加以实现。但是目前为止尚未得到海康正面的回应。

问题分析：

由于目前VideoPlayer.ocx的做法相对简单，从Callback接收到视频流开始，到调用厂家的解码器进行解码，再到显示，全部是在同一个Thread里进行的，在这样的做法下，假如中间有任何一层稍微有点问题的话，就容易导致整个VideoThread 挂起；并且加上UniArgus在处理海康的视频流格式相对特殊（其视频流并未以单帧的方式进行回传，而是以一个VideoGroup，一个VideoGroup的方式在回传，而每个VideoGroup除audio和I frame外，都会有B、B、P三帧），更要命的是，目前的VideoPlayer.ocx在处理帧间停顿的时做法实在***(Sleep())，，结果导致其在流畅度和CPU利用率上远远低于其它厂家（单帧回传，单帧解码、单帧显示）的做法。

改善措施：

Decode 与Display改为分成两个来处理，从Callback收到视频流之后，直接扔到decoder去做decode，decode完毕之后放入Queue；在放入第一帧decode好的frame时，启动一个多媒体定时器（相对于SetTimer or Sleep更为精确的计时器），并以N ms（如40ms）的interval从Queue里取出来进行播放。

改用此方法之后，解决了流畅度问题，并且CPU利用率也得到的一些的提升，在我的Notebook上同时解码并播放4路BitRate 512K, FrameRate fps 25的CIF，CPU占用率为20左右。暂未在原同等配置的客户端做详尽的数据测试。