Is this a decent structure for a multithreaded vid

Hi I’m currently working on a project for a videocoacher program for recording and replaying video, as well as showing delayed real-time video, and tracking placement via color.

The software is running on linux , on a 4 core odroid, and initially I started to make it multi threaded with threads implemented as a part of each new class. Each of these threads taking care of their own gui elements.

I’ve later found out that I need to show all gui elements/video in the main/gui thread. Earlier I’ve used opencv and boost. But it seems like using the Qt might be a better idea since some of the code already depends on the QT library. I am currently a novice at programming, and not very familiar with either opencv, qt, or threading.

My question is: Is this relatively sound as a structure for the program, or is there something inherently wrong with how I am planning to do it now?

Main/GUI Thread

will show all visual & video content
will start a thread for ButtonControl object

ButtonControl

will handle all button input, controlling what happens in the program
depending on what buttons are pressed will start and end threads like:
StoreToFile object ( starts storing video to a file, while sending a video stream to GUI thread to show what it is storing in real-time)
ReadFromFile object ( reads the file currently stored and sends data to display it in GUI thread
DelayedVideoStream object (stores video to buffer, and shows a continuous delayed view of what happened 5seconds in the past)
ColorTracking object (tracks where a color placement is in the image )

Kind regards, and thank you for taking the time to look at my question.

TLDR - is a structure where threads are implemented as classes and the image data is sent back to the gui/main thread a decent way to do a multithreaded program ?

Performance-wise, the best approach is not to deal with threads directly at all, but use QtConcurrent::run. It is safe to paint QImages that are simply passed via signals to a GUI object to display. I wrote a complete example demonstrating that approach. It leads to some very concise and easy-to-understand code thanks to related code being adjacent.

If you do want to use explicit threads, it will be much easier not to derive from QThread, but to simply move various worker objects into their threads, and have them communicate via signals and slots. I have a complete example for that approach as well.