Repository navigation
Provide wheel without FFmpeg (non-LGPL wheel) #353
Description
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.
Activity
skvark commentedon Jun 26, 2020
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 commentedon Jun 26, 2020
Understood, this was a large concern of mine as well.
This would be appreciated, but it's understood that this is a lot of work.
Looks like perhaps only
WITH_FFMPEG=OFFwould be needed, so maybe this wouldn't be super difficult. Thank you for the suggestions.skvark commentedon Jun 26, 2020
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: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)python setup.py bdist_wheelmanylinuximages as a build hosts if maximum portability is needed (and runauditwheelfor the wheel after build)distfolder 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 commentedon Jul 9, 2020
Possible name for the wheel could be:
opencv-python-permissive-licensedjohnthagen commentedon Jul 17, 2020
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-4.3.0.36-cp38-cp38-win_amd64.whl
johnthagen commentedon May 20, 2021
@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 commentedon May 21, 2021
@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 commentedon Jun 13, 2023
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 commentedon Dec 26, 2023
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.
HJJ256 commentedon Jul 6, 2026
Hi @skvark
OpenCV 5 is also released now. Is there any update on this issue?