Ask Your Question

Eric HUBERT's profile - activity

2013-09-27 02:45:31 -0600 commented answer SEGFAULT in libnative_camera

Yep. It worked for me. I did not, however, made an exhaustive bach of tests. However, the license of the GNU STL is to restrictive, so now I am using STL PORT shared for everything.

2013-09-26 02:57:09 -0600 commented answer SEGFAULT in libnative_camera

Hello, Actually I did the test myself. recompiled native_camera, opencv and all my libs with gnustl_shared and all my issues disappeared. I also tried with everything using stlport_shared, and also stlport_static. no issues neither.

My original issue was that native_camera was using stlport and I was using gnustl for every others libs. Using 2 different kinds of STL was bad. (I do recompile opencv)

I guess it is mandatory to use stlport when recompiling opencv. My bad if I missed any warning/default config or anything else.

Anyway, thanks a lot for your help!

2013-09-24 04:39:30 -0600 received badge  Supporter (source)
2013-09-24 04:38:39 -0600 commented answer SEGFAULT in libnative_camera

Thank you for your precious help. I see in the build instructions the flag "-DANDROID_USE_STLPORT=ON" . and I'm guessing maybe this can be a good hint. Since my app uses multiple shared libraries (including OpenCV ones) and since It is advised to use a single SHARED version of the STL then...

(see CPLUSPLUS-SUPPORT.html from the NDK.)

I will try to build libnative_camera with the I'm using for everything else and see if it fixes my issue.

Will keep you informed. (since it might be a good idea in opencv build scripts to use the same shared STL)

2013-09-23 05:16:41 -0600 asked a question SEGFAULT in libnative_camera

Hello everyone,

I'm having hard times finding the root cause of an issue in my native android app using OpenCV video camera feature. And since the libnative_camera source code is not public (unless I'm making a mistake) It's difficult to understand it.

    signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
    #00  pc 0000effc  /system/lib/
    #01  pc 00011da3  /system/lib/ (dlfree+1458)
    #02  pc 0000cf13  /system/lib/ (free+10)
    #03  pc 0000b28f  /data/app-lib/ (std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()+4)
    #04  pc 00040c90  /data/app-lib/ (-----)

The weird part is that there absolutely no link in my source code between stack #04 and #03.

Is there any way to get a debug version of the libnative_camera ? about its source code? Does it run some static initialization code? Did someone encounter a similar issue?


2013-08-14 17:07:41 -0600 received badge  Nice Answer (source)
2013-08-14 05:14:23 -0600 received badge  Teacher (source)
2013-08-14 04:53:35 -0600 received badge  Self-Learner (source)
2013-08-14 04:40:14 -0600 answered a question CvCaptureCAM_DShow::open with an out of bound index

My defect and proposed fix has been accepted and merged into the 2.4.7 branch

2013-08-07 03:12:16 -0600 received badge  Editor (source)
2013-08-07 03:06:16 -0600 commented question CvCaptureCAM_DShow::open with an out of bound index

Thank you for the idea, but it won't help me. the "try_index" used within the DShow wrapper makes that even if I start with index 99, it will use the "last" camera from its own list.

2013-08-06 19:17:09 -0600 received badge  Student (source)
2013-08-06 10:04:03 -0600 asked a question CvCaptureCAM_DShow::open with an out of bound index


In my program (MultiPlatform C++ using OpenCV 2.4.6) , I am trying to determine how many video inputs are available. There is no straightforward API for that, so I'm doing a small workaround:

I try and init a new VideoCapture with an increasing index until it fails. (isOpened() returns false)

    test = new cv::VideoCapture(i++);
    bOk = test->isOpened();

While it's working on linux (with V4L2) it fails on Windows (with DirectShow) since the OpenCV Dshow wrapper, when requested to open a camera index out of bound, decides to use the last available one. (so I'm getting 99 working inputs)

cf cap_dshow.cpp l.3172

try_index = try_index < 0 ? 0 : (try_index > devices-1 ? devices-1 : try_index);

Is there any particular reason for this behaviour? (I did not find an obvious one on the source history) maybe is this a workaround for a dshow issue?

Thank you

Edit : The "fall back" behavior should be, in my opinion, a decision from the caller, and not the lib itself. I did a fix yesterday, it seems to be working perfectly. So I assume there is no issue from dshow. I added an issue in the tracker and made a pull request for the fix. I hope it will make it into the 2.4.7 :