Implement MediaStreamTrack::getCapabilities() and MediaTrackCapabilities
Categories
(Core :: WebRTC: Audio/Video, enhancement, P2)
Tracking
()
backlog | webrtc/webaudio+ |
People
(Reporter: mathieu.hofman.dev+mozilla, Assigned: dbaker)
References
(Blocks 3 open bugs)
Details
(4 keywords)
Attachments
(3 files)
Reporter | ||
Comment 1•9 years ago
|
||
Updated•9 years ago
|
Updated•9 years ago
|
Updated•9 years ago
|
Updated•9 years ago
|
Comment 2•7 years ago
|
||
Comment 3•6 years ago
|
||
Any chance this feature will come in near future?
Updated•5 years ago
|
Comment 4•5 years ago
|
||
Reminder to check the privacy.resistFingerprinting
pref as well as bug 1528042 when implementing this feature.
Comment 5•3 years ago
|
||
Any chance this feature will come in near future?
It's been 2 years. Any news?
Comment 6•2 years ago
|
||
This is currently breaking Facebook Messenger Calls, see the linked WebCompat bug. I've already reached out to them to see if they can fix it, but I'm setting a webcompat-priority here for now so that this is on our radar.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•1 year ago
|
Updated•8 months ago
|
Comment 8•6 months ago
|
||
Not sure how QA can test this. Should I run MediaStreamTrack::getCapabilities() in the Console of the browser, exact string? Or is there another place to run this?
Comment 9•5 months ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:jib, since the bug has recent activity, could you have a look please?
For more information, please visit BugBot documentation.
Comment 10•5 months ago
|
||
This is covered by automated WPT tests so there should be no need for QA to test this. Except maybe to verify facingMode is present on mobile devices perhaps?
That said, you can type the following into web console to test it:
(await navigator.mediaDevices.getUserMedia({video:true, audio:true})).getTracks().map(t => t.getCapabilities())
Comment 11•5 months ago
|
||
This was highlighted as a Web Compat risk recently, which seems fair.
Our earlier (media team) assessment of it as low priority is based on its usefulness (it's not super useful at all imho).
But looking at websites that don't test with Firefox, a different standard is needed. Some websites appear to be in the habit of using this pattern:
const amIOnMobile = !!mst.getCapabilities().facingMode;
...which is easily fixed by using this instead:
const amIOnMobile = !!mst.getSettings().facingMode;
Simply testing with Firefox should help address this, but if they're not doing so this advice doesn't help, and we should up-prioritize a fix, despite its overall low value add otherwise.
Updated•4 months ago
|
Assignee | ||
Comment 12•3 months ago
|
||
Assignee | ||
Comment 13•3 months ago
|
||
Depends on D219117
Assignee | ||
Comment 14•3 months ago
|
||
Depends on D220338
Updated•3 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Comment 15•2 months ago
|
||
Comment 16•2 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/40da10b9a99d
https://hg.mozilla.org/mozilla-central/rev/3b73074ef93b
https://hg.mozilla.org/mozilla-central/rev/a086565fa15a
Assignee | ||
Comment 17•2 months ago
|
||
Release Note Request (optional, but appreciated)
[Why is this notable]: WebRTC applications will now be able to query the capabilities of the live media track to gather capabilities. This does not implement bug 1213422 and is only for the live track.
[Affects Firefox for Android]: Yes
[Suggested wording]: The getCapabilities method allows applications to gather the media capabilities supported for the live MediaStreamTrack.
[Links (documentation, blog post, etc)]: https://www.w3.org/TR/mediacapture-streams/#dom-mediastreamtrack-getcapabilities
Updated•29 days ago
|
Description
•