# Using CAP\_MSMF and CAP\_DSHOW at same time with two cameras causes "can't grab frame. Error: -2147483638" **URL:** \ **Category:** Python\ **Tags:** videoio\ **Created:** [May 9, 2021, 9:26am UTC](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239 "2021-05-09T09:26:46Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![Michael.Uray](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opencv.org/michael.uray/32/2061_2.png) [@Michael.Uray](https://forum.opencv.org/u/Michael.Uray)\ **Post date:** [May 9, 2021, 9:26am UTC](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239/1 "2021-05-09T09:26:46Z")
Hi guys, I try to use two USB cams at the same time, one uses `VideoCapture()` with `CAP_MSMF` (thermal camera) and the other one with `CAP_DSHOW` (webcam). ``` System: Windows 10 (20H2) Python: 3.9.4 opencv-python: 4.5.2.52 ``` Both programs work fine if itself if started as single application, but if I start both at the same time, then the camera which uses `CAP_MSMF` ends with the following error message during `read()`: ```auto [WARN:0] global C:\Users\runneradmin\AppData\Local\Temp\pip-req-build-m8us58q4\opencv\modules\videoio\src\cap_msmf.cpp (1021) CvCapture_MSMF::grabFrame videoio(MSMF): can't grab frame. Error: -2147483638 ``` This is how the call of the webcam with `CAP_DSHOW` looks like: ```auto # initialize the video stream print("[INFO] starting video stream...") vs = VideoStream(src=1) # call inside WebcamVideoStream class: self.stream = cv2.VideoCapture(src, cv2.CAP_DSHOW) print("CAP_PROP_FRAME_WIDTH") vs.stream.stream.set(cv2.CAP_PROP_FRAME_WIDTH, 1280) print("CAP_PROP_FRAME_HEIGHT") vs.stream.stream.set(cv2.CAP_PROP_FRAME_HEIGHT, 720) print("CAP_PROP_FPS") vs.stream.stream.set(cv2.CAP_PROP_FPS, 25) vs.start() # loop over the frames from the video stream while True: # grab the frame from the threaded video stream frame = vs.read() ... # not relevant frame processing snipped cv2.imshow("webcam_tf", frame) if cv2.waitKey(20) == 27: break ``` This is how the call of the thermal cam with `CAP_MSMF` looks like: ```auto print("starting thermalcam...") cv2.namedWindow("thermalcam") cap = cv2.VideoCapture(0, cv2.CAP_MSMF) print("CAP_PROP_FPS") cap.set(cv2.CAP_PROP_FPS, 25) # request raw data from CV cap.set(cv2.CAP_PROP_CONVERT_RGB, 0) # request raw data from camera cap.set(cv2.CAP_PROP_ZOOM, 0x8004) # shutter cap.set(cv2.CAP_PROP_ZOOM, 32768) if cap.isOpened(): # try to get the first frame print("Read first frame") rval, frame = cap.read() else: print("Error opening webcam") rval = False if rval: print("Start cyclic reading") while True: # WEBCAM rval, frame = cap.read() if not rval: break ... # not relevant frame processing snipped frame = cv2.cvtColor(frame, cv2.COLOR_BGR2RGB) heatmap_gray = cv2.cvtColor(frame, cv2.COLOR_RGB2GRAY) heatmap = cv2.applyColorMap(heatmap_gray, cv2.COLORMAP_HOT) heatmap = imutils.resize(heatmap, width=640) cv2.imshow("thermalcam", heatmap) if cv2.waitKey(20) == 27: break ``` I actually load both cameras into separate processes, means they should not use the same ressources inside Python for sure. This error even happens if I start the second camera in a separate Python (Miniconda) environment. Any idea what could cause this problem on the `CAP_MSMF` device if a second device with `CAP_DSHOW` gets started? ---
**Author:** ![crackwitz](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opencv.org/crackwitz/32/14_2.png) [@crackwitz](https://forum.opencv.org/u/crackwitz)\ **Post date:** [May 9, 2021, 9:59am UTC](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239/2 "2021-05-09T09:59:21Z")
do not use “VideoStream” from imutils. that library adds nothing of value here. directly use OpenCV’s VideoCapture. try accessing both cameras with `apiPreference=cv.CAP_MSMF` ---
**Author:** ![Michael.Uray](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opencv.org/michael.uray/32/2061_2.png) [@Michael.Uray](https://forum.opencv.org/u/Michael.Uray)\ **Post date:** [May 9, 2021, 10:52am UTC](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239/3 "2021-05-09T10:52:49Z")
> [@crackwitz](#): > > do not use “VideoStream” from imutils. that library adds nothing of value here. Even if adds nothing of value here, could it cause any problems like this? I am actually pretty new to Python as well as to OpenCV and I try to run the Face-Mask-Detection Python script which further uses the imutils stream in [detect\_mask\_video.py](https://github.com/chandrikadeb7/Face-Mask-Detection/blob/master/detect_mask_video.py) If there is no problem to expect with using “VideoStream” from imutils, then I would prefer to stay with it at the moment to prevent too much code changes there on the begin. With `CAP_MSMF` on the Webcam I experienced a very long start up time on the Webcam, probably caused by this [issue](https://github.com/opencv/opencv/issues/17687) there. This was the reason why I changed for testing purposes directly the call in the imutils library file `webcamvideostream.py` as followed to test it with `CAP_DSHOW`. ```auto # self.stream = cv2.VideoCapture(src) self.stream = cv2.VideoCapture(src, cv2.CAP_DSHOW) (self.grabbed, self.frame) = self.stream.read() ``` These set() functions also fail (set\_ret == false) if I use `CAP_MSMF` instead of `CAP_DSHOW` as API backend. ```auto print("CAP_PROP_FRAME_WIDTH") set_ret = vs.stream.stream.set(cv2.CAP_PROP_FRAME_WIDTH, 1280) print("CAP_PROP_FRAME_HEIGHT") set_ret = vs.stream.stream.set(cv2.CAP_PROP_FRAME_HEIGHT, 720) print("CAP_PROP_FPS") set_ret = vs.stream.stream.set(cv2.CAP_PROP_FPS, 25) ``` So far as I have seen does imutils internally also use `VideoCapture()`. Would you think it could help to not use the “VideoStream” from imutils? ---
**Author:** ![crackwitz](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opencv.org/crackwitz/32/14_2.png) [@crackwitz](https://forum.opencv.org/u/crackwitz)\ **Post date:** [May 9, 2021, 11:23am UTC](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239/4 "2021-05-09T11:23:31Z")
since you are aware of its implementation and how it uses `VideoCapture`, there’s no harm. it is however needless abstraction. since MSMF seems to cause trouble, can you open both cameras using CAP\_DSHOW instead? ---
**Author:** ![matti.vuori](https://avatars.discourse-cdn.com/v4/letter/m/e79b87/32.png) [@matti.vuori](https://forum.opencv.org/u/matti.vuori)\ **Post date:** [May 9, 2021, 12:45pm UTC](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239/5 "2021-05-09T12:45:51Z")
There could be problems caused by imuitils. For example, it could be programmed to use to one just camera configuration that it uses for multiple VideoCaptute objects. And anyway, any unnecessary code is a potential for unnecessary bugs. ---
**Author:** ![Michael.Uray](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opencv.org/michael.uray/32/2061_2.png) [@Michael.Uray](https://forum.opencv.org/u/Michael.Uray)\ **Post date:** [May 9, 2021, 4:14pm UTC](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239/6 "2021-05-09T16:14:37Z")
> [@crackwitz](#): > > since MSMF seems to cause trouble, can you open both cameras using CAP\_DSHOW instead? To read out the thermal cam I use a modified version from the [ht301\_hacklib](https://github.com/stawel/ht301_hacklib/blob/f5f1d1f701128a235c2ab3325085d1902d251aa5/ht301_hacklib.py#L244). ```auto # if video_dev == None: # video_dev = self.find_device() # self.cap = cv2.VideoCapture(video_dev) # self.cap = cv2.VideoCapture(0, cv2.CAP_DSHOW) self.cap = cv2.VideoCapture(0, cv2.CAP_MSMF) if not self.isHt301(self.cap): Exception('device ' + str(video_dev) + ": HT301 not found!") ret_val = self.cap.set(cv2.CAP_PROP_CONVERT_RGB, 0) # Use raw mode command to camera self.cap.set(cv2.CAP_PROP_ZOOM, 0x8004) ``` The data frame after `read()` looks like this: ```auto ret, frame = self.cap.read() ``` ![2021-05-09_17-04-02_ht301_hacklib.py_-ht301_hacklib-_Visual_Studio_C](https://us1.discourse-cdn.com/flex020/uploads/opencv/original/2X/6/6ccb332a3a5f7f09682a085a241c467c4b5af52b.png) And it is possible to reshape it to get a 2 dimensional array of u16 with 256x196. ```auto dt = np.dtype(' **Author:** ![Michael.Uray](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opencv.org/michael.uray/32/2061_2.png) [@Michael.Uray](https://forum.opencv.org/u/Michael.Uray)\ **Post date:** [May 9, 2021, 4:23pm UTC](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239/7 "2021-05-09T16:23:10Z") > [@matti.vuori](#): > > For example, it could be programmed to use to one just camera configuration that it uses for multiple VideoCaptute objects. So far as I can see [decides](https://github.com/jrosebr1/imutils/blob/master/imutils/video/videostream.py#L8) its code only to us a piCamera or the [cv2.VideoCapture()](https://github.com/jrosebr1/imutils/blob/c12f15391fcc945d0d644b85194b8c044a392e0a/imutils/video/webcamvideostream.py#L9). How could imutils affect the camera operation even if I run the second camera in a separate Python Miniconda environment? ---
**Author:** ![crackwitz](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opencv.org/crackwitz/32/14_2.png) [@crackwitz](https://forum.opencv.org/u/crackwitz)\ **Post date:** [May 9, 2021, 5:58pm UTC](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239/8 "2021-05-09T17:58:54Z")
> [@Michael.Uray](#): > > ```auto > ret_val = cap.set(cv2.CAP_PROP_CONVERT_RGB, 0) > > ``` that should have an effect even with CAP\_DSHOW. if it does not, it’s a bug in OpenCV and worth opening an issue. perhaps the functionality hasn’t been implemented… or it hasn’t been implemented for whatever pixel format the device reports. either way, you’ve encountered some bugs I’d say are located in OpenCV. - using both MSMF and DSHOW at the same time _should_ be working - DSHOW and `CAP_PROP_CONVERT_RGB` being false should work as expected, not return an RGB/BGR array > ---
**Author:** ![Michael.Uray](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opencv.org/michael.uray/32/2061_2.png) [@Michael.Uray](https://forum.opencv.org/u/Michael.Uray)\ **Post date:** [May 9, 2021, 8:56pm UTC](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239/9 "2021-05-09T20:56:55Z")
I understand, that if I set `cv2.CAP_PROP_CONVERT_RGB = 0`, then I should receive a frame as 1D u8 array, independent from the backend. Some more tests I did with the two cameras do not reflect my understanding. **Thermal cam with `CAP_MSMF`:** ```auto import cv2 import numpy as np # devices: 0 = thermal cam, 1 = webcam #video = cv2.VideoCapture(0, cv2.CAP_DSHOW) video = cv2.VideoCapture(0, cv2.CAP_MSMF) #video.set(cv2.CAP_PROP_FOURCC, 0x32595559) # request raw data from camera ret_val = video.set(cv2.CAP_PROP_ZOOM, 0x8004) # activate shutter at camera ret_val = video.set(cv2.CAP_PROP_ZOOM, 32768) # request RAW data from CV API ret_val = video.set(cv2.CAP_PROP_CONVERT_RGB, 0) print ("Video FOURCC") print (hex(int(video.get(cv2.CAP_PROP_FOURCC)) & 0xffffffff)) if video.isOpened(): # try to get the first frame rval, frame = video.read() else: rval = False ``` ```auto Video FOURCC 0x32595559 ``` 0x32595559 == “2YUY” Returns 100352 bytes as shape:(1, 100352). **Thermal cam with `CAP_DSHOW`:** ```auto import cv2 import numpy as np # devices: 0 = thermal cam, 1 = webcam video = cv2.VideoCapture(0, cv2.CAP_DSHOW) #video = cv2.VideoCapture(0, cv2.CAP_MSMF) #video.set(cv2.CAP_PROP_FOURCC, 0x32595559) # request raw data from camera ret_val = video.set(cv2.CAP_PROP_ZOOM, 0x8004) # activate shutter at camera ret_val = video.set(cv2.CAP_PROP_ZOOM, 32768) # request RAW data from CV API ret_val = video.set(cv2.CAP_PROP_CONVERT_RGB, 0) print ("Video FOURCC") print (hex(int(video.get(cv2.CAP_PROP_FOURCC)) & 0xffffffff)) if video.isOpened(): # try to get the first frame rval, frame = video.read() else: rval = False ``` ```auto Video FOURCC 0xe436eb7d ``` 0xe436eb7d == “ä6ë}” Returns 150528 bytes as shape:(196, 256, 3). **Webcam with `CAP_MSMF`:** ```auto import cv2 import numpy as np # devices: 0 = thermal cam, 1 = webcam #video = cv2.VideoCapture(1, cv2.CAP_DSHOW) video = cv2.VideoCapture(1, cv2.CAP_MSMF) #video.set(cv2.CAP_PROP_FOURCC, 0x32595559) # request raw data from camera ret_val = video.set(cv2.CAP_PROP_ZOOM, 0x8004) # activate shutter at camera #ret_val = video.set(cv2.CAP_PROP_ZOOM, 32768) # request RAW data from CV API #ret_val = video.set(cv2.CAP_PROP_CONVERT_RGB, 0) print ("Video FOURCC") print (hex(int(video.get(cv2.CAP_PROP_FOURCC)) & 0xffffffff)) if video.isOpened(): # try to get the first frame rval, frame = video.read() else: rval = False ``` ```auto Video FOURCC 0x16 ``` 0x16 == not a readable ASCII code. Returns 921600 bytes as shape:(480, 640, 3). **Webcam with `CAP_DSHOW`:** ```auto import cv2 import numpy as np # devices: 0 = thermal cam, 1 = webcam video = cv2.VideoCapture(1, cv2.CAP_DSHOW) #video = cv2.VideoCapture(1, cv2.CAP_MSMF) #video.set(cv2.CAP_PROP_FOURCC, 0x32595559) # request raw data from camera ret_val = video.set(cv2.CAP_PROP_ZOOM, 0x8004) # activate shutter at camera #ret_val = video.set(cv2.CAP_PROP_ZOOM, 32768) # request RAW data from CV API #ret_val = video.set(cv2.CAP_PROP_CONVERT_RGB, 0) print ("Video FOURCC") print (hex(int(video.get(cv2.CAP_PROP_FOURCC)) & 0xffffffff)) if video.isOpened(): # try to get the first frame rval, frame = video.read() else: rval = False ``` ```auto Video FOURCC 0x32595559 == "2YUY" ``` Returns 921600 bytes as shape:(480, 640, 3). Is this the way how it should be? ---
**Author:** ![Michael.Uray](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opencv.org/michael.uray/32/2061_2.png) [@Michael.Uray](https://forum.opencv.org/u/Michael.Uray)\ **Post date:** [May 9, 2021, 10:11pm UTC](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239/10 "2021-05-09T22:11:49Z")
> [@crackwitz](#): > > using both MSMF and DSHOW at the same time _should_ be working I did some tests to isolate this problem a bit more. During my tests a had two webcams connected. **`test1.py`** , which uses `CAP_MSMF`: ```auto import cv2 import numpy as np #video = cv2.VideoCapture(0, cv2.CAP_DSHOW) video = cv2.VideoCapture(0, cv2.CAP_MSMF) print ("Video FOURCC") print (hex(int(video.get(cv2.CAP_PROP_FOURCC)) & 0xffffffff)) if video.isOpened(): # try to get the first frame rval, frame = video.read() else: rval = False while 1: cv2.imshow("preview1", frame) rval, frame = video.read() key = cv2.waitKey(1) if key == 27: # exit on ESC break ``` **`test2.py`** , which uses `CAP_DSHOW`: ```auto import cv2 import numpy as np video = cv2.VideoCapture(1, cv2.CAP_DSHOW) #video = cv2.VideoCapture(1, cv2.CAP_MSMF) print ("Video FOURCC") print (hex(int(video.get(cv2.CAP_PROP_FOURCC)) & 0xffffffff)) if video.isOpened(): # try to get the first frame rval, frame = video.read() else: rval = False while 1: cv2.imshow("preview2", frame) rval, frame = video.read() key = cv2.waitKey(1) if key == 27: # exit on ESC break ``` If I start `test2.py` (`CAP_DSHOW`) first and after it `test1.py` (`CAP_MSMF`), then everything is fine and both videos are shown. But if I do it the other way around, then `video.isOpened()` in test2.py returns false and it is not possible to read a frame. The behavior is a bit different to the issue which happened during my test with the thermal cam, but it points out that there is a problem using `CAP_DSHOW` and `CAP_MSMF` at the same time. ---
**Author:** ![Michael.Uray](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opencv.org/michael.uray/32/2061_2.png) [@Michael.Uray](https://forum.opencv.org/u/Michael.Uray)\ **Post date:** [May 10, 2021, 7:28am UTC](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239/11 "2021-05-10T07:28:06Z")
> [@crackwitz](#): > > if it does not, it’s a bug in OpenCV and worth opening an issue. > … > either way, you’ve encountered some bugs I’d say are located in OpenCV. > > - using both MSMF and DSHOW at the same time _should_ be working > - DSHOW and `CAP_PROP_CONVERT_RGB` being false should work as expected, not return an RGB/BGR array I did open an issue regarding the MSMF and DSHOW problem, it clearly looks to me like an unwanted behaviour. > > > \##### System information (version) > \- OpenCV =\> 4.5.2.52 > \- Python: Python 3.9.4… > \- Operating System =\> Windows 64 Bit (20H2) > > \##### Detailed description > If I start one camera with CAP\_MSMF and the second one with CAP\_DSHOW a bit later, then it fails to open the CAP\_DSHOW camera. > If i do it the other way around it works without problem. > > In another program I experienced the situation, that it even interrupted the reading of the CAP\_MSMF camera with the following error, if I started the second camera with CAP\_DSHOW later. > \`\[WARN:0\] global C:\\Users\\runneradmin\\AppData\\Local\\Temp\\pip-req-build-m8us58q4\\opencv\\modules\\videoio\\src\\cap\_msmf.cpp (1021) CvCapture\_MSMF::grabFrame videoio(MSMF): can't grab frame. Error: -2147483638 > \` > > \[This\](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239) is the according discussion in the OpenCV forum. > > \##### Steps to reproduce > During my tests a had two USB webcams connected via a USB 3.0 hub. > > \*\*\`test1.py\`\*\*, which uses \`CAP\_MSMF\`: > \`\`\` > import cv2 > import numpy as np > > \#video = cv2.VideoCapture(0, cv2.CAP\_DSHOW) > video = cv2.VideoCapture(0, cv2.CAP\_MSMF) > > if video.isOpened(): # try to get the first frame > rval, frame = video.read() > else: > rval = False > > while 1: > cv2.imshow("preview1", frame) > rval, frame = video.read() > > key = cv2.waitKey(1) > if key == 27: # exit on ESC > break > \`\`\` > > > \*\*\`test2.py\`\*\*, which uses \`CAP\_DSHOW\`: > \`\`\` > import cv2 > import numpy as np > > video = cv2.VideoCapture(1, cv2.CAP\_DSHOW) > \#video = cv2.VideoCapture(1, cv2.CAP\_MSMF) > > if video.isOpened(): # try to get the first frame > rval, frame = video.read() > else: > rval = False > > while 1: > cv2.imshow("preview2", frame) > rval, frame = video.read() > > key = cv2.waitKey(1) > if key == 27: # exit on ESC > break > \`\`\` > > If I start \`test2.py\` (\`CAP\_DSHOW\`) first and after it \`test1.py\` (\`CAP\_MSMF\`), then everything is fine and both videos are shown. > But if I do it the other way around, then \`video.isOpened()\` in test2.py returns false and it is not possible to read a frame. > > The behavior is a bit different to the issue which happened during my test with a thermal cam (it interruped an already opened camera frame reading with the error mentioned above), but it points out that there is a problem using \`CAP\_DSHOW\` and \`CAP\_MSMF\` at the same time. Not sure about the `CAP_PROP_CONVERT_RGB` issue, maybe I do not understand completly how it should work. Would you say that [these](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239/9) results there are how it should be? Or should it return a 1D uint8 array in every situation if `CAP_PROP_CONVERT_RGB` is set to 0? ---
**Author:** ![crackwitz](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opencv.org/crackwitz/32/14_2.png) [@crackwitz](https://forum.opencv.org/u/crackwitz)\ **Post date:** [May 10, 2021, 5:44pm UTC](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239/12 "2021-05-10T17:44:12Z")
> [@Michael.Uray](#): > > Would you say that [these](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239/9) results there are how it should be? Or should it return a 1D uint8 array in every situation if `CAP_PROP_CONVERT_RGB` is set to 0? depends. if the source is RGB, it should ideally return RGB (rather than BGR, which is OpenCV’s “native” format). if the source is some YUV, it should return that… or “bytes”. if the source is Y16 (grayscale) it should return that… or “bytes”. if the source is some compressed data, it should return that as “bytes”. if it gives you some 3-channel data for the thermal camera, even though you asked for disabled CONVERT\_RGB, it’s a bug… or the camera has a “capture pin” that emits a false-color picture in addition to physical quantities (temperature). ---
**Author:** ![Michael.Uray](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opencv.org/michael.uray/32/2061_2.png) [@Michael.Uray](https://forum.opencv.org/u/Michael.Uray)\ **Post date:** [May 10, 2021, 8:44pm UTC](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239/13 "2021-05-10T20:44:42Z")
> [@crackwitz](#): > > or the camera has a “capture pin” that emits a false-color picture in addition to physical quantities (temperature). The camera has several modes (e.g. colored RGB) and one of them is the raw mode which gets activated via this command, using the zoom channel. > [@Michael.Uray](#): > > ```auto > # request raw data from camera > cap.set(cv2.CAP_PROP_ZOOM, 0x8004) > > ``` The commands work fine in general with `CAP_MSMF` as well as with `CAP_DSHOW`, because the shutter command works without problems with both APIs and it also uses the zoom channel. > [@Michael.Uray](#): > > ```auto > # shutter > cap.set(cv2.CAP_PROP_ZOOM, 32768) > > ``` If I set the RAW data command to the camera, then the camera stays in RAW mode until it looses its power. I can see this by opening any other camera application accessing the thermal camera after I have sent a command for RAW or any other modes. If the camera provides RAW data but it only works via `CAP_MSMF`, then I asume a problem with `CAP_DSHOW`. Is the raw mode operation just rarely used in opencv that no one would notice such a problem? ---
**Author:** ![crackwitz](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.opencv.org/crackwitz/32/14_2.png) [@crackwitz](https://forum.opencv.org/u/crackwitz)\ **Post date:** [May 11, 2021, 10:24am UTC](https://forum.opencv.org/t/using-cap-msmf-and-cap-dshow-at-same-time-with-two-cameras-causes-cant-grab-frame-error-2147483638/3239/14 "2021-05-11T10:24:42Z")
it’s a fairly new feature and not implemented uniformly across all the backends… because nobody knows all the backends, or can test them. most people who notice a problem either live with it or work around it. you’re the first of the remaining few who actually need it to work and can’t use a workaround. someone is always first. the world can be very small sometimes. the open issue about failure to open the device is a good step. the “raw” mode (CONVERT\_RGB false) for DSHOW not working right… I see some issues that look related, so I guess someone’s aware of the problem at least: [Issues · opencv/opencv · GitHub](https://github.com/opencv/opencv/issues?q=CONVERT_RGB) feel free to add any of your investigative findings to these issues, or link back to this thread. it’d help anyone willing to implement a fix.