Make cv::VideoCapture::get return cv::CAP_PROP_UNKNOWN (-1) for unsupported properties #21337
The return value indicating an unsupported property is not consistent across backends.
I stumbled on this issue because my code was determining if a property value is valid if it's non-zero (like the documentation says), which worked fine on macOS, but not on Android.
For example, auto-exposure is not supported on macOS, so get() returns 0. But it is supported on Android and 0 means auto-exposure is off.
I think -1 is the better return value to indicate unsupported properties.
I made changes to all the backends. I think I got every case. This breaks API compatibility for some backends, so I based this on branch 3.4.
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or other license that is incompatible with OpenCV
- [x] The PR is proposed to proper branch
- [ ] There is reference to original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
Python: add context manager compatibility for VideoCapture and VideoWriter #28967
### Description
This PR implements the context manager protocol (`with` statement support) for `cv2.VideoCapture` and `cv2.VideoWriter` objects in Python.
### Problem
Currently, these classes do not support the context manager protocol, leading to a `TypeError: ... object does not support the context manager protocol` when used with a `with` block. As reported in issue #28956, if an exception occurs before an explicit `.release()` call, the video resource or file remains locked in the system[cite: 298, 309].
### Identification & Motivation
By analyzing the issue and the Python binding structure of OpenCV, I identified that while the core logic resides in C++, the Pythonic behavior can be enhanced by injecting `__enter__` and `__exit__` methods during the module initialization. This ensures that resources are automatically and safely released even if the program execution is interrupted by an error[cite: 298, 325].
### Solution
I have modified `modules/python/package/cv2/__init__.py` to dynamically inject the necessary methods:
1. Defined `_video_enter` to return the object itself (standard context manager behavior).
2. Defined `_video_exit` to trigger the `.release()` method automatically.
3. Injected these methods into `VideoCapture` and `VideoWriter` classes immediately after the `bootstrap()` function to ensure the native C++ classes are correctly loaded into the global namespace.
Fixes#28956
In my configuration with bazel, when building the Java bindings,
it is not like building C++ and including videio/videoio.hpp
triggers:
error this is a compatibility header which should not be used inside the OpenCV library
Cover all seek directions in VideoCapture Java test #27421
### Pull Request Readiness Checklist
required for https://github.com/opencv/opencv/pull/27370
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
Java VideoCapture buffered stream constructor #27284
### Pull Request Readiness Checklist
resolves#26809
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
Open VideoCapture from data stream #25584
### Pull Request Readiness Checklist
Add VideoCapture option to read a raw binary video data from `std::streambuf`.
There are multiple motivations:
1. Avoid disk file creation in case of video already in memory (received by network or from database).
2. Streaming mode. Frames decoding starts during sequential file transfer by chunks.
Suppoted backends:
* FFmpeg
* MSMF (no streaming mode)
Supporter interfaces:
* C++ (std::streambuf)
* Python (io.BufferedIOBase)
resolves https://github.com/opencv/opencv/issues/24400
- [x] test h264
- [x] test IP camera like approach with no metadata but key frame only?
- [x] C API plugin
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
❗ Potential conflicts with #25958
C-API cleanup: highgui, videoio #26025❗ Merge with: opencv/opencv_contrib#3780
This PR removes usage of C-API from highgui and videoio modules. Only source code is affected, tests were not using obsolete API.
It should be possible to backport these changes to 4.x branch preserving removed public headers and source files (`*_c.h` and `*_c.cpp`).
#### Checklist
I tried to verify as many backends as possible, though these checks were not as thorough as I'd like them to be. Below is the checklist covering all modified backends with their statuses.
> 🔹 - small changes
> 🟢 - consider working
> ⚪ - considered untested
##### highgui
Pass | Backend | Local check | CI check
-----|---------|-------------|---------
🟢 | GTK2 | build + test, plugin build | build + test ❔🟢 | GTK3 | build + test, plugin build | build + test
🟢 | QT | build + test, plugin build |
⚪ | Wayland 🔹 | |
🟢 | WIN32 🔹 | | build + test
🟢 | Cocoa 🔹 | | build + test
⚪ | WinRT | |
##### videoio
Pass | Backend | Local check | CI check
-----|---------|-------------|---------
🟢 | Android Camera/MediaNDK 🔹 | | build
🟢 | Aravis | build |
🟢 | AVFoundation OSX | | build + test
⚪ | AVFoundation iOS | | build
🟢 | DC1394 | build |
🟢 | DShow 🔹 | | build
🟢 | FFMpeg | build, plugin build | build + test
🟢 | GPhoto 🔹 | build |
🟢 | GStreamer | build, plugin build | build + test
🟢 | Images | build | build + test
🟢 | MSMF 🔹 | | build + test
🟢 | OpenNI | build |
🟢 | PVAPI | build |
🟢 | V4L | build + test | build
🟢 | XIMEA | build |
🟢 | XINE 🔹 | build |
#### Notes
- local linux build checks performed using [this framework](https://github.com/mshabunin/opencv-videoio-build-check)
- minor extra changes made in both `cap_avfoundation*.mm` to make them slightly more synchronized - it would be better to combine them into a single one in the future
- configurations with plugins have been build but not tested
- **moved unrelated changes to separate PRs** ~two issues have been fixed in separate commits:~
- ~imgproc: missing `cv::hal::` color conversion functions has been used in MediaSDK backend~
- ~videoio/V4L: wrong color conversion mode caused bad colors for NV12 camera input format (RGB instead of BGR)~
It would be nice to check following functionality manually:
- [ ] OSX: camera input
- [ ] iOS: camera and file input
- [ ] WinRT: build, some testing
- [x] Linux/Wayland: build
Merge with https://github.com/opencv/opencv_contrib/pull/3446
Related issue: https://github.com/opencv/opencv/issues/11810
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
Add Python bindings for VideoCapture::waitAny #21826
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
Introduce libavdevice to make v4l2 available to the ffmpeg backend
* introduce libavdevice to make v4l2 available to the ffmpeg backend
* downgrade the min required libavdevice version to 53.2.0
* make libavdevice optional
* create OCV_OPTION OPENCV_FFMPEG_ENABLE_LIBAVDEVICE and add definition through ocv_add_external_target
* move OCV_OPTION 'OPENCV_FFMPEG_ENABLE_LIBAVDEVICE' to detect_ffmpeg.cmake
add video capture parameters
* add parameters
* videoio: revert unnecessary massive changes
* videoio: support capture parameters in backends API
- add tests
- FFmpeg backend sample code
- StaticBackend API is done
- support through PluginBackend API will be added later
Co-authored-by: Milashchenko <maksim.milashchenko@intel.com>
Co-authored-by: Alexander Alekhin <alexander.a.alekhin@gmail.com>
Objc binding
* Initial work on Objective-C wrapper
* Objective-C generator script; update manually generated wrappers
* Add Mat tests
* Core Tests
* Imgproc wrapper generation and tests
* Fixes for Imgcodecs wrapper
* Miscellaneous fixes. Swift build support
* Objective-C wrapper build/install
* Add Swift wrappers for videoio/objdetect/feature2d
* Framework build;iOS support
* Fix toArray functions;Use enum types whenever possible
* Use enum types where possible;prepare test build
* Update test
* Add test runner scripts for iOS and macOS
* Add test scripts and samples
* Build fixes
* Fix build (cmake 3.17.x compatibility)
* Fix warnings
* Fix enum name conflicting handling
* Add support for document generation with Jazzy
* Swift/Native fast accessor functions
* Add Objective-C wrapper for calib3d, dnn, ml, photo and video modules
* Remove IntOut/FloatOut/DoubleOut classes
* Fix iOS default test platform value
* Fix samples
* Revert default framework name to opencv2
* Add converter util functions
* Fix failing test
* Fix whitespace
* Add handling for deprecated methods;fix warnings;define __OPENCV_BUILD
* Suppress cmake warnings
* Reduce severity of "jazzy not found" log message
* Fix incorrect #include of compatibility header in ios.h
* Use explicit returns in subscript/get implementation
* Reduce minimum required cmake version to 3.15 for Objective-C/Swift binding