New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 680906 link

Starred by 4 users

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature

Blocking:
issue 616098



Sign in to add a comment

Support depth capture and Media Capture Depth Stream Extensions API for RealSense and Kinectv2 on OSX

Project Member Reported by aleksand...@intel.com, Jan 13 2017

Issue description

This is a sub-task of Issue 616098.
Currently, Intel® RealSense depth cameras capture is supported on Windows, Linux & ChromeOS.
Work is ongoing on supporting Android Tango v2 depth capture on Android -  Issue 674440 .

There is no support for depth capture on OSX.
RealSense cameras [1] and Kinect v2 [1] could be supported using libusb.

[1]
https://github.com/IntelRealSense/librealsense/blob/master/src/libuvc/dev.c
[2]
https://github.com/OpenKinect/libfreenect2
 
Blocking: 616098
>RealSense cameras [1] and Kinect v2 [1] could be supported using libusb.
mcasas@, emircan@,
I did a quick prototype on this and it seems feasible.
What's your opinion on adding libusb based video capture to Chromium?

Note: targeting OSX here but guess it could be used elsewhere, too.

Comment 2 by mcasas@chromium.org, Jan 18 2017

Would you propose using libusb only for these new devices or migrate
completely to it? In Mac we use [0] to supplement [1] "normal" OS cameras
for Decklink/Blackmagic purposes, so there is a precedent, at least.

Usually adding a library to third_party/ has to face security and size
concerns first and maintenance concerns later.  third_party libs are
or must be rolled frequently and a number of bots/tests set up to 
catch any potential regressions etc.  Also, licensing must be 
studied. Once all that is cleared, [2] outlines the process of 
actually adding it.

[0] https://cs.chromium.org/chromium/src/third_party/decklink/?q=third_party/decklink&sq=package:chromium&dr
[1] https://cs.chromium.org/chromium/src/media/capture/video/mac/video_capture_device_factory_mac.mm?sq=package:chromium&dr=CSs&l=104
[2] https://chromium.googlesource.com/chromium/src.git/+/master/docs/adding_to_third_party.md
Thanks.

I'm thinking to use it only for those not recognized by AVFoundation and Decklink/Blackmagic.

libusb is already there, under src/third_party/libusb/. I noticed it is used by src/device/usb but didn't verify it is already compiled in to OSX binary. In the prototype, it was sufficient to add deps += "//third_party/libusb" to media/capture/BUILD.gn.


Comment 4 by mcasas@chromium.org, Jan 18 2017

Cc: reillyg@chromium.org
+reillyg@ what's the usage of libusb now?
//third_party/libusb is used by //device/usb and nowhere else. I discourage other uses of libusb and suggest using the API exposed by //device/usb instead.

Comment 6 by rbyers@chromium.org, Jan 18 2017

Components: Blink>GetUserMedia

Comment 7 by guidou@chromium.org, Jan 23 2017

Status: Assigned (was: Untriaged)
Should have updated this earlier - for the same reason as with Android Tango[1], seems that Kinect2 support is also a WontFix. Microsoft Kinect page states [2]:

"
Manufacturing of the Kinect sensor and adapter has been discontinued, but the Kinect technology continues to live on in products like the HoloLens, Cortana voice assistant, the Windows Hello biometric facial ID system, and a context-aware user interface.

Microsoft is working with Intel to provide an option for developers looking to transition from the Kinect for Windows platform. Microsoft will continue to provide support for the Kinect for Windows SDK via our online forums, premiere and paid technical support. As developers transition from Kinect hardware, Microsoft encourages developers to look into Intel’s RealSense depth cameras. 
"

[1]
https://bugs.chromium.org/p/chromium/issues/detail?id=674440#c12
[2]
https://developer.microsoft.com/en-us/windows/kinect 

Sign in to add a comment