25769 2014-05-18 13:41:29 +0000 Need extensibility for media types that are not audio or video 2014-09-11 14:39:05 +0000 1 1 1 Unclassified WebRTC Working Group Media Capture and Streams unspecified PC All RESOLVED FIXED P2 normal --- 25752 1 fluffy public-media-capture adam.bergkvist harald public-media-capture stefan.lk.hakansson oldest_to_newest 106264 0 fluffy 2014-05-18 13:41:29 +0000 The spec needs to be clearly extensible for new media types (the range or depth camera use case is one example of this). I think this means we need a way get all the tracks, not just the audio and video ones [ actually , I seem to recall we agreed long ago to add that]. We also need to be be clear how to extend MST.kind, MediaDeviceKind, and SourceTypeEnum. The way SourceTypeEnum is defined my have problems extending due to limitations of WebIDL so may need to change the way it is defined. 108564 1 harald 2014-07-01 08:24:43 +0000 MST.kind seems easy to extend (it's the same string as the media type). MediaDeviceInfo.kind currently has "audioinput", "audiooutput" and "videoinput". Since MediaDeviceInfo.kind is only returned from the platform, never passed to it, we do not have the problem we had with facingMode of the platform throwing on extensions it does not understand. sourceTypeEnum's future is discussed in bug 25752. Adding that as a dependency for this one. 108751 2 stefan.lk.hakansson 2014-07-07 13:03:00 +0000 There is now a way to get all tracks (regardless of kind) of a MediaStream: getTracks. Concluding the sourceType discussion remains though. 110458 3 adam.bergkvist 2014-08-22 08:57:15 +0000 (In reply to Stefan Hakansson LK from comment #2) > Concluding the sourceType discussion remains though. That's done and sourceTypes is removed. How does that affect this bug? 111386 4 fluffy 2014-09-11 14:39:05 +0000 There is now a method to get all the track and from each track you find get it's kind so I believe this bug has "fixed"