Let's see how we can somehow fix the problem by introducing another optimized architecture:

First, we will divide the execution into two independent parts. The main thread, or the video thread, which simply continues to read the frames, puts it on a stack and then shows those frames into the screen together if the bounding boxes exist. Then we have another thread, the YOLO thread, which is independent from the main thread; it reads those frames from the stack, and it produces bounding-box predictions. Since the YOLO thread, which is the slowest one, isn't mixing with the main thread, it isn't slowing down the thread that's showing the video. The flow of the frames will go normally, and in the screen, we'll see a high-quality video. Most of the time, this architecture will work just fine.

However, this isn't perfect. Let's see one example (please refer the optimized YOLO architecture image): suppose the sixth frame comes in and then the main thread will be put on the stack; this will show us the frame on the screen. It will first check for the bounding boxes.

Since the YOLO thread may take some time to produce the new bounding boxes for the sixth frame, it may be that the main thread will take all bounding boxes from the fifth frame, mix them together, draw the rectangles, and show those boxes on the screen, which will be the sixth frame with the fifth frame bounding boxes.

This works well if the video doesn't move or change frames too fast. If we have a fast-moving car, or maybe people running, it will show us outdated bounding boxes. The speed of the movement depends on the mode we choose, a function available in some graphical user interfaces. We could choose high resolution, which means that the YOLO thread will be slowed down, or we may choose a lower resolution and grid size, and that means that we will see almost a real-time into the screen.