cmake -D build options?

[wb666greene]

This is really just a question.

Intel's OpenVINO installed a customized OpenCV 4.1.0 that supports their MYRIAD tensor co-processors. But it seems they have introduced a issue where rtsp stream decoding can only achieve about half the frame rate as your Pypi 4.1.0 builds. OpenVINO has recently been open sourced so its possible to recompile it.

My question is, do you publish the cmake -D options you use to build? I'd like to try to rebuild OpenVINO and make its options match yours in hopes of getting the good rtsp decode performance of your builds.

[skvark]

The build options are scattered around setup.py: https://github.com/skvark/opencv-python/blob/master/setup.py

However, I think that OpenCV doesn't handle decoding. It's handled by FFmpeg. FFmpeg requires some assembler libraries (nasm and yasm) to work efficiently. I have used this guide to build FFmpeg: https://trac.ffmpeg.org/wiki/CompilationGuide/Centos

See the Dockerfiles for more info: https://github.com/skvark/opencv-python/blob/master/docker/Dockerfile_x86_64

[wb666greene]

Thanks, so if I understand correctly you are shipping a statically linked ffmpeg, same as with QT?

That should explain it.

[skvark]

FFmpeg libraries which are shipped with opencv-python are shared libraries (the only way to ship them to comply with LGPL) and they have been dynamically linked with the OpenCV binary. Same with Qt.

[wb666greene]

I guess I mis-read something in the faq about QT. Back to square one if the same ffmpeg libraries are being used -- I only have one version of ffmpeg installed as far as I can tell.

I've both contrib-opencv-python and the Intel OpenVINO openCV installed on the same system. Default is opencv-python, but OpenVINO sets a PYTHONPATH to make its version be found first.

I'm seeing this decrement on both ARM and Intel cpus, although rtsp stream decoding is poor on ARM, its still showing about the same percentage performance decrements with Intel's built for ARM vs. the pyWheels openCV version.

The Intel NCS v1 SDK appears to install the pypi verison of OpenCV and didn't have this issue, I've discovered it moving my code to OpenVINO to allow using the faster NCS2.

[skvark]

These packages do not use system FFmpeg so it does not matter which FFmpeg you have installed.

auditwheel (https://github.com/pypa/auditwheel) fixes the wheel archives during build so that they become self-contained which means that they include all dependencies (except some system libraries such as glibc). Quoting the auditwheel README:

auditwheel repair: copies these external shared libraries into the wheel itself, and automatically modifies the appropriate RPATH entries such that these libraries will be picked up at runtime. This accomplishes a similar result as if the libraries had been statically linked without requiring changes to the build system. Packagers are advised that bundling, like static linking, may implicate copyright concerns.

OpenCV binary itself is a very big static library (cv2.cpython-36m-x86_64-linux-gnu.so below) which contains many dependencies such as libjpeg etc.. Additionally, the OpenCV binary is linked with some external dependencies which must be redistributed as shared libraries due to LGPL license.

If you have a look at the installation folder you should see something like this inside the .libs folder under cv2:

~/.local/lib/python3.6/site-packages/cv2:

drwxrwxr-x 5 skvark skvark     4096 Jun 17 19:32 .
drwx------ 7 skvark skvark     4096 Jul  4 09:50 ..
-rwxrwxr-x 1 skvark skvark 28481592 Jul  4 09:49 cv2.cpython-36m-x86_64-linux-gnu.so
drwxrwxr-x 3 skvark skvark     4096 Jun 17 19:32 data
-rw-rw-r-- 1 skvark skvark      233 Jul  4 09:49 __init__.py
drwxrwxr-x 2 skvark skvark     4096 Jul  4 09:50 .libs
-rw-rw-r-- 1 skvark skvark    30910 Jul  4 09:49 LICENSE-3RD-PARTY.txt
-rw-rw-r-- 1 skvark skvark     1097 Jul  4 09:49 LICENSE.txt
drwxrwxr-x 2 skvark skvark     4096 Jun 17 19:32 __pycache__

~/.local/lib/python3.6/site-packages/cv2/.libs:

libavcodec-874f3d51.so.58.47.106   libQtCore-3dbacd8a.so.4.8.7  libswresample-a49c020a.so.3.4.100  libz-a147dcb0.so.1.2.3
libavformat-fb41c63f.so.58.26.101  libQtGui-6d0f14dd.so.4.8.7   libswscale-4e6f4703.so.5.4.100
libavutil-473e9eb1.so.56.26.100    libQtTest-1183da5d.so.4.8.7  libvpx-8459aeef.so.6.0.0

In short: OpenCV wheels installed from PyPI use always a custom FFmpeg version which is built specifically on the Cent OS 5 Docker container to achieve maximum portability across different distros. I don't know how the other OpenCV versions you have installed are packaged, but most likely they use the system FFmpeg unlike opencv-python wheels.

EDIT: You can check the dependencies of the other packages with ldd cv2.so.

[wb666greene]

Thanks for this clarification, I was stumbling around and just noticed the .libs directory and saw the various shared libraries that were being used with opencv-python. I often forget about looking for "hidden" files and directories :(

Achieves the same net effect as my incorrect assumption about static linking, albeit with a lot more complexity to keep everybody happy.

Thanks for the ldd tip. I'll poke around some more and see if I can figure something out. I have found a work-around. I can run my rtsp decode code as a separate Python3 program using the opencv-python version to get the good decode performance. and run my AI code in a different Python3 process using the OpenVINO PYTHONPATH for its openCV and the NCS "myriad" support. This is actually more inline with my ultimate plans were the rtsp decoding is done on one machine and the AI runs on another.

Trying to run the OpenVINO code without the "myriad" functions is giving me errors like this:
`QObject::moveToThread: Current thread (0x1883c70) is not the object's thread (0x19a3f00).
Cannot move to target thread (0x1883c70)

Segmentation fault
`
Presumably because my python path is not finding consistent sets of libraries. I believe virtual environments are my only solution here. I'm not too familiar with them but I have used them.

Thanks for your help.

Edit.
A good while back I compiled OpenCV 3.3.0 on this desktop development system in question for my first foray into AI, using the system ffmpeg and I get almost the same rtsp stream decoding performance as does the opencv-pything i.e ~70 fps with system ffmpeg and ~73 fps withi contrib-python. My 15 rtsp streams being decoded have and aggregate framerate of 75 fps so I suspect these difference is insignificant as my timing code starts when the threads are launched and it takes about 90 seconds before the final thread has opened the stream and started decoding it. Its pretty consistent that this security DVR takes 6 seconds to open an rtsp connection and the opening doesn't seem to be parallelized. So I wouldn't bet the farm on it being ffmpeg version issue at this point.

I'm poking around the OpenVINO github and I'm beginning to think they didn't use the best threading model in their build, choosing best compatability. I still need to learn more.