How to read VideoCapture as parts in multiple threads

edit

and you want to keep 90k frames in memory ? it would only require 185GB for HD frames ;)

I already load 90k in VideoCapture variable and I loop through it, I'm using a frame of 480x320 in size. for illustration, we can use less than 90k frames

Are you familiar with the std C++ thread and mutex?

I'm quite enough familiar with c++ thread, however for mutex I've never worked with before.

the problem here with the thread is concurrency and multiple access to the same resource VideoCapture variable? how to deal with it ?

Yeah, you pass in a mutex instantiation into the thread function. You must pass the mutex by reference.

Whenever you want to be thread-safe, you call the mutex's lock() function before you use the non-atomic data/functions. Once you're done using the non-atomic data/functions you call the mutex's unlock() function.

It's that simple: Since you're passing by reference, all threads use the same mutex. The mutex blocks on lock(), waiting for the other thread to call unlock().

On the other hand, you might be able to avoid using a mutex. Just pass the data subset directly into each thread function. That way your main function can immediately call join() after all of the thread() calls.

assume, that a VideoCapture is NOT THREADSAFE AT ALL. (it's a matter of internal state, not locks)

@azdoud.y you'd have to use 1 seperate capture per thread

Sorry, I was assuming that these video clips were already stored to disk as images.

@azdoud.y again, please explain the need for multiple threads. which problem are you trying to solve here ?

okey, @berak I will explain

did you profile your code ? where is the bottleneck ?

if it turns out to be the psnr/ssim part,maybe a single producer with several consumers would be a better design ?

if it was too slow in a single thread before, tripling the work load and expect to make it faster, seems absurd.

Noting is absurd if we want to learn something new.

yes, when I profile my code it slows down at psnr/ssim functions

@berak Can you give us some documentation about single producer with several consumers would be a better design, please

maybe:

• have a single VideoCapture
• read your image
• push_back() it into a std::deque (with locks around that code)
• either start a new thread, or have a threadpool, and take the next free one
• pop_front() an image from the deque (again with locks)
• process your image

@berak, you said that I'd have to use 1 separate capture per thread, how can I separate the main capture into sub-capture parts?

start a new VideoCapture object in each of your 3 threads. seek to a certain frameno, and start reading/processing (and please don't put any gui code, like imshow() into any of those threads.)

Why don't you split your video into multiple files in a preprocessing function, and then create an array of VideoCapture objects equivalent to the number of different video files and make them work in parallel?