gtx860M,cuda9路1080p多高斯运动检测测试

多高斯背景差分,非常吃cpu,特别是多路视屏,所以想用gpu做检测 后面的跟踪一系列的规则判断用cpu

opencv+cuda+stl做了个测试

代码:

// MTTestCudaMog.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include "opencv.hpp"
#include <thread>
#include <iostream>
#include <mutex>
#include "cudacodec.hpp"
#include "cudabgsegm.hpp"
#include "cudaobjdetect.hpp"
#include "Timer.h"

using namespace std;
std::mutex m;
void f1()
{
cv::VideoCapture cap("D:\\testvideo\\22.mp4");
cv::Mat mat;
cv::Ptr<cv::cuda::BackgroundSubtractorMOG2> mog = cv::cuda::createBackgroundSubtractorMOG2(0.0002, 16,false);
cv::cuda::GpuMat gpuMat;
cv::cuda::GpuMat gpuMsk;
cv::Mat matMsk;
CTimer timeTester;
double t = 0.0;

while (true)
{
m.lock();
cap>>mat;
timeTester.Start();
gpuMat.upload(mat);
mog->apply( gpuMat, gpuMsk );
gpuMat.download( matMsk );
t = timeTester.End();
cout << "Intial ThreadID : " << std::this_thread::get_id() << ":" << t<< endl;
m.unlock();
}
};

int _tmain(int argc, _TCHAR* argv[])
{
int ichannel = 9;
vector<thread> vThread;
vThread.resize(ichannel);
for( int i=0; i<ichannel; i++ )
{
vThread[i] = std::thread(f1);
}
for( int i=0; i<ichannel; i++ )
{
vThread[i].join();
}
cout<<"Main Thread"<<endl;
return 0;
}

gpu负载率在36%左右  cpu使用25%左右包括读入视屏的占用

下面这幅图是每一帧gpu的多高斯检测时间包括数据上载gpu和下载到内存的时间

时间: 2024-10-30 06:07:37

gtx860M,cuda9路1080p多高斯运动检测测试的相关文章

软件测试之路再谈(三年测试风雨)

碧水涟涟,夏至未至,秋风依依,梅花落时,已是一生 一初衷: 为什么写这篇博客? 个人性别偏于低调,最近换了新工作,坐标成都,就任于一家T系公司. 1.公司是以项目为单位,有测试团队但没有测试部这个概念,测试团队人数大概60人左右,但都基本跟你没任何关系,只有项目上的其他两个成员跟你有交集,缺少后方养分,差异性,一时间不太适应, 2.业务划分很精细,能接触到的东西十分有限,还有各模块之间弱化了连接测试,担忧.已经发现过问题,而且也和组员讨论过他们也赞同这种方式容易出现质量弱化 基于以上有些迷茫吧.

白盒测试的学习之路----(四)搭建测试框架TestNG测试

TestNG是一个开源自动化测试框架; TestNG是类似于JUnit,但它不是一个JUnit扩展.它的灵感来源于JUnit.它的目的是优于JUnit的,尤其是当测试集成的类. TestNG消除了大部分的旧框架的限制,使开发人员能够编写更加灵活和强大的测试. 因为它在很大程度上借鉴了Java注解(JDK5.0引入的)来定义的测试,它也可以告诉你如何使用这个新功能在真实的Java语言生产环境中.一般开发使用的是JUnit做单元测试,而测试一般都是勇士TestNG. 首先,就是下载相关jar包(te

架构之路(四):测试驱动

上一章我们提到,单元测试只是测试驱动的一个子集:换言之,测试驱动有着更宽广的概念,他要求以“测试”为驱动力,来推动整个开发活动.这个观点似乎非常具有争议性,相当多的人认为其根本不具有可执行性.但很奇怪的是,当我第一眼接触这个观点,我就觉得,它像一道闪电划破长空,它光华璀璨,价值无以伦比! 需求文档可测试化 我第一点想到的,就是需求文档应该可测试化.我不太明白,这样简单有效的一个工作,为什么几乎没有人去做?因为发包方的原因? 大家接触到的需求文档是什么样子的?我从来没有看到过一份我满意的需求文档.

arduino+16路舵机驱动板连接测试

用Arduino类库驱动舵机并不是一件难事,如果需要驱动很多电机,就需要要占用更多的引脚,也会影响到Arduino的处理能力.专门的舵机驱动板很好的解决了这个问题. 此舵机驱动板使用PCA9685芯片,是16通道12bit PWM舵机驱动,用2个引脚通过I2C就可以驱动16个舵机.不仅如此,你还可以通过级联的方式最多级联62个驱动板,总共可以驱动992个舵机! 大多数的舵机设计电压都是在5~6V,尤其在多个舵机同时运行时,跟需要有大功率的电源供电.如果直接使用Arduino 5V引脚直接为舵机供

探索式测试实践之路

背景: 第一阶段:问题暴露... 4 第二阶段:各种方案探索... 6 第三阶段:思考...... 8 第四阶段:推广... 11 第五阶段:变化着推广... 14 总结... 16 背景: 记的看过一篇文章,<在效率这件事上,保守者谈"变革",而激进者说"革命">,当时,文章中提的很明确,之所以要"革",是因为目前的方式,无法满足要求了.如果什么都不变,必死:如果变的方向不对,或过大,也必死: 所以,文中建议,对于保守和激进两种方式

live555客户端连多路1080P视频流花屏问题

硬件和软件环境是这样的: DM8168 + linux, 解码器是DM8168自带的 视频来源: ipc通过live555做的的rtsp sever发送过来的 其他测试: 通过VLC在pc连4路1080P没有问题,都挺流畅的: 用之前一个项目中自己实现的RTSP client连同样的1080p 4路到6路都没有问题(只是那个占用内存太多了,才打算用live555重写) live555 rtsp client 客户端大概如下: 修改openRTSP, 使支持多个实例支持多个RTSPClient,其

exynos4412 HDMI测试

平台: IBOX 4412 Linux:Linux-3.8.13(from NanoPC from Odroid) Driver:drivers/media/platform/s5p-tv 编译器:arm-linux-gnueabihf-gcc 4.7.3 一.代码移植(参考板都已经做完) smdk4x12_devices[]加入 smdk4x12_machine_init中加入 二.Menuconfig 配置 Device Drivers -->Multimedia support --->

测试工具

Web Performance & Load 测试工具multi-mechanize 对Web服务做Performance & Load测试,最常见的工具有Apache Benchmark俗称ab和商用工具LoadRunner.ab简单直接,功能也相对较弱,但我们经常看到的对一些Web server或者Framework的性能测试用的ab做的, 而LoadRunner功能也确实很强大,各种大型软件公司.软件外包企业几乎是必备了,用起来很High,当然其价格也确实很High 这里要介绍的mu

【转】测试,人人都是产品经理之测试产品的选择和创造

  序言:明天新的一年的的工作开始了,在晚上写这篇文章,也算是对自己一年工作的一个简单的总结以及对今年所想做的事情作为一个开端吧.这次回家,疯狂了一把,不管测试.不管自动化.也不管技术,只知道与朋友们欢畅,踏上回来的途中,却反射性的重新拿起了书.每个人也许想知道自己的价值在哪,无论在哪,我觉得每个人都是自己的产品经理,而定位自己的需求,寻找产品的价值都是一件很难的事情,首先知道自己要什么,再知道自己可以设计出来?最后还要经过反复的实践和测试,才能诞生出一个让自己感到稍微满意的产品,因为这些文章,