2019-04-18 13:53:28 -0600 | edited question | capture->set(CAP_PROP_POS_FRAMES,f) is very slow in mjpg AVI files using VideoCapture capture->set(CAP_PROP_POS_FRAMES,f) is very slow in mjpg AVI files using VideoCapture Hi everyone, I'm using VideoCa |
2019-04-18 13:49:38 -0600 | asked a question | capture->set(CAP_PROP_POS_FRAMES,f) is very slow in mjpg AVI files using VideoCapture capture->set(CAP_PROP_POS_FRAMES,f) is very slow in mjpg AVI files using VideoCapture Hi everyone, I'm using VideoCa |
2016-09-30 05:23:37 -0600 | answered a question | VideoCapture unable to read large AVI files (wrong frame count) After further testing, the issue with length appears only with MJPEG encoded AVI files and seems to be related to this bug with the internal mjpeg decoder. If we change container to mp4 (via Would be great if if some opencv code fairy finds time to work on that I guess... |
2016-09-21 23:35:02 -0600 | commented question | VideoCapture unable to read large AVI files (wrong frame count) There seem to have been someone with a similar problem 4 years ago with a previous version of opencv, which had at the time been resolved: http://answers.opencv.org/question/14... Unfortunately I doubt that "switching compiler" works here since I'm having the exact same problem on multiple machines and both OSX and linux... |
2016-08-17 06:16:44 -0600 | received badge | ● Nice Answer (source) |
2016-08-16 15:25:05 -0600 | received badge | ● Teacher (source) |
2016-08-16 04:03:39 -0600 | commented question | SVM Predict Slow Dumb question, but if you're using SVM as a linear predictor, can't you just get mean and bias off of it and do your own calculation from it? Would be much faster than having to go through all your support vectors and computing a dot product off of them for each of your 500 samples. |
2016-08-16 03:55:59 -0600 | received badge | ● Supporter (source) |
2016-08-16 03:55:44 -0600 | answered a question | In the Shi-Tomasi method, is it possible to get the area where the frequency of detected corners is high? Depending on what you want to do, you can estimate the density of your corners as follows:
You can then use that image to find regions of high density. The only parameter you have to play with is the size of your Estimator image (larger circle == smoother output). Incidentally, this is exactly what a RBF kernel does. However if you only want to know the "center of mass" of your corners (i.e. you only want ONE answer, and not a density) you can do it much more easily, and FooBar's solution is also perfect for that (and much faster). |
2016-08-16 03:35:53 -0600 | answered a question | SVM returning a single value during prediction It may be a problem with the training (and parameters) rather than with the code itself: if the SVM model is simply a horizontal line (e.g. if the epsilon is too large for your data) then it will always output the same value (the bias). I dont remember off the bat but depending on the default parameters for SVM training, the model nay expect to have data that jumps around in the range of 0-1 instead of hundreds. Try rescaling your input to a 0-1 range, or try to play around with your training parameters (mostly the epsilon if you're doing epsilon SVM). Good luck! Basilio |
2016-07-13 14:03:39 -0600 | commented question | Video saved by opencv is zero bytes Also, be advised that some codecs will simply not write anything to file (for instance, most codecs on OSX will result in empty files). It wont throw an error, just not write anything to file. |
2016-07-13 12:59:00 -0600 | answered a question | What exactly does code in Canny do? Not an expert but from the look of it it seems like a nice trick for high computational efficiency:
it seems to be deciding which type of comparison it needs to do with the if (dyVal < tg22x) lines and then goes and check the next pixels in the derivatives images (dx and dy). Bottom line, that's where you need to set your flags. For clarification, you wont be able to tell the "direction" in the sense of right to left vs left to right, just vertical, horizontal and two diagonal directions. Hope this helps! |
2016-07-13 12:35:35 -0600 | received badge | ● Editor (source) |
2016-07-13 11:20:26 -0600 | asked a question | VideoCapture unable to read large AVI files (wrong frame count) Hey there! CONTEXT In our projects we work with very large video files (5-6h of recordings at a time). We usually encode in MJPEG to make moving through the videos more reasonable (using ffmpeg), which gives us files of 30Gb or thereabouts each time. PROBLEM When using VideoCapture to read the avi files, using the following code : We get the wrong amount of frames (~14'300 frames instead of the correct ~400'000-500'000). VideoCapture is then able to read through the file but only up to frame #14'300 or thereabouts. The problem happens on both linux and osx. WHAT WE TRIED The (now deprecated) CvCapture reads the file size properly and allows to read through the entire videos with no issues. Our only problem is that it's much slower to read the files compared to VideoCapture (same files, same machines). (It is our current fallback solution.) The "trick" from the examples code (reading the file size "manually" off the avi RIFF header) returns the same wrong frame count as getting CV_CAP_PROP_FRAME_COUNT off VideoCapture. This comes, I guess, from the 2gb limit that AVI files had in the old days, but as CvCapture (in both opencv2 and opencv3) is able to read the files properly, I guess that the 2gb limit is not (or should not be) a deal breaker. THE QUESTION Any ideas on how to get VideoConverter to work properly? If that is not possible then how to know the proper file size from an over-sized avi file? And barring that any idea on an alternative way of reading through videos in a quicker way than CvCapture? Any help would be greatly appreciated! Best, Basilio |