B4silio's profile - activity

capture->set(CAP_PROP_POS_FRAMES,f) is very slow in mjpg AVI files using VideoCapture Hi everyone, I'm using VideoCa

capture->set(CAP_PROP_POS_FRAMES,f) is very slow in mjpg AVI files using VideoCapture Hi everyone, I'm using VideoCa

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 ffmpeg -i input.avi -vcodec copy output.mp4) the ffmpeg mjpeg decoder kicks in instead and there are no problems with frame count anymore. However the scrubbing speed (reading video randomly jumping around) is about 60% slower...

Would be great if if some opencv code fairy finds time to work on that I guess...

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...

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.

Depending on what you want to do, you can estimate the density of your corners as follows:

1. Make a Density Estimator image

   1. Make a 64x64 black image
   2. Draw a 16x16 radius white circle at its center
   3. Gaussian Blur it with a filter size of ~15
   4. You now have a 2D "gaussian" pattern you can use as a density estimator

2. Create a black image of the same size as your input (say 640x480)

3. For each of your detected corners
   1. Add the Density Estimator image to the black image with a small weight (you'll be adding a lot of them)
4. You now have an image that has blobs that become very white if there are a lot of edges in that region, and remains black where you dont have them

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).

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

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.

Not an expert but from the look of it it seems like a nice trick for high computational efficiency:

• Precompute a costly operation tan(pi/8)
• Use some bit shifting ( << operation) to do comparisons using int insteand of floats

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).

 if (dyVal < tg22x) // this is for horizontal edges
    {
        if (m > tex2D(tex_mag, x - 1, y) && m >= tex2D(tex_mag, x + 1, y)) {
            edge_type = 1 + (int)(m > high_thresh);
            // flag = 1;
        }
    }
    else if(dyVal > tg67x) // this for vertical ones
    {
        if (m > tex2D(tex_mag, x, y - 1) && m >= tex2D(tex_mag, x, y + 1)) {
            edge_type = 1 + (int)(m > high_thresh);
            // flag = 2;
        }
    }
    else // diagonals (uses s to switch direction of the diagonal)
    {
        if (m > tex2D(tex_mag, x - s, y - 1) && m >= tex2D(tex_mag, x + s, y + 1)) {
            edge_type = 1 + (int)(m > high_thresh);
            // flag = s > 0 ? 3 : 4;
        }
    }
    // mask(x,y) = flag;

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!

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 :

VideoCapture input = VideoCapture(pathString);
if (!input.isOpened()) return;
int frameCount = input.get(CV_CAP_PROP_FRAME_COUNT);

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