Hey, I’m using ofThread in an addon which will read frames from an IP camera’s mjpg stream. Because decompression is kinda slow (it’s not using MMX right now), I decided to make the task threaded.
Unfortunately, whenever I quit the application, it crashes. Presumably because it’s in the middle of reading and copying the pixels. What’s the best way to avoid this kinda problem?
I tried calling myThread.stopThread() in ~ofTestApp, but that didn’t work.
OSX 10.4.10, Xcode 2.5, of_preRelease_v0.05
Hi Mantissa, at one point I was having the same problem… but it magically disappeared after I rearranged all my locks() and unlocks(). Just a wild guess here, but maybe its because the app is exiting while there’s still a mutex lock on?
On a completely different note (without meaning to hijack the thread), how is it going with the IP Cameras? I was looking at using 4-8 IP cameras all being analyzed by one PC (or mac?) with each camera being analyzed in its own thread. A lot of people (mainly in the surveillance world) said IP cameras were a major pain… how are you finding it?
hey memo -
thanks, i’ll give it a shot. i had already tried calling stopThread() and unlock() in the destructor function with little success. perhaps I should just build some functionality that waits until the thread ends before it actually quits. the problem appears to be with ffmpeg’s functions that free the connection to the camera. it only happens intermittently.
i’ve had some success with the ip cameras. though i would definitel agree with those said that it was a major pain in the butt. as soon as i sort this out, i’ll release the code as an add-on (with compiled ffmpeg libraries for osx; linux shouldn’t need it). the frame rate is a little slower than anticipated (16 fps, not 30), though i understand that i can boost the decompression speed considerably by using mmx (still haven’t managed to compile the jpeg-mmx library though).