2019-10-24 09:22:43 -0600 | received badge | ● Popular Question (source) |
2015-07-13 09:57:01 -0600 | asked a question | VideoCapture.read() count doesn't match CAP_PROP_FRAME_COUNT or output by FFMPEG When I check my video frame count using CAP_PROP_FRAME_COUNT, it says there are 300 frames. Similarly, when I use FFMPEG to output the frames of the video, I also get 300 frames. However, when I use a regular VideoCapture read loop similar to the code below, I always get 296 frames. I'm guessing this has something to do with the video format being H264 and the way the data is compressed in such a video. But some of the data I'm using is given with the 300 frame count and my code relies on the OpenCV output which is giving me 296 frames. This discrepancy makes matching the two sets of data a headache. Can anyone explain why there is the difference in frame count/output and how to properly get the two sets of data to match up? In particular, is there just some specific setting I need to look into to get the read() loop to hand back the same 300 frames that FFMPEG would output? Thanks. Code: |
2015-07-06 10:09:01 -0600 | commented question | opencv_traincascade stuck on precalculation when running LBP mode @StevenPuttemans: Sorry for the delay since the last update. See the latest update above for relevant information. |
2015-07-02 10:28:30 -0600 | commented question | opencv_traincascade stuck on precalculation when running LBP mode @StevenPuttemans: Tried it, but with no luck. The Haar training runs fine, so I doubt it's a path issue, though I could be wrong. |
2015-07-01 21:03:59 -0600 | received badge | ● Editor (source) |
2015-07-01 21:00:16 -0600 | commented question | opencv_traincascade stuck on precalculation when running LBP mode @StevenPuttemans: Thanks, but unfortunately, bumping it up to 3GB on each of the buffers doesn't help. |
2015-07-01 10:31:30 -0600 | asked a question | opencv_traincascade stuck on precalculation when running LBP mode My cascade training works when using Haar but not LBP. The problem seems to occur during the precalcuation phase. For example, when running: The output I receive is: And it stalls at this point without moving forward (even when waiting for 30+ minutes). If I run this same command using HAAR instead of LBP, the recalculation finishes within 10 seconds or so. I've tried fiddling with the UPDATE I've found that the program is definitely trying in some way, as it shows up in my Activity Monitor as consuming a huge amount of CPU. Another user seems to have had this problem a year ago on StackOverflow and tried many things, but they seem to have had no success. Their plight can be found here. It may be worth noting that we are both on OS X. UPDATE 2 Trying the exact same dataset and command on an Ubuntu machine has the script run correctly. So it seems to be related to the OS X installation of OpenCV in some way. |
2015-06-29 15:34:01 -0600 | commented question | OpenCV 3 - Python's detectMultiScale3 fails in clipObjects @berak: That fixes the problem for me! Thanks for the help! I'll look into logging an issue some time in the near future. |
2015-06-29 10:43:26 -0600 | received badge | ● Student (source) |
2015-06-29 10:37:35 -0600 | asked a question | OpenCV 3 - Python's detectMultiScale3 fails in clipObjects Using OpenCV 3.0.0 and Python 3.4.3, I'm getting an error running Which appears to simply be an assertion check in the C++ source for detectMultiScale3 Documentation Code: |