Currently I'm writting a small prove-of-concept-program, which reads avi-files using the cv::VideoCapture class of openCV and displays the frames using openGL.
After I got this working, I changed the texture transfer to the use of pixel buffer objects.
Had I read the documentation carefully, I wouldn't had done one stupid mistake.
When you map your videomemory to your system's memory using glMapBuffer, you have to unbind it before you can use it, otherwise you get an "Invalid Operation"-error.
First attempt then was to copy the image data using memcpy, which worked just fine but required an additional copy.
Well, you can create a cv::Mat object with an already-allocated region of memory. So I used the mapped bufferpointer as the datapointer for the object.
But nothing happend and the image stayed black.
So what is going on here?
After finding out, that the memory location of the frame changed, after I read one frame with the cv::VideoCapture object, I thought that somehow the buffer memory does not match the requirements of the frame, e.g. size. But that was not the case.
Then I dug into the openCV sourcecode (second time this weekend) and found the the reason.
Inside the cv::VideoCapture class uses the old cvCapture functions, which allocate memory themself. So when you grab an image, your provided image gets this new memory and the provided memory is deallocated.
Even though this memory is only allocated at the beginning, there is no way that you can provide own memory, which should be used by the cv::VideoCapture module.
Bad news.
Funny thing is that the cvCapture code is class based and even uses cv::Mat inside.
Maybe someday the developers will rewrite the code and enable transparent memory usage.
