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
Fixed write return status in videoio module#29087
closes: https://github.com/opencv/opencv/issues/24287
### 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
videoio(mjpeg): fix heap-buffer-overflow in put_bits off-by-one resize guard #29113
### Summary
Fix a heap-buffer-overflow (WRITE of size 4) in the built-in MJPEG encoder detected by AddressSanitizer during fuzzing.
Fixes#29112
### Root Cause
`mjpeg_buffer::put_bits` in `modules/videoio/src/cap_mjpeg_encoder.cpp` guards buffer resize with:
```cpp
if ((m_pos == (data.size() - 1) && len > bits_free) || m_pos == data.size())
resize(int(2 * data.size()));
```
When `len == bits_free` the guard is **false** (strict `>`), so no resize happens. The subsequent code then:
1. Subtracts `len` from `bits_free`, making it exactly 0.
2. Enters the `bits_free <= 0` branch and executes `++m_pos`.
3. Writes `data[m_pos]` — now equal to `data[data.size()]` — **out of bounds**.
### Fix
Change `len > bits_free` to `len >= bits_free` so the buffer is grown whenever the current slot will be exactly or more than consumed.
```diff
-if ((m_pos == (data.size() - 1) && len > bits_free) || m_pos == data.size())
+if ((m_pos == (data.size() - 1) && len >= bits_free) || m_pos == data.size())
```
### Verification
Reproducer (1×1 grayscale frame, `CAP_OPENCV_MJPEG`):
```cpp
uint8_t pixel = 0xff;
cv::Mat frame(1, 1, CV_8UC1, &pixel);
int fourcc = cv::VideoWriter::fourcc('M', 'J', 'P', 'G');
cv::VideoWriter writer;
writer.open("/tmp/poc.avi", cv::CAP_OPENCV_MJPEG, fourcc, 25.0, cv::Size(1,1), false);
writer.write(frame);
```
Ran under `-fsanitize=address,undefined`; exits cleanly with no error after this fix.
### Regression Test
`TEST(Videoio_MJPEG, put_bits_no_heap_overflow)` added to `modules/videoio/test/test_video_io.cpp` — opens a `CAP_OPENCV_MJPEG` VideoWriter for a 1×1 grayscale file and writes one frame; asserts `EXPECT_NO_THROW`.
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
videoio(dshow): fix crash in videoInput::start() when pVih is NULL #28914
### Summary
This PR fixes a critical application crash in the DirectShow backend when encountering certain legacy or virtual cameras (e.g., Microsoft's DirectShow "Ball" Sample).
### The Problem
In `modules/videoio/src/cap_dshow.cpp`, the function `videoInput::start()` calls `pConfig->GetConnectedMediaType(&mt)`.
- In some edge cases, this call returns `S_OK`, indicating success.
- However, the associated format block `mt.pbFormat` (which `pVih` points to) can still be `NULL`.
- The current implementation uses `CV_Assert(pVih)`, which triggers a hard crash of the entire application when this occurs.
### The Fix
I have replaced the `CV_Assert(pVih)` with a null-pointer check. If `pVih` is `NULL`, the function now returns `false`. This allows the high-level `cv::VideoCapture` to handle the failure (e.g., by returning `false` from `.open()`) instead of crashing the process.
### Engineering Rationale
- Execution Path Consistency: For devices providing valid format headers, `pVih` remains non-NULL. In these cases, the conditional check is skipped, and the execution path is identical to the original implementation.
- Process Stability: Replacing `CV_Assert` prevents immediate process termination (SIGABRT) when a DirectShow filter provides an invalid or empty format block.
- Error Propagation: Returning `false` in `videoInput::start()` allows the initialization failure to propagate through the call stack. This ensures that `cv::VideoCapture::open()` returns `false`, enabling the caller to detect the issue via the standard API (e.g., `isOpened()`) instead of the process being terminated.
### Evidence
I have manually reproduced this crash using the Microsoft DirectShow Ball Sample filter on Windows. As shown in the attached debugger screenshot:
- `deviceID` is 2 (the virtual camera).
- `hr` is `S_OK`.
- `pVih` is `NULL`.
<img width="773" height="1413" alt="dshow_null_pvih_debug_evidence" src="https://github.com/user-attachments/assets/5bc454b4-4a0b-4703-825d-0d5fd23cba28" />
Fixes#28904
### 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
- [ ] 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
videoio: fix C4576 build error with older ffmpeg versions #28894Fixes#28875
### Description
This PR fixes a build failure (`error C4576`) that occurs when building the `videoio` module with older FFmpeg versions (e.g., 4.4.4) using MSVC under strict C++17 mode.
**Root Cause:**
In older FFmpeg headers, the `AV_TIME_BASE_Q` macro is defined using a C99 compound literal `(AVRational){1, AV_TIME_BASE}`. This syntax is non-standard in C++ and is strictly rejected by MSVC when `/std:c++17` is enabled.
**Solution:**
Replaced the `AV_TIME_BASE_Q` macro with FFmpeg's standard `av_make_q(1, AV_TIME_BASE)` function. This resolves the C4576 compiler error and ensures modern C++ compatibility.
*(Note: `av_make_q` is already smoothly polyfilled in `cap_ffmpeg_impl.hpp` for extremely old FFmpeg versions, making this a highly safe, consistent, and zero-overhead replacement.)*
### 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
- [ ] 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
Add CAP_PROP_IMAGE_SEQ_START #28844
Resolves https://github.com/opencv/opencv/issues/28843
New CAP_PROP_IMAGE_SEQ_START as an open only property for setting the first frame index when a VideoCap is opening with pattern, squashes test_images TODO.
`CAP_FFMPEG`: forwarded to the image2 demuxers "start_number" option.
`CAP_IMAGES`: Now a WithParams variant so the value reaches open() before probe runs, replaces 0 or 1 auto probe for sequence start.
Property is opt in so default behavior is not affected.
Please note that G_STREAMER is not considered here as I think its out of scope, it already has a "start-index" property and its backend is driven by the pipeline strings rather then these printf patterns.
If an alternative solution is preferred that will not involve a new property or promoting CAP_IMAGES to a "WithParams" variant I don't mind implementing.
### 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
- [ ] 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
Avfoundation fractional fps seek fix#28833
Accompanied by PR on [opencv_extra](https://github.com/opencv/opencv_extra/pull/1345)
Fixes https://github.com/opencv/opencv/issues/28831
AVFoundation backend seeking slowly drifts for any video which has a non-integer frame rate.
Narrowing of a float `mAssetTrack.nominalFrameRate` to int32_t means fractional rates are treated as integer when seeking by frame number.
Solution implemented in this branch is to use the tracks native rational frame duration when seeking (and available).
I've also included an AVF only test case which uses a new test file in opencv_extra. This test just compares the video caps expected ms vs actual for a known rate file (23.976).
Could consider extending this test to more then just AVF, as from what I can see there are no fractional rate tests / files.
### 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
videoio(gstreamer): fix timestamp drift and color negotiation on Apple #28535
This commit addresses two issues on macOS with Apple M3 hardware:
1. Replaces floating-point timestamp math with gst_util_uint64_scale_int to ensure nanosecond precision.
2. Explicitly forces I420 format in the encoding profile to prevent hardware encoder negotiation failure.
### 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
- [ ] The PR is proposed to the proper branch
- [ ] There is a reference to the 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
Fixed picture_sw object leak in ffmpeg backend with hardware codecs. #28283
Replacement for https://github.com/opencv/opencv/pull/28221
### 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
- [ ] The PR is proposed to the proper branch
- [ ] There is a reference to the 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
Fix frame seeking with negative DTS values in FFMPEG backend #27878
**Merge with extra**: https://github.com/opencv/opencv_extra/pull/1289
Fixes https://github.com/opencv/opencv/issues/27819
Fixes https://github.com/opencv/opencv/issues/23472
Accompanied by PR on https://github.com/opencv/opencv_extra/pull/1289
The FFmpeg backend fails to correctly seek in H.264 videos that contain negative DTS values in their initial frames. This is a valid encoding practice used by modern video encoders (such as DaVinci Resolve's current export) where B-frame reordering causes the first few frames to have negative DTS values.
When picture_pts is unavailable (AV_NOPTS_VALUE), the code falls back to using pkt_dts:
`picture_pts = packet_raw.pts != AV_NOPTS_VALUE_ ? packet_raw.pts : packet_raw.dts;`
If this DTS value is negative (which is legal per H.264 spec), it propagates through the frame number calculation:
`frame_number = dts_to_frame_number(picture_pts) - first_frame_number;`
This results in negative frame numbers, messing up seeking operations.
Solution implemented in this branch is a timestamp normalization similar to FFmpegs -avoid_negative_ts_make_zero flag:
- Calculate a global offset once on the first decoded frame by getting the minimum timestamp in either:
- Container start_time
- Stream start_time
- First observed timestamp (PTS, then DTS).
- Apply the offset consistently to all timestamps, shifting negative values to begin at 0 while keeping relative timing.
- Simplify timestamp converters to remove `start_time` subtractions since timestamps are pre-normalized.
This also includes a new test `videoio_ffmpeg.seek_with_negative_dts`
This test verifies that seeking behavior performs as expected on a file which has negative DTS values in the first frames.
A PR on opencv_extra accompanies this one with that testing file: https://github.com/opencv/opencv_extra/pull/1279
```
opencv_extra=ffmpeg-videoio-negative-dts-test-data
```
<cut/>
### 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
- [ ] 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
videoio(ios): fix NSInvalidArgumentException in VideoWriter release #28173
Summary
Fixes a crash on iOS when calling `VideoWriter::release()` in OpenCV 4.12.0.
Issue
Fixes#28165
Detailed Description
This PR resolves a regression where an `NSInvalidArgumentException` was thrown with the message ` -[NSAutoreleasePool retain]: Cannot retain an autorelease pool`.
The crash was caused by the manual usage of `NSAutoreleasePool` in the `~CvVideoWriter_AVFoundation` destructor. The local pool variable was being captured by the completion handler block passed to `[mMovieWriter finishWritingWithCompletionHandler:]`. Since `NSAutoreleasePool` instances cannot be retained, capturing them in a block causes a crash.
Changes:
- Replaced manual `NSAutoreleasePool` allocation and draining with modern `@autoreleasepool` blocks in `CvVideoWriter_AVFoundation`.
- applied this modernization to the Constructor, Destructor, and `write` methods.
- Specifically in the destructor, an inner `@autoreleasepool` is now used inside the completion block, ensuring no pool object needs to be captured from the outer scope.
catch _com_error exceptions to suppress debugger flooding #28073Resolves: #27643
This PR fixes an issue where the Microsoft Media Foundation (MSMF) backend triggers repeated C++ exceptions (_com_error) during video capture. While these exceptions are often non-fatal "first-chance" exceptions, they cause the Visual Studio debugger to break execution repeatedly, making debugging difficulty and flooding the output window.
Changes
cap_msmf.cpp: Added try-catch blocks around critical COM interaction paths.
Updated SourceReaderCB::OnReadSample (Async callback) to catch _com_error.
Updated CvCapture_MSMF::grabFrame (Synchronous grab) to catch _com_error.
Added CV_LOG_WARNING to log the error message from the caught exception, ensuring that actual errors are still visible in the logs without crashing the application or halting the debugger.
Impact
Users debugging OpenCV applications on Windows with Visual Studio will no longer be interrupted by internal MSMF exceptions when using the default backend.
The application flow remains uninterrupted even if MSMF encounters transient internal errors.
Vibhor
Alexander Smorkalov
Mansour Moufid
Fulnergy
Abhishek Gola
Yixuan Tang
Ebrahim Namdari
Maksim Shabunin
Teddy-Yangjiale
Alex
Andrew Yooeun Chun
Ahmad
Murat Raimbekov
Alexander Smorkalov
Kumataro
Vincent Rabaud
satyam yadav
ramukhsuya