Description
I've seen the Windows build flaking at a ~2% rate, and think it's started with OpenCV 5.0. I don't see any source changes that might explain this, however the issue seems to be in the prebuilt FFmpeg binary that is included in the package. Example: https://github.com/Breakthrough/PySceneDetect/actions/runs/35548340704/job/106178294407
D:\a\_temp\02bf8af7-1216-404a-bfb2-8f1ba7760c24.sh: line 2: 660 Segmentation fault python -X dev -m pytest -vv
pytest exit code: 139
We should file an upstream bug for this in the actual OpenCV repo once we can get a more reliable reproduction.
Reproduction
On release mode it happens less frequently, but more often when running the process with a debugger attached. In production, the crash rate seems to depend on the prior state of the world (specifically, which video was decoded first). The crash also seems to only occur when OPENCV_LOG_LEVEL is set to ERROR.
Workarounds
- set
OPENCV_LOG_LEVEL=FATAL
- Set the capture backend explicitly, and use
cv2.CAP_IMAGES for PNGs. By default, it uses cv2.CAP_ANY which tries ffmpeg first, loading it into the process.
Tasks
Description
I've seen the Windows build flaking at a ~2% rate, and think it's started with OpenCV 5.0. I don't see any source changes that might explain this, however the issue seems to be in the prebuilt FFmpeg binary that is included in the package. Example: https://github.com/Breakthrough/PySceneDetect/actions/runs/35548340704/job/106178294407
We should file an upstream bug for this in the actual OpenCV repo once we can get a more reliable reproduction.
Reproduction
On release mode it happens less frequently, but more often when running the process with a debugger attached. In production, the crash rate seems to depend on the prior state of the world (specifically, which video was decoded first). The crash also seems to only occur when
OPENCV_LOG_LEVELis set to ERROR.Workarounds
OPENCV_LOG_LEVEL=FATALcv2.CAP_IMAGESfor PNGs. By default, it usescv2.CAP_ANYwhich tries ffmpeg first, loading it into the process.Tasks
cv2.CAP_ANY. (Alternatively: should we allow **kwargs instead?)