Ask Your Question

mojoritty's profile - activity

2014-06-27 08:58:22 -0500 received badge  Teacher (source)
2014-06-27 07:27:49 -0500 received badge  Self-Learner (source)
2014-06-27 07:16:24 -0500 answered a question VideoCapture::set() memory leak

I seem to have found a solution to this issue and reported it as a bug in the bugtracker. It turns out the memory leak originates in videoInput::setVideoSettingCamera(), where an IBaseFilter object is created in a call to getDevice() but never released. I presented a solution in the bugreport.

This solves the memory leak for the largest part. However, it seems there is still a very small leak, several bytes per call probably, that originates from the call to getDevice(). Unfortunately, I have not been able to trace this bug to its origin, and was not able to solve it. Maybe someone else is able to locate it, I suspect the calls to CoCreateInstance and CreateClassEnumerator cause the leak, since memory usage seems to increase after these calls.

2014-06-25 21:12:04 -0500 received badge  Student (source)
2014-06-25 04:19:57 -0500 commented answer VideoCapture::set() memory leak

The documentation is pretty much incomplete to that respect. The properties are defined in highgui_c.h, and there are many more than the ones listed in the documentation. Easiest way is to look in the VS Intellisense auto-complete list, that's how I found them.

2014-06-25 02:40:42 -0500 commented answer VideoCapture::set() memory leak

I was considering this kind of workaround. However, this would not fix the leak, only make it less of an issue since it does not leak every loop iteration. When the user makes many adjustments, significant amounts of memory will still be leaked. I still think this is an issue that should better be fixed. Unless this is intended behavior, in which case it would be good to document this (and explain why this is the case).

2014-06-24 13:38:22 -0500 received badge  Critic (source)
2014-06-24 13:38:09 -0500 commented answer VideoCapture::set() memory leak

As I tried to explain in my post, I want to use some controls to adjust the camera settings during recording. In that case, the value passed to VideoCapture::set() would be a variable (i.e. video_cap.set(CV_CAP_PROP_FOCUS, new_focus);), and the variable might be adjusted during program execution, for example using an OpenCV TrackBar (e.g. cv::createTrackBar("bar","window",new_focus,30);). When the camera setting is only applied once, no runtime changes are possible. In any case, moving the line out of the loop is only a work-around. In my view, the command should not leak memory in any case.

2014-06-24 10:55:56 -0500 asked a question VideoCapture::set() memory leak

I am trying to capture video with a Microsoft LiveCam Studio webcam using OpenCV 2.4.9 (which will use DShow to connect to the camera). Since I want to be able to change camera settings on the fly, I inserted a call to VideoCapture::set() inside the capture loop. This way, as soon as a setting is changed (for example using an OpenCV TrackBar), the camera will be adjusted accordingly.

The issue is that VideoCapture::set() seems to introduce a memory leak, which becomes apparent when put into a loop. When running the code below, memory usage increases significantly during program execution. When disabling the call to VideoCpture::set(), memory usage is constant during execution.

I tested this on OpenCV 2.4.4 and 2.4.9 and both show the same issue (compiled in 32 bit on a Windows 7 x64 machine using VS2010). Changing different camera settings seems to result in different sizes of leaks, but each call seems to produce a leak. e.g. CV_CAP_PROP_FOCUS seems to leak almost 2 MB/second while CV_CAP_PROP_CONTRAST only leaks about 15 KB/second. Unfortunately, VisualLeakDetector does not detect a leak when running this code, making debugging hard.

#include "opencv2/highgui/highgui.hpp"
int main(int argc, char ** argv)
    cv::Mat img;
    cv::VideoCapture video_cap(0);
    for(int i = 0; i < 1000; ++i)
        video_cap.set(CV_CAP_PROP_FOCUS, 14);
        video_cap >> img;
    return 0;