Multi-worker video processing

Face detection, overlays and mask rendering are heavy, and each frame has about 16 ms. If this work runs on the main thread, the interface suffers. Clicking a dropdown or changing the theme would take a long time to respond while the video is running.

The heavy steps run in separate workers, in parallel, so the main thread stays free for the interface. The video pipeline never locks the UI, so a click on a dropdown or a theme change responds at once even while video is running. The other threads are also used for the other work that happens while the video runs, so the machine's processing is put to use. The stages pass frames through a shared latest-frame buffer: the consumer always takes the newest frame and never blocks the producer.

Keeping the work on the main thread. It is simpler, but the interface becomes slow whenever the video pipeline is busy.

Designed and implemented a multi-worker architecture to move computationally intensive video-processing operations away from the primary application execution path.

Offloaded operations such as face detection, overlays, and mask rendering to background workers to support real-time processing while targeting a 16ms frame budget.

• When a stage is slow, the pipeline drops a frame and moves on to the next one instead of waiting. I chose that over freezing the picture.
• Workers that coordinate are harder to build and debug.

The interface stays smooth while the video runs, and the pipeline stays within its frame budget.