Multi encoder an parallelism

[dgalland]

From the source code:

""This is a base class for a multi-threaded software encoder."""

"Derive your encoder from this class and add an encode_func method. For an example, see JpegEncoder (jpeg_encoder.py).
The parallelism is likely to help when the encoder in question releases the GIL, for example before diving into a large C/C++ library."

I don't completely understand the comment, under what condition is there really parallelism without the GIL.
Is it really the case when the derived encoder for example JpegEncoder calls simplejpeg.encode_jpeg (It seems that the simplejpeg package calls libturbojpeg)

[davidplowman]

Hi, thanks for the question. I'll assume that anyone reading this knows about the GIL and why it means that multithreading gives you no benefits when you're running "vanilla Python code".

However, multithreading does help when you have threads that are waiting for something, typically for events or for I/O to finish. Before the thread sleeps, it releases the GIL, so other Python threads can now run.

When you call into a large C/C++ library it appears to have the same effect. In this case, while all the JPEG encode is happening in libjpegturbo, the GIL is released and another thread can now run Python code (and it too, may release the GIL when it dives into the JPEG encoder...).

You can experiment by watching htop in a terminal window while running examples/capture_mjpeg.py. In the standard configuration I see all 4 cores running at 60-70% utilisation. If you hack the code (set num_threads to 1) so that there's only a single thread, I see one core at about 100% and the other 3 are basically idle. Does that make sense?

[dgalland]

Thanks David for your answer, I learned something.
I knew that Python multithreading was interesting for IO-Bound task but I didn't know that GIL was released when calling a C/C++ library. Do you think this is also true for OpenCV?

[davidplowman]

Indeed, now that's a good question. Truth is, I don't really know, and I believe it's up to whoever implemented the Python bindings. However, I think that both OpenCV and numpy implement this behaviour, but one would have to try it to be sure...

[dgalland]

So I look at the MultiEncoder code that uses ThreadPoolExecutor.
Are we sure that the jpeg encoded frames are obtained in the order of their submission?

[dgalland]

After careful review, the answer is yes because even if the tasks are executed concurrently, the results are retrieved in order through a sequential Queue.

[davidplowman]

Glad you've figured it out. Sorry not to have replied more quickly!