Reading track.getCapabilities() should not need to wait right after track opening |
|||
Issue descriptionMediaStreamTrack.getCapabilities() does not have the image capture-related capabilities immediately after getUserMedia() returns the MediaStreamTrack, which forces uses to introduce a variable delay such as e.g. the one in [1] This should not be needed, since gUM() is asynchronous already. [1] https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/imagecapture/MediaStreamTrack-getCapabilities.html?q=getcapabilities+html&sq=package:chromium&dr=C&l=36
,
Apr 29 2017
It should be noted this also affects MediaStreamTrack.getSettings(), that also requires a delay before correct results are returned. Proposed solution of making getUserMedia not resolve until image capture-related stuff is ready should fix this case as well.
,
May 11 2017
To be clear, code snippet currently logs an empty object in Chrome 60.0.3092.0:
video.srcObject = await navigator.mediaDevices.getUserMedia({ video : true });
video.onplay = function() {
console.log(track.getCapabilities());
})
,
May 11 2017
,
May 14 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||
►
Sign in to add a comment |
|||
Comment 1 by mcasas@chromium.org
, Apr 14 2017Status: Available (was: Unconfirmed)
Summary: Reading track.getCapabilities() should not need to wait right after track opening (was: track.getCapabilities() should not need to wait right after track opening)