LGTM. PS-NOT-RELATED but make sure that it also works when two real sense cameras are connected on the system. We see some laptop with Realsense cameras on the back and on the front.
Thanks. On Sun, Dec 20, 2015 at 10:32 PM, Hu, Ningxin <ningxin...@intel.com> wrote: > (The google doc version is at: > https://docs.google.com/document/d/1n4Ne7QSYjmpxZ_KBhCrqHTIMFrXuYpGoKpylNo2ScnA/edit?usp=sharing > ) > > > > *Description:* > > There are dozens of Windows 10 devices in the market equipped with Intel > RealSense cameras, see the list at > http://www.intel.com/content/www/us/en/architecture-and-technology/realsense-devices.html. > > > The 3D imaging capability of RealSense cameras enables innovative user > experiences like hand gesture based gaming, depth enabled photography, > augmented reality and 3D scanning etc. > > Thanks to the extension mechanism, Crosswalk apps are able to access the > RealSense camera and corresponding middlewares by integrating Intel > RealSense SDK (RSSDK) ( > https://software.intel.com/en-us/intel-realsense-sdk). E.g. implementing > Crosswalk extensions for 3D photography, scene perception and face tracking > etc. > > As RealSense camera enables many useful scenarios, it is quite common that > multiple applications or multiple components of one application need to > share the camera simultaneously. For example, one application is using > camera for video conference, another application is using camera for > gesture control. So RSSDK, together with Intel Depth Camera Manager (DCM) ( > https://software.intel.com/en-us/articles/intel-realsense-cameras-and-dcms-overview), > support sharing RealSense camera by multiple processes on Windows. > > However, today’s Crosswalk doesn’t employ RSSDK and DCM to capture video > from RealSense cameras. It ends up with two issues. First, Crosswalk app’s > accessing to RealSense cameras will be blocked by other native apps’ using > of same camera or vice versa. Second, according to multiple processes > architecture of Crosswalk Windows, the video capture running inside browser > process (for getUserMedia API) and the camera usage in extension process > would even block each other. This limitation prohibits common RealSense use > cases, such as taking 3D photo (by extension) while previewing camera (by > gUM), tracking face (by extension) in live camera stream (by gUM) etc. > > Chromium-Crosswalk supports multiple video capture API implementations. As > following component diagram shows, on Windows, it has VideoCaptureDeviceWin > class for DirectShow API and VideoCaptureDeviceMFWin class for Media > Foundation API. The concrete classes are derived from VideoCaptureDevice > interface, capture video frame by native API and feed them to Chromium > media pipeline through VideoCaptureDevice::Client interface. The > VideoCaptureDeviceFactoryWin class is responsible for concrete > VideoCaptureDevice instance selection and creation. > > > > > > [image: VCDRSSDK.png] > > > > To support the RealSense cameras, the VideoCaptureDeviceRSWin class is > proposed to be added. It uses RSSDK and DCM to capture video frames. The > prototype shows, with VideoCaptureDeviceRSWin, the Crosswalk app is able to > share RealSense cameras with other native apps. Another prototype shows > Crosswalk app can preview the RealSense cameras in real-time by > getUserMedia API as well as accessing RSSDK middlewares in Crosswalk > extensions. All of these are essential to enable compelling RealSense > experience for Web app on Crosswalk. > > > > This feature will be behind a runtime flag, use-rs-video-capture. To > indicate Crosswalk runtime capturing video frames from RealSense cameras, > the developers specify this runtime flag when packaging app with app-tool. > At runtime, VideoCaptureDeviceFactoryWin instance tries to create and > initialize the VideoCaptureDeviceRSWin once the use-rs-video-capture flag > is set. If there are no RealSense cameras or RSSDK runtime libraries > installed on target devices, it fallbacks to normal video capture API > implementation on Windows, say Media Foundation API or DirectShow API. > > > > The VideoCaptureDeviceRSWin implementation depends on RSSDK open source > headers and library loader, named libpxc. It is also proposed to pull > libpxc into third_party of Chromium-Crosswalk. > > > > The Android implementation will be proposed once the RSSDK Android is > available. > > > > *Affected component:* Crosswalk-Chromium/media/capture/video/win > *Related feature:* https://crosswalk-project.org/jira/browse/XWALK-6028 > > *Target release:* Crosswalk-18 > *Implementation details:* > > > Host libpxc in github.com/crosswalk-project/libpxc. > > > > src/xwalk/DEPS.xwalk > > Fetch third_party/libpxc dependency when glicent sync. > > > > src/media/capture/video/win/video_capture_device_rs_win.cc (NEW) > > src/media/capture/video/win/video_capture_device_rs_win.h (NEW) > > Implement VideoCaptureDeviceRSWin. It derives from VideoCaptureDevice. It > bases on libpxc to invoke RSSDK API to access RealSense cameras. > > > > media/capture/video/video_capture_device.cc > > media/capture/video/video_capture_device.h > > Add RSSDK API type besides MEDIA_FOUNDATON and DIRECT_SHOW. > > > > media/base/media_switches.cc > > media/base/media_switches.h > > Add use-rs-video-capture flag > > > > media/capture/video/win/video_capture_device_factory_win.cc > > Recognize use-rs-video-capture flag. Create and initialize > VideoCaptureDeviceRSWin once the flag is set. Fallback to > VideoCaptureDeviceMFWin or VideoCaptureDeviceWin when there are no > RealSense cameras or RSSDK runtime libraries. > > > > media/media.gyp > > Add libpxc and video_capture_device_rs_win.[h|cc] for Windows. > > > > Thanks, > > -ningxin > > > > > > _______________________________________________ > Crosswalk-dev mailing list > Crosswalk-dev@lists.crosswalk-project.org > https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev > >
_______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
