camera CPU占用率高问题

unsway123 2013-12-19 09:37:04

平台是：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那种，微软标准的框架，难道是他自己本身就这么高？

求讨论

...全文

1462 14 打赏收藏转发到动态举报

写回复

用AI写文章

14 条回复

切换为时间正序

请发表友善的回复…

发表回复

alien75 2013-12-23

打赏
举报

如果 1、csc转换 2、scaler缩放 3、frame预览 4、录像时间水印(opt) 这四个关键操作不能用硬件来实现，那CPU占用率想降到理想状态是不太可能的

一介布衣萧萧 2013-12-23

打赏
举报

应该是在转换为RGB这个地方占用了过多的CPU 楼上说的不错，估计你这个没有开硬件加速。512内存使用这么低分辨率不应该出现这样的情况的最好的办法还是要添加代码检测一下哪个位置耗时最多，这样才好定位解决

unsway123 2013-12-23

打赏
举报

暂时把帧率定位15帧了，这样cpu的占用率在预览的时候%40多，录像的时候占用率在%70多，基本丢帧率在%1或者更低。基本可以OK了。

unsway123 2013-12-21

打赏
举报

引用 10 楼 gooogleman 的回复:

[quote=引用 2 楼 alien75 的回复:] dshow不是很熟悉，从你的描述来分析： 1、“当camera中断来后，只是一个普通的拷贝”：这个有数据拷贝，数量量越大则占用CPU时间越长 2、“fillbuffer只是做了一次拷贝”：不出意外这个地方是同步保护加数据拷贝，数量量越大则占用CPU时间越长 3、“APP去enquebuffer”：不出意外这个地方是同步保护加数据拷贝，数量量越大则占用CPU时间越长 4、应用如果显示拿到的数据，因为对dshow不是很熟悉，不出意外应该也是有数据搬移的(除非是使用DMA方式直接拿去显示)。基于以上几点，建议找一个进程管理器工具看每个应用CPU占用率，驱动一般对应的是NK.exe，应用你自然清楚是哪一个。或者可以将几个操作统计一下tick，看耗时多的在哪一步

这几个建议不错。这个camera 在wince 下有一个很大的毛病，占用内存很大，找了好久找不出原因，如果是128M的物理内存拍照300W的相片，变的很难。楼主的内存占用多少？[/quote] 可用内存大概在280M吧，我们贴的是512M的

gooogleman 2013-12-20

打赏
举报

引用 2 楼 alien75 的回复:

dshow不是很熟悉，从你的描述来分析： 1、“当camera中断来后，只是一个普通的拷贝”：这个有数据拷贝，数量量越大则占用CPU时间越长 2、“fillbuffer只是做了一次拷贝”：不出意外这个地方是同步保护加数据拷贝，数量量越大则占用CPU时间越长 3、“APP去enquebuffer”：不出意外这个地方是同步保护加数据拷贝，数量量越大则占用CPU时间越长 4、应用如果显示拿到的数据，因为对dshow不是很熟悉，不出意外应该也是有数据搬移的(除非是使用DMA方式直接拿去显示)。基于以上几点，建议找一个进程管理器工具看每个应用CPU占用率，驱动一般对应的是NK.exe，应用你自然清楚是哪一个。或者可以将几个操作统计一下tick，看耗时多的在哪一步

这几个建议不错。这个camera 在wince 下有一个很大的毛病，占用内存很大，找了好久找不出原因，如果是128M的物理内存拍照300W的相片，变的很难。楼主的内存占用多少？

unsway123 2013-12-20

打赏
举报

引用 8 楼 unsway123 的回复:

[quote=引用 7 楼 hudaweikevin 的回复:] 一般来说主要是DSHOW占用高，你的解码应该是没有硬件去加速的。其它地方你程序做个比较长的循环然后关掉其它环境都是可以测试到CPU的占用率的，比如你说的拷贝这些，你不停的拷贝不去显示，就很容易知道结果了。 TI的不像telechip会把CAMERA这部分软件全部调好，硬件加速弄好的。

我做过试验的，中断来了，只做拷贝，不传递到dshow里面去，cpu占用率是很低的。[/quote] 看过你的帖子，你是在OVERLAY上做刷图吧，颜色深度不一样，刷图就会慢是吧，现在是这样的，dshow其实在收到我copy上去的数据后，不也是在进行刷图嘛，其实就跟你那个状态差不多了，dshow最后的刷图，实际上是把我的yuv的数据直接刷到RGB的一个surface上的，这中间应该是会有转换的吧，兄台，当时你有研究过3730上OVERLAY的处理吗

unsway123 2013-12-20

打赏
举报

引用 7 楼 hudaweikevin 的回复:

一般来说主要是DSHOW占用高，你的解码应该是没有硬件去加速的。其它地方你程序做个比较长的循环然后关掉其它环境都是可以测试到CPU的占用率的，比如你说的拷贝这些，你不停的拷贝不去显示，就很容易知道结果了。 TI的不像telechip会把CAMERA这部分软件全部调好，硬件加速弄好的。

我做过试验的，中断来了，只做拷贝，不传递到dshow里面去，cpu占用率是很低的。

David_Hu 2013-12-20

打赏
举报

一般来说主要是DSHOW占用高，你的解码应该是没有硬件去加速的。其它地方你程序做个比较长的循环然后关掉其它环境都是可以测试到CPU的占用率的，比如你说的拷贝这些，你不停的拷贝不去显示，就很容易知道结果了。 TI的不像telechip会把CAMERA这部分软件全部调好，硬件加速弄好的。

unsway123 2013-12-19

打赏
举报

引用 2 楼 alien75 的回复:

dshow不是很熟悉，从你的描述来分析： 1、“当camera中断来后，只是一个普通的拷贝”：这个有数据拷贝，数量量越大则占用CPU时间越长 2、“fillbuffer只是做了一次拷贝”：不出意外这个地方是同步保护加数据拷贝，数量量越大则占用CPU时间越长 3、“APP去enquebuffer”：不出意外这个地方是同步保护加数据拷贝，数量量越大则占用CPU时间越长 4、应用如果显示拿到的数据，因为对dshow不是很熟悉，不出意外应该也是有数据搬移的(除非是使用DMA方式直接拿去显示)。基于以上几点，建议找一个进程管理器工具看每个应用CPU占用率，驱动一般对应的是NK.exe，应用你自然清楚是哪一个。或者可以将几个操作统计一下tick，看耗时多的在哪一步

但是我自己的理解是，我整个camera显示的流程是我只是做了一次拷贝，驱动中的拷贝，只是fillbuffer，这个fillbuffer所传递的地址是上层应用传递下来的，找道理说，上层应用只是做了一个指针的传递工作，我想做显示的时候，也只是一个指针的传递吧，我刚做了测试，在320*240的时候，CPU的占用率只有%9了，跟数据量的关系是有非常大的关系，但是cpu的占用率出在那个环节呢，在驱动中的那次拷贝才耗费了我4个ms，我一帧数据间隔也是60ms，是那个地方耗费了我大量的cpu呢

alien75 2013-12-19

打赏
举报

dshow不是很熟悉，从你的描述来分析： 1、“当camera中断来后，只是一个普通的拷贝”：这个有数据拷贝，数量量越大则占用CPU时间越长 2、“fillbuffer只是做了一次拷贝”：不出意外这个地方是同步保护加数据拷贝，数量量越大则占用CPU时间越长 3、“APP去enquebuffer”：不出意外这个地方是同步保护加数据拷贝，数量量越大则占用CPU时间越长 4、应用如果显示拿到的数据，因为对dshow不是很熟悉，不出意外应该也是有数据搬移的(除非是使用DMA方式直接拿去显示)。基于以上几点，建议找一个进程管理器工具看每个应用CPU占用率，驱动一般对应的是NK.exe，应用你自然清楚是哪一个。或者可以将几个操作统计一下tick，看耗时多的在哪一步

unsway123 2013-12-19