Videocapture *mov`s seems to time out in virtualbox
I get a strange behavior with Videocapture when I run code inside a Virtualbox client (Client: Ubuntu 15.10 x64) (confirmed with following host systems: Windows & Arch Linux). When the Videocapture object opens a video file everything is fine but when the system idles for too long (e.g. waiting for keyboard input) ~30 seconds the video capture returns an empty list and not the next frame of the video file (VideoCapture::grab returns false). This only seem to happen with *.mov files like the one attached (http://80.86.85.151:91/small.mov). Is this a problem in OpenCV or might something else be the cause?
#include <cv.h>
#include <highgui.h>
#include <opencv2/core/core.hpp>
#include <opencv2/videoio/videoio.hpp>
#include <opencv2/highgui/highgui.hpp>
#include <string>
#include <iostream>
using namespace cv;
using namespace std;
int main(){
const string ref = "/home/biotracker/Downloads/MVI_7555.MOV";
cv::VideoCapture capt(ref);
Mat im;
capt >> im;
for (int i = 0; i < 10; i++) {
cout << "im empty: " << im.empty() << endl;
imshow("qq", im);
char c = waitKey(60000);
cout << "time is over, nextframe" << endl;
capt >> im;
}
return 0;
}
Just mentioning that you have a very strange way of reading a video ... You are only reading a single frame? The
capt >> imcommand is only executed once ... so if you want to see several frames, this code is not going to do anything usefull.This is just sample code to reproduce the issue. The last line in the for-loop reads the next image and if keys are pressed a video sequence is played as expected but when the waitKey-timeout occurs the next image cannot be read anymore. To clarify: i get same behavior when i "split up" the >> function, as VideoCapture::grab already returns false when waiting for the timeout, otherwise it works fine.
remark: for now, I can only reproduce this issue inside a virtual machine (running Ubuntu 15.10, x64). When executed native or inside a docker image, everything works just fine!
Hmm then it might be something related to the piping of the waitKey stream, because it needs access to your keyboard signal ...
This seems unlikely as the issue also happens in our production code where we make no use of waitKey (but rather use locks). As it only happens with *.mov files (so far) and not with others (tested only with *avi) it seem to be an encoding problem..
Then how about switching to another encoding format?
Thats what we do as workaround :) . However, it would be interesting to know if this is an issue with OpenCV or not and thus: report of this strange error.
I guess you should open up an issues at the issue tracker on github and link this topic. Guess you will draw the developers there faster then here :)