Multiprocessing in darknet_video.py (NOT final!)

[CristiFati]

Disclaimer

• I'm not aiming to merge this PR anywhere (that's the reason why I left there debug and other stuff), it's just a point that I've reached (and got stuck at). If anyone is interested, they can use this

• This is on top of #8562. It contains it (otherwise the PR wouldn't make sense), ONLY LAST COMMIT IS RELEVANT

As I explained in the prerequisite PR, on my laptop (pretty old), I get ~3 FPS:

• NVidia Quadro M100M - GPU

• Win 10 pc064

• Python 3.9

In theory, switching to multi process could increase speed by a factor of up to 3 (as they are 3 threads), but a more realistic estimation would be ~1.5 - 2 (I thought that with a reasonable amount of work, I'd get some good results). However they are very disappointing, as it performs even worse (~2 FPS). On one hand, it makes sense as it needs to pickle / unpickle lots of stuff for each frame.

There are other drawbacks as well:

• I know the synchronization mechanism (if it can be called that) is rudimentary, but it crashes at the end (didn't do a deep debug session to find out why), and it requires Ctrl+ Break

• Besides that, the model is loaded twice, (one just to get some data out of it - as it can't be pickled)

• While we are on pickleing subject, one thing that I don't understand is why only the IMAGE class needed adjustments, as other structures (DETECTION) are being shared between processes as well (via Queues)

• The 3 function signatures became horribly long

Some (visual) details: [SO]: Changing YoloV4 darknet_video.py into multiprocessing instead of multi_threading (@CristiFati's answer).

I think with a lot of refactoring, things could be improved (maybe even change the number of threads (ExecUnits)), but I didn't do any profiling to see where it "sits" most.

[CristiFati]

Also, the test env is quite poor. Many tests fail because of setup issues totally unrelated to the changes.

[cenit]

if you rebase on top of master, errors should go away. Sorry for the noise I opened a PR on your fork to ease the process, if you want to accept it

[CristiFati]

Thank you @cenit, that was it!! Unfortunately I didn't see your PR in my repo (to be honest I didn't expect anyone to commit there), so I rebased myself. But as specified in the comments, this is just for others to see, it's not mergeable into master. #8562 and #8555 are to be merged from my side.