Issue metadata
Sign in to add a comment
|
16-bit depth capture broken in yesterday's Beta and Canary builds |
||||||||||||||||||||||
Issue description
Chrome Version :
Broken only in yesterday's releases:
63.0.3216.0 (Official Build) canary 64-bit on Windows
62.0.3202.18 (Official Build) beta (64-build) on Windows (note bellow that it works with the same version on Ubuntu).
Feature works in all releases for about one year.
Verified to work with:
- 61.0.3163.91 (Official Build) (64-bit) on Windows
- previous version of beta (as it autoupdates don't have the version now), I use it every day for development.
- Version 63.0.3213.3 (Official Build) dev (64-bit) on Linux
- Version 62.0.3202.18 (Official Build) beta (64-bit) in Linux
URLs (if applicable) : https://webrtc.github.io/samples/src/content/devices/input-output/
What steps will reproduce the problem?
(1) Plug Intel RealSense SR300 based Depth Capture Camera (e.g. Razer Stargazer, Creative Blasterx Senz3D
(2) open the page https://webrtc.github.io/samples/src/content/devices/input-output/
(3) select depth stream
What is the expected result?
It used to display depth stream.
What happens instead?
Now, green or black screen with navigator.getUserMedia error: "NotReadableError".
I'm building the latest code to debug.
,
Sep 15 2017
aleksandar.stojiljkovic@intel.com: Since it's hardware dependent, maybe you can use bisect-builds.py (http://www.chromium.org/developers/bisect-builds-py) to find the change caused the problem.
,
Sep 15 2017
,
Sep 15 2017
,
Sep 15 2017
,
Sep 18 2017
All fine with Chromium code. The change is related to difference in capture size, format and frame rate prioritization: Among other, the camera provides 640x480@30Hz YUYV, 640x480@30Hz Y16 and 640x480@60Hz Y16 video capture formats. Previously, 640x480@60Hz Y16 got picked and now 640x480@30Hz YUYV is. This one should probably be blacklisted as it doesn't contain depth capture data and renders "Not Readable Error". This is hardware specific and there is a simple workaround - supply "frameRate: 60" constraint to getUserMedia. Because of this, reducing the priority.
,
Sep 18 2017
aleksandar.stojiljkovic@i Thanks for the issue. Tried this issue on Windows 7 on the latest canary 63.0.3218.0 using Logitech HD Pro Webcam and could observe no issues. No green or black screen with navigator.getUserMedia error: "NotReadableError" is observed. Adding 'TE-Hardware-Dependency' and 'TE-NeedsTriageFromMTV' labels as we don't have the above mentioned cameras to check this issue. Requesting MTV team to please look into this issue and help in further triaging. Thank you.
,
Jan 30 2018
The proper way to separate depth stream from others is using videoKind constraint - Issue 616098. Accessing now through hacky constrains workarounds without using mediacapture-depth stream extension is possible [1] and no need to change the Chromium implementation. [1] https://github.com/01org/depth-camera-web-demo/blob/311595ba29a802444884dac5b41f3dcd389c762d/depth-camera.js#L28 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by aleksand...@intel.com
, Sep 15 2017