Issue metadata
Sign in to add a comment
|
Windows (Hello) depth camera streams are not accessible anymore for some cameras (e.g. Realsense D435) |
||||||||||||||||||||
Issue descriptionThe issue is noticed with Intel RealSense D435 camera. It doesn't happen with older cameras e.g. SR300. This is the design behind the recent change in Windows driver MFT, and related to Windows Hello [1] " This removes the camera from KSCATEGORY_VIDEO, which will block it from being enumerated through the legacy enumeration by regular camera apps. Both the SkipCameraEnumeration and SensorCameraMode entries should be placed in the DDInstall.HW section of the INF file. " Since non-RGB cameras could be marked as sensor cameras in driver inf file, MFEnumDeviceSources would enumerate them only if KSCATEGORY_SENSOR_CAMERA is supplied as attribute (attribute MF_DEVSOURCE_ATTRIBUTE_SOURCE_TYPE_VIDCAP_CATEGORY with value KSCATEGORY_SENSOR_CAMERA). Camera is hidden for DirectShow access, too. DirectShow approach is the default way to enumerate cameras on Windows in Chrome, currently. There seems to be a consensus to replace DirectShow by MediaFoundation in Chrome Issue 735576 #c6 [2]. The fix would then include setting MediaFoundation as default (instead of DirectShow based approach) on Windows8 and later and enumerating also depth/IR cameras using the attribute above. Even though the other depth cameras are visible on Windows, and D435 is visible on Linux, we could reconsider putting this under experimental --enable-blink-features=MediaCaptureDepth or new flag. I'll check this further. [1] https://docs.microsoft.com/en-us/windows-hardware/drivers/stream/windows-hello-camera-driver-bring-up-guide [2] https://bugs.chromium.org/p/chromium/issues/detail?id=735576#c6 ⛆ |
|
|
,
Feb 9 2018
My takeaway from the report was that newer depth cameras are not supported via DirectShow, so this issue is blocked on our work of rolling out the MediaFoundation based video capture.
,
Feb 9 2018
,
Feb 11 2018
,
Feb 13 2018
#2 Yes, it requires MediaFoundation. Note that the regression is not caused by Chrome change - it is the change in Windows and MediaFoundation API. I quickly prototyped the fix. The actions needed to fix this are: a) enable media foundation (Issue 735576) b) When enumerating cameras, enumerate additionally with KSCATEGORY_SENSOR_CAMERA attribute [1] c) Fix regression in Issue 730068#74 (related to IMFCaptureEngine) d) few more nits related to selecting preferred format. [1] https://cs.chromium.org/chromium/src/media/capture/video/win/video_capture_device_factory_win.cc?rcl=4402134e68e443b37121258c8f91b7d497379d3a&l=99
,
Feb 13 2018
aleksand...@intel.com, I don't know if you receive notifications from issue 730068. Please take a look to [1]. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=730068#c77
,
Feb 13 2018
> I don't know if you receive notifications alaoui.rda@gmail.com. Should receive them from now on. Thanks. I feel there's a need to clarify. Issue 730068 patch is regression related to all 16-bit depth cameras. It works fine with default DirectShow implementation or with the patch reverted. Issue here (807293) is related to a specific D415 [1] and D435 [2] as they apparently require MediaFoundation, as describes above. [1] https://click.intel.com/intelr-realsensetm-depth-camera-d415.html [2] https://click.intel.com/intelr-realsensetm-depth-camera-d435.html
,
Feb 22 2018
We saw an issue with this in the wild at Confrere. User has a Windows laptop with the F200 Depth camera, which is for some reason chosen by default with the following constraints:
{
"video": {
"deviceId": "default",
"height": 720,
"width": 1280
},
"audio": {
"deviceId": "default"
}
}
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
Error is NotReadableError.
It's very bad to begin with that the depth camera is selected by default, the RGB camera should probably be default. We are going to work around this issue by listening for NotReadableError, fetching available devices from enumerateDevices and testing the next available camera for now (we have camera selector, so this should be fine).
Going to control panel and selecting a different default camera in the settings (RGB F200) works without issue.
See also attached files. One is an rtcstats dump open it with: https://fippo.github.io/webrtc-dump-importer/rtcstats
Other file is the output of chrome://media-internals. Unfortunately we don't have physical access to the machine for further testing at this point, but we have resolved this issue with the customer.
,
Feb 27 2018
#8 daginge@gmail.com, thanks for the report. F200 has the same depth resolution (640x480) as SR300 [1] so let me try to reproduce and resolve this. Moving this to new Issue 816979. Let's continue there. [1] https://ark.intel.com/products/series/85364/Intel-RealSense-Cameras
,
Mar 9 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3af3bbb84f5badb5a2a6e9ba4cb814b790e7ff1d commit 3af3bbb84f5badb5a2a6e9ba4cb814b790e7ff1d Author: Aleksandar Stojiljkovic <aleksandar.stojiljkovic@intel.com> Date: Fri Mar 09 05:37:33 2018 Access depth (KSCATEGORY_SENSOR_CAMERA) cameras on Windows. The recent change in MediaFoundation API requires explicit enumeration of sensor (newer depth Hello) cameras. Pass-through mode fixes in MF capture implementation. Verified using both Intel® RealSense™ Depth Camera D435 and previous depth cameras, those that are not marked as sensors in driver inf, e.g. SR300. Minor refactoring static -> anonymous namespace. BUG=807293 Change-Id: I8c13d360bfc30cae8902f8e03d553dff69dcbf34 Reviewed-on: https://chromium-review.googlesource.com/944627 Commit-Queue: Aleksandar Stojiljkovic <aleksandar.stojiljkovic@intel.com> Reviewed-by: Max Morin <maxmorin@chromium.org> Reviewed-by: Kinuko Yasuda <kinuko@chromium.org> Reviewed-by: Guido Urdaneta <guidou@chromium.org> Reviewed-by: Christian Fremerey <chfremer@chromium.org> Cr-Commit-Position: refs/heads/master@{#542042} [modify] https://crrev.com/3af3bbb84f5badb5a2a6e9ba4cb814b790e7ff1d/content/browser/media/media_internals_unittest.cc [modify] https://crrev.com/3af3bbb84f5badb5a2a6e9ba4cb814b790e7ff1d/media/capture/BUILD.gn [modify] https://crrev.com/3af3bbb84f5badb5a2a6e9ba4cb814b790e7ff1d/media/capture/mojom/video_capture_types.mojom [modify] https://crrev.com/3af3bbb84f5badb5a2a6e9ba4cb814b790e7ff1d/media/capture/mojom/video_capture_types_mojom_traits.cc [modify] https://crrev.com/3af3bbb84f5badb5a2a6e9ba4cb814b790e7ff1d/media/capture/video/video_capture_device_descriptor.cc [modify] https://crrev.com/3af3bbb84f5badb5a2a6e9ba4cb814b790e7ff1d/media/capture/video/video_capture_device_descriptor.h [modify] https://crrev.com/3af3bbb84f5badb5a2a6e9ba4cb814b790e7ff1d/media/capture/video/win/capability_list_win.cc [modify] https://crrev.com/3af3bbb84f5badb5a2a6e9ba4cb814b790e7ff1d/media/capture/video/win/video_capture_device_factory_win.cc [modify] https://crrev.com/3af3bbb84f5badb5a2a6e9ba4cb814b790e7ff1d/media/capture/video/win/video_capture_device_factory_win.h [add] https://crrev.com/3af3bbb84f5badb5a2a6e9ba4cb814b790e7ff1d/media/capture/video/win/video_capture_device_factory_win_unittest.cc [modify] https://crrev.com/3af3bbb84f5badb5a2a6e9ba4cb814b790e7ff1d/media/capture/video/win/video_capture_device_mf_win.cc [modify] https://crrev.com/3af3bbb84f5badb5a2a6e9ba4cb814b790e7ff1d/media/capture/video/win/video_capture_device_mf_win_unittest.cc |
||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by niklase@chromium.org
, Feb 9 2018