On windows11, using VideoCapture to open the SONY camera in CAP_DSHOW mode, 60FPS, the decoder uses MJPG, there is a serious memory leak problem

windows11, C++, OpenCV 455,470 versions have this problem, other versions may also have it, did not do too much testing.
The following code does not leak on windows10.

#include <opencv2/opencv.hpp>
#include <iostream>
#include <iosfwd>
#include <fstream>
#include <opencv2/highgui.hpp>


#include <opencv2/opencv.hpp>
#include <iostream>
#include <vector>
#include <dshow.h>
#include <comdef.h>

struct CameraInfo {
	std::string name;
	int index;
};

std::vector<CameraInfo> getCameraList() {
	std::vector<CameraInfo> cameraList;

	ICreateDevEnum* devEnum = nullptr;
	IEnumMoniker* enumMoniker = nullptr;
	IMoniker* moniker = nullptr;
	IPropertyBag* propertyBag = nullptr;

	CoInitializeEx(NULL, COINIT_MULTITHREADED);
	CoCreateInstance(CLSID_SystemDeviceEnum, NULL, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&devEnum));
	devEnum->CreateClassEnumerator(CLSID_VideoInputDeviceCategory, &enumMoniker, 0);

	ULONG fetched;
	while (enumMoniker->Next(1, &moniker, &fetched) == S_OK) {
		VARIANT varName;
		VariantInit(&varName);

		moniker->BindToStorage(0, 0, IID_PPV_ARGS(&propertyBag));
		propertyBag->Read(L"FriendlyName", &varName, 0);

		CameraInfo cameraInfo;
		cameraInfo.name = static_cast<char*>(_bstr_t(varName));
		cameraInfo.index = cameraList.size();
		cameraList.push_back(cameraInfo);

		VariantClear(&varName);
		propertyBag->Release();
		moniker->Release();
	}

	enumMoniker->Release();
	devEnum->Release();
	CoUninitialize();

	return cameraList;
}

int main() {
	

	std::vector<CameraInfo> cameraList = getCameraList();

	std::cout << "List of available cameras:" << std::endl;
	for (int i = 0; i < cameraList.size(); ++i) {
		std::cout << i << ". " << cameraList[i].name << std::endl;
	}

	int selectedCameraIndex = 0; 
	std::cin >> selectedCameraIndex;
	cv::VideoCapture frameCapture;
	bool b1 = frameCapture.open(selectedCameraIndex, cv::CAP_DSHOW);

	auto nInitFOURCC = frameCapture.get(cv::CAP_PROP_FOURCC);
	bool bSetFrameWidthSuccessed = frameCapture.set(cv::CAP_PROP_FRAME_WIDTH, 1920);
	bool bSetFrameHeightSuccessed = frameCapture.set(cv::CAP_PROP_FRAME_HEIGHT, 1080);

	//bool bSetFOURCC = frameCapture.set(cv::CAP_PROP_FOURCC, cv::VideoWriter::fourcc('Y', 'U', 'Y', '2'));
	//auto nModifyFOURCC = frameCapture.get(cv::CAP_PROP_FOURCC);

	double actualFps = frameCapture.get(cv::CAP_PROP_FPS);
	int nColorCameraFPS_WhenColorMode = 60;
	frameCapture.set(cv::CAP_PROP_FPS, nColorCameraFPS_WhenColorMode);
	actualFps = frameCapture.get(cv::CAP_PROP_FPS);
	if (actualFps != nColorCameraFPS_WhenColorMode && actualFps < 30)
	{
		nColorCameraFPS_WhenColorMode = 30;
		frameCapture.set(cv::CAP_PROP_FPS, nColorCameraFPS_WhenColorMode);
	}

	/*
		*CAP_PROP_FOURCC is important.Used to solve the problem of picture stuttering.
		*
		*This property sets what format to decode, this decoding is currently tested down the general default decoding to YUV2, but some cameras in YUY2 only 5 frames(less than 30 frame rate support), resulting in a picture feeling very cardstock, even if we call
		* frameCapture.set(cv::CAP_PROP_FPS, nColorCameraFPS_WhenColorMode);   Set a >= 30 frame fetch requirement, also returned true.But the actual map still can not get 30 frames per second, even only 5 frame rate.
		* For example, the Sonysony ILCE - 7M3 camera only supports 5 frames in YUY2 format, while it supports 10, 20, 25, 30, 60 in MJGP format.
		*
		*One more thing to note is that the code for setting the decoder must be placed at the end of setting resolutionand frame rate, that is, at the end of capture.Otherwise it's still going to run out.  
		*
		*In.open(index, cv::CAP_ANY / cv::CAP_DSHOW), when the default cv::CAP_ANY, you do not need to set CAP_PROP_FOURCCand will not get stuck, but in cv::CAP_ANY mode, There will be cases where the camera picture is wrong,
		* Using cv::CAP_DSHOW can solve the problem of camera holding the wrong picture, but it will cause a deadlock, the solution is to set CAP_PROP_FOURCC at the last time(currently testing MJPG decoding format is the format that most cameras support high frame rate)
	*/
	char fourcc_1 = 'M';
	char fourcc_2 = 'J';
	char fourcc_3 = 'P';
	char fourcc_4 = 'G';

	bool bSetFOURCC = frameCapture.set(cv::CAP_PROP_FOURCC, cv::VideoWriter::fourcc('M', 'J', 'P', 'G'));
	auto nNowCaptureFOURCC = frameCapture.get(cv::CAP_PROP_FOURCC);
	auto nNowCaptureFPS = frameCapture.get(cv::CAP_PROP_FPS);
	auto nNowCaptureWIDTH = frameCapture.get(cv::CAP_PROP_FRAME_WIDTH);
	auto nNowCaptureHEIGHT = frameCapture.get(cv::CAP_PROP_FRAME_HEIGHT);


	//Try to read the picture first, although some resolutions are supported, but read out may be different from the set resolution, such as 800 * 600 on Sonysony ILCE - 7M3, read out is 720 * 576.  Direct trust in Resolution is unreliable.	
	if (frameCapture.isOpened()) {
		cv::Mat frame;
		while (true) {
			frameCapture >> frame;
			if (!frame.empty()) {
				cv::imshow("Camera Stream", frame);
			}
			if (cv::waitKey(1) == 'q') {
				break;
			}
		}
		frameCapture.release();
		cv::destroyAllWindows();
	}
	else {
		std::cout << "Unable to open the specified camera." << std::endl;
	}

	return 0;
}

The above is the code section.

The reason why I use the opening mode of DShow is that CAP_DShow can get a correct camera index compared with CAP_ANY. Sometimes when I use CAP_ANY, although the index of the camera is 0, what I get is not the camera picture of 0, but the picture of another camera.
The reason for using MJPG decoding is that only MJPG can get a high frame rate picture.
I tried the sequence, the MJPG decoding had to be set after the FPS and the width and height, otherwise I would still get a comparison card picture, even though I was using 60 frames.
Interestingly, when I set the camera frame rate to 30, there was no problem with leaks.

I don’t know if anyone has the same problem as me. Is it the BUG of OpenCV in windows11?

the best wish to everybody!!

Thanks
whitetian
907162706@qq.com

you speak of leaks.

can you quantify that?