Provide wheel without FFmpeg (non-LGPL wheel)

[johnthagen]

Currently, if a user would like to use opencv-python in an application that they distribute with PyInstaller, LGPL licenses produce difficulty due to the requirement to be able to swap in different versions of the LGPL'd library. (This is summarized in this PyOxidizer issue).

opencv-python-headless is very close to being compatible because it excludes Qt (also LGPL) but still includes FFmpeg (#349). FFmpeg brings with it a pretty extensive list of requirements on the developer: https://www.ffmpeg.org/legal.html

For developers who want to use all of the other great features of OpenCV without FFmpeg, do you think there could be a solution for hosting a wheel in this way? Or perhaps the -headless wheels could be updated to not include FFmpeg?

Relevant OpenCV ffmpeg README about build options: https://github.com/opencv/opencv/tree/master/3rdparty/ffmpeg

---

• On Linux and other Unix flavors OpenCV uses default or user-built ffmpeg/libav libraries.
  If user builds ffmpeg/libav from source and wants OpenCV to stay BSD library, not GPL/LGPL,
  he/she should use --enabled-shared configure flag and make sure that no GPL components are
  enabled (some notable examples are x264 (H264 encoder) and libac3 (Dolby AC3 audio codec)).
  See https://www.ffmpeg.org/legal.html for details.

  If you want to play very safe and do not want to use FFMPEG at all, regardless of whether it's installed on
  your system or not, configure and build OpenCV using CMake with WITH_FFMPEG=OFF flag. OpenCV will then use
  AVFoundation (OSX), GStreamer (Linux) or other available backends supported by opencv_videoio module.

  There is also our self-contained motion jpeg codec, which you can use without any worries.
  It handles CV_FOURCC('M', 'J', 'P', 'G') streams within an AVI container (".avi").

• On Windows OpenCV uses pre-built ffmpeg binaries, built with proper flags (without GPL components) and
  wrapped with simple, stable OpenCV-compatible API.
  The binaries are opencv_videoio_ffmpeg.dll (version for 32-bit Windows) and
  opencv_videoio_ffmpeg_64.dll (version for 64-bit Windows).

  The pre-built opencv_videoio_ffmpeg*.dll is:

  • LGPL library, not BSD libraries.
  • Loaded at runtime by opencv_videoio module.
    If it succeeds, ffmpeg can be used to decode/encode videos;
    otherwise, other API is used.

  FFMPEG build includes support for H264 encoder based on the OpenH264 library.
  OpenH264 Video Codec provided by Cisco Systems, Inc.
  See https://github.com/cisco/openh264/releases for details and OpenH264 license.
  OpenH264 library should be installed separatelly. Downloaded binary file can be placed into global system path
  (System32 or SysWOW64) or near application binaries (check documentation of "LoadLibrary" Win32 function from MSDN).
  Or you can specify location of binary file via OPENH264_LIBRARY environment variable.

  If LGPL/GPL software can not be supplied with your OpenCV-based product, simply exclude
  opencv_videoio_ffmpeg*.dll from your distribution; OpenCV will stay fully functional except for the ability to
  decode/encode videos using FFMPEG (though, it may still be able to do that using other API,
  such as Video for Windows, Windows Media Foundation or our self-contained motion jpeg codec).

  See license.txt for the FFMPEG copyright notice and the licensing terms.

[skvark]

It doesn't make sense to remove FFmpeg from the headless packages. Headless means that there are no dependencies to any GUI libraries and removing FFmpeg would break all software which is depending on FFmpeg features in the headless packages.

The FFmpeg libs are dynamically linked to the OpenCV binary and be at least in theory can be replaced by some modified version of FFmpeg. For example when I used PyInstaller some years ago for some software all the shared libraries were available next to the executable created by PyInstaller.

I'm aware of the OpenCV guidance on FFmpeg. Windows wheels use the pre-built binaries provided by OpenCV.

I could maybe create a third distribution which is completely stripped down version of OpenCV without any external dependencies. However, my recommendation is to use the toolchain in this repository to build a custom version of this wheel and embed that to the PyOxidizer / PyInstaller bundle. That should be very straightforward to implement with any CI system out there. If I start providing all kinds of combinations of OpenCV builds I have soon a line of people waiting for me to do their work for them.

[johnthagen]

If I start providing all kinds of combinations of OpenCV builds I have soon a line of people waiting for me to do their work for them.

Understood, this was a large concern of mine as well.

I could maybe create a third distribution which is completely stripped down version of OpenCV without any external dependencies.

This would be appreciated, but it's understood that this is a lot of work.

However, my recommendation is to use the toolchain in this repository to build a custom version of this wheel

Looks like perhaps only WITH_FFMPEG=OFF would be needed, so maybe this wouldn't be super difficult. Thank you for the suggestions.

[skvark]

I'll think about the new packages. Currently the priority is to get new releases out.

Local build / custom CI build should be very easy to do as well as hosting a local PyPI index. I have done that for multiple internal commercial Python packages (not for opencv-python) in the past (like ~5 years ago) and it worked fine. In case someone is wondering how to do that:

1. Clone this repository in CI system job (CI system being for example Travis, Appveyor, Jenkins, Bitbucket CI, Gitlab CI etc.)
2. export CMAKE_FLAGS="-DWITH_FFMPEG=OFF -DSOME_OTHER_FLAG=ON" and add any others flag you need (for example CUDA, which is also a bit complicated dependency to redistribute)
3. Run python setup.py bdist_wheel
   • Optionally use the manylinux images as a build hosts if maximum portability is needed (and run auditwheel for the wheel after build)
4. You'll have the wheel file in the dist folder and you can do with that whatever you wish (upload to local PyPI index, use as dependency in a CI job which runs the PyInstaller / PyOxidizer bundler for your app etc.)

[johnthagen]

Possible name for the wheel could be:

• opencv-python-permissive-licensed

[johnthagen]

For anyone interested, bundled FFmpeg library files are separate in the wheel file (as @skvark mentioned):

opencv_python_headless-4.3.0.36-cp38-cp38-manylinux2014_x86_64.whl

• opencv_python_headless.libs
  • libavcodec-681a2255.so.58.93.100
  • libavformat-fed7ce93.so.58.47.100
  • libavutil-bedca4f8.so.56.55.100
  • libswresample-e69eb03e.so.3.8.100
  • libswscale-59c13675.so.5.8.100

opencv_python_headless-4.3.0.36-cp38-cp38-win_amd64.whl

• cv2
  • opencv_videoio_ffmpeg430_64.dll

[johnthagen]

@asmorkalov @sergregory Now that OpenCV is officially supporting this project, I was curious about your thoughts on this.

I believe having a fully permissively-licensed wheel for users who would like to embed OpenCV into Python applications and distribute those (e.g. PyInstaller, PyOxidizer, etc) would be very useful.

[asmorkalov]

@johnthagen The option is under discussion for OpenCV 5.0. There are other OpenCV dependencies that should be handled and we are looking for general solution.

[stefan6419846]

Has there been any progress on this in the last two years? As far as I can see, OpenCV 5.0 is not yet available, so this will most likely experience further delays and probably require building custom packages which omit FFmpeg?

[ioctl-user]

A suggestion on this topic: it would be nice to have build option like -DPERMISSIVE_CODE_ONLY, that could build opencv with only MIT, BSD, Apache, PD-licensed code. This option is to be used to build OpenCV for commercial products.