平台是：WINCE6.0 + DM3730(1GHZ)
APP：DirectShow
分辨率：720*576 （15帧）
问题：
打开camera应用，只是preview，CPU的占用率都高达%40---%50。要是把录像功能打开的话，CPU的占用率高达%80.还没算上加录音。这里我的录像是采用了DSP的。所以编码部分不用担心CPU的负载。
1. 手头没有一个参考，不知道在WINCE下，预览15帧，720*576的这种CPU的占用率一般是多少，我的属于正常还是不正常，到是有个mobile的参考，320*240（15帧）的CPU占用率是%15，我测试过数据量小，CPU的占用率会降低，自己测试过640*480的，占用率在%30多
2. 查过整个预览的流程，我做过测试，当camera中断来后，只是一个普通的拷贝，不将数据传递给APP,也就是不要fillbuffer，CPU的占用率还是很低的，只有%5,这点说明camera驱动对于读取数据对CPU的损耗一点都不大，可是我只要去fillbuffer，这个占用率就飙升了%40。
3. fillbuffer只是做了一次拷贝，给APP传递了一个消息，然后APP去enquebuffer,然后继续等中断，fillbuffer,连续下去，这就是驱动做的事情，这个过程会引起CPU的负载高吗？
4. 如果camera驱动没有引起CPU的占用率高，难道是显示驱动引起的吗？我如何才能排查显示驱动在camera应用对CPU的影响。
5. camera的应用是dshow，我就是用那种非常简单的智能连接，都是renderstream那种，微软标准的框架，难道是他自己本身就这么高？
求讨论
------解决方案--------------------
dshow不是很熟悉，从你的描述来分析：
1、“当camera中断来后，只是一个普通的拷贝”：这个有数据拷贝，数量量越大则占用CPU时间越长
2、“fillbuffer只是做了一次拷贝”：不出意外这个地方是同步保护加数据拷贝，数量量越大则占用CPU时间越长
3、“APP去enquebuffer”：不出意外这个地方是同步保护加数据拷贝，数量量越大则占用CPU时间越长
4、应用如果显示拿到的数据，因为对dshow不是很熟悉，不出意外应该也是有数据搬移的(除非是使用DMA方式直接拿去显示)。
基于以上几点，建议找一个进程管理器工具看每个应用CPU占用率，驱动一般对应的是NK.exe，应用你自然清楚是哪一个。或者可以将几个操作统计一下tick，看耗时多的在哪一步
------解决方案--------------------
只将数据拿到，不做显示进行一下测试，看看 CPU 的使用率如何？
720*576 的分辨率，应该比你的 LCD 分辨率在高度上高，显示需要做处理的。
------解决方案--------------------
一般来说主要是DSHOW占用高，你的解码应该是没有硬件去加速的。
其它地方你程序做个比较长的循环然后关掉其它环境都是可以测试到CPU的占用率的，比如你说的拷贝这些，你不停的拷贝不去显示，就很容易知道结果了。
TI的不像telechip会把CAMERA这部分软件全部调好，硬件加速弄好的。
------解决方案--------------------
这几个建议不错。
这个camera 在wince 下有一个很大的毛病，占用内存很大，找了好久找不出原因，如果是128M的物理内存拍照300W的相片，变的很难。楼主的内存占用多少？
------解决方案--------------------
应该是在转换为RGB这个地方占用了过多的CPU
楼上说的不错，估计你这个没有开硬件加速。512内存使用这么低分辨率不应该出现这样的情况的
最好的办法还是要添加代码检测一下哪个位置耗时最多，这样才好定位解决
------解决方案--------------------
如果
1、csc转换
2、scaler缩放
3、frame预览
4、录像时间水印(opt)
这四个关键操作不能用硬件来实现，那CPU占用率想降到理想状态是不太可能的