Silent failure when multiprocessing and OpenCL used on MacOS

asked 2018-01-12 07:08:05 -0600

I have been running a long OpenCV pipeline and, in attempt to reduce dropped frames, I decided to implement it with multiprocessing. The reason I chose multiprocessing over Python threads is because with long pipelines the Global Interpreter Lock (GIL) still tends to get in the way.

The following code was mostly stolen from the following StackOverflow thread, and it seems to work fine when OpenCL is not used. However, I have always had the statement cv2.ocl.setUseOpenCL(cv2.ocl.haveOpenCL()) at the top of my code in the blind belief that it would lead to some acceleration.

It seems that when it is used in conjunction with multiprocessing, the whole OpenCL support breaks and the pipeline is stuck at [ INFO:0] Initialize OpenCL runtime....

Is this known behaviour of OpenCV on MacOS?

I am running MacOS 10.12 with manually compiled OpenCV for Gstreamer and other support, Python 3.5.2.

import multiprocessing
import cv2
import time

print("OpenCL is available: {}".format(cv2.ocl.haveOpenCL()))
cv2.ocl.setUseOpenCL(cv2.ocl.haveOpenCL()) # Change to False to test without OpenCL
queue_from_cam = multiprocessing.Queue(maxsize=2048)

def cam_loop(queue_from_cam):
    cap = cv2.VideoCapture(0,
    while True:
        hello, img =
        if hello:

cam_process = multiprocessing.Process(target=cam_loop, args=(queue_from_cam,))

while True:
    if not queue_from_cam.empty():
        from_queue = queue_from_cam.get()
        cv2.imshow('camera', from_queue)
        if cv2.waitKey(1) & 0xFF == ord('q'):
edit retag flag offensive close merge delete


It seems reasonable that going for OpenCL and multithreading might generate issues, since internally OpenCL is basically generating for certain functions a massive parallelization using the GPU. I would think you either go for paralllelization and deactivate OpenCL or vice-versa.

StevenPuttemans gravatar imageStevenPuttemans ( 2018-01-12 08:10:05 -0600 )edit

While I do agree that bugs like this one are bound to occur in a multiprocessing application, I feel that this must be a fairly common use case in OpenCV in Python - freeing up time on the GIL from math manipulation by delegating simple functionality to a secondary thread is a pretty standard scenario. I just hope that it doesn't behave the same way when using CUDA acceleration!

BTW, I have recently tested the same code on Ubuntu 16.04.3 and it behaves exactly the same way.

KaloyanP gravatar imageKaloyanP ( 2018-01-18 14:48:45 -0600 )edit