JasonInVegas's profile - activity

Nikkadim,

I have the same problem....and it occurred with both dynamic (dll) and static (lib) libraries regardless of what I tried so far.

I believe there's a common practice of recycling the GPU algorithm input memory objects and filling them with output results so you don't have to allocate double memory....this won't work if the GPU is performing the video frame decode ... naturally...because it needs the memory for the next frame.

Last item: I believe the Cuda perf tools include a call signature (even example code) to test for GPU compute level capabilities. So that code is out-of-the-box functionality on the CUDA side.

Whew...hope this helps (and doesn't confuse things more!)

Good luck!

P.S. please reply with the use-case you're constructing!

Now, about parameterizing the stream buffers based on video specs.

I'm not exactly confident which GPU memory structure(s) to use, but the GPU memory allocation is based on video frame Width x Height x Color_depth for each frame packed into an image struct like a pixel frame buffer object (FBO) in shaders....if you extract the frame(s) on CPU: you pack them, then pass them into the allocated GPU FBO memory object(s). So the frame extraction time(s) and GPU execution times ideally balance so the CPU doesn't bottleneck nor rest. The allocated amount of GPU memory must support input frames and output frame results.

My original comment was: "Why allocate 12 streams, if 6 frames 24-bit color uncompressed, HD video packed into FBOs on the GPU will consume the GPU memory?"

regarding item #2: my opinion is "yes" based on the comments in the referenced opencv forum post, it appears compute level 2.0 is required in order to achieve the stream-based parallelism.

So, which nVidia cards support compute level 2.0? (or restated: What is the least expensive Fermi architecture board?) Summary page: https://developer.nvidia.com/cuda-gpus

Everything on this page will support at least compute level 2.0 (most are 2.1 and above) http://www.nvidia.com/object/quadro-desktop-gpus-specs.html

These range from $150 USD to way too much...a Quadro k600 is a $175 USD board that supports compute level 3.0

Yes, it is possible...most likely you will want to parameterize the stream counts (rather than hard-coding '12') to make efficient use of block transfers based on GPU-specs including avail. memory, video format and frame specs, frame speed, and GPU algorithm-execution performance.

Here is nVidia's somewhat dated whitepaper link from their video decode/encode kit, which may outperform the VideoCapture/VideoWriter: http://www.nvidia.com/docs/IO/40049/TB-Quadro_VideoCaptureStreaming_v01.pdf

More importantly is their Codec SDK: https://developer.nvidia.com/nvidia-video-codec-sdk

My assumption is that CV/Cuda will be used within the frame-based algorithm, so I'll leave that to you....but the nVidia codec SDK will get you in and out again from the GPU without CPU-based video writes.

Also, here is a link to IntuVision's publication and commercial products that scale to make use of GPU resources for video analytics: www.intuvisiontech.com/tech/publications_13.php www.intuvisiontech.com/products/gpu.php

--Gotta give credit where credit is due, and IntuVision does it well!

Hope this helps, JasonInVegas

Yes, I too have the same problem installing after successfully downloading the x64bit version. I verified the MD5 checksum hash: bd46dd8b2ecf8a865efd57ef52d0e70c but the installer rapidly returns a fatal NSIS installer integrity check failure error message.