- From: Jim Barnett <1jhbarnett@gmail.com>
- Date: Fri, 16 May 2014 19:06:07 -0400
- To: public-media-capture@w3.org
This is what I thought until someone pointed out that 'video' could cover a number of different kinds of devices (such as 3D cameras) so that 'sourceType' contains additional information. It may be worthwhile looking at this again, but 'video' and 'audio' are a pretty coarse classification. - Jim On 5/16/2014 6:54 PM, bugzilla@jessica.w3.org wrote: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25752 > > Bug ID: 25752 > Summary: sourceType is redundant as constraint > Product: WebRTC Working Group > Version: unspecified > Hardware: All > OS: All > Status: NEW > Severity: normal > Priority: P2 > Component: Media Capture and Streams > Assignee: public-media-capture@w3.org > Reporter: shijuns@microsoft.com > CC: public-media-capture@w3.org > > In the MediaStreamConstraints dictionary, the "video" and "audio" properties > already indicate whether the source should be a camera or microphone for the > specific MediaTrackConstraints. Having an "sourceType" doesn't give the UA more > meaningful instruction, meanwhile, can introduce unnecessary conflict, e.g. by > setting the sourceType to "camera" on the "audio" property. > > Also, typically we should not expect the sourceType to change while applying > new constraints on an existing MediaStreamTrack. MediaStreamTrack.kind > indicates the sourceType already. There is no clear value keeping the > sourceType as constraints in this case either. > > sourceType "none" is covered by the MediaStreamTrack.radyState, again > redundant. > > Suggest removing sourceType from the constraints list, and mapping the concept > to other attributes defined in the spec already. > -- Jim Barnett Genesys
Received on Friday, 16 May 2014 23:07:15 UTC