OpenCV：无法通过视频获得帧率

Question

I want to get framerate for video but I always get -nan on linux.

VideoCapture video(input);
if (!video.isOpened())  // zakoncz program w przypadku, problemu z otwarciem
{
    exit(0);
}

double fps = video.get(CV_CAP_PROP_FPS);

My openCv version is 2.4.7. The same code works fine on windows.

Answer 1

My guess is that it's camera dependent. Some (API) functions are sometimes not implemented in OpenCV and/or supported by your camera. Best would be if you check the code on github.

Concerning your problem: I am able to get the frame rates with a normal webcam and a XIMEA camera with your code.

Tested on:

• Ubuntu 15.04 64bit
• OpenCV 3.0.0 compiled with Qt and XIMEA camera support

You could measure your frame rate yourself:

double t1 = (double)cv::getTickCount();
// do something
t1 = ((double)cv::getTickCount() - t1)/cv::getTickFrequency();

Gives you the time that //do something spent.

Answer 2

It is from a file, you can try to estimate it yourself.

VideoCapture video("name_of_video.format");
int frameCount = (int)video.get(CV_CAP_PROP_FRAME_COUNT) ;
//some times frame count is wrong, so you can verify
video.set(CV_CAP_PROP_POS_FRAMES , frameCount-1);

//try to read the last frame, if not decrement frame count
    while(!(video.read(nextFrame))){

    frameCount--;

    video.set(CV_CAP_PROP_POS_FRAMES , frameCount-1);
}

//it is already set above, but just for clarity
      video.set(CV_CAP_PROP_POS_FRAMES , frameCount-1);
      double fps = (double)(1000*frameCount)/( video.get(CV_CAP_PROP_POS_MSEC));
      cout << "fps: " << fps << endl;

This is how I get framerate when using CV_CAP_PROP_FPS fails

Answer 3

The question doesn't clarify if this refers to video from a live source (webcam) or from a video file.

If the latter, the capabilities of OpenCV will depend on the format and codecs used in the file. For some file formats, expect to get a 0 or NaN.

If the former, the real fps of the source may not be returned, especially if the requested framerate is not supported by the hardware, and a different one is used instead. For this case I would suggest an approach similar to @holzkohlengrill's, but only do that calculation after an initial delay of say 300ms (YMMV), as grabbing of the first frames and some initialisations happening can mess with that calculation.