Re: Fwd: Media Capture and Streams Last Call review

Bill,

Thanks for supplying this feedback.

After having had a chance to review the updated spec, it seems to me that
the spec is also lacking a convenient way to determine more basic facets of
devices like sample rate, etc.  There is an *inconvenient* way, which is to
enumerate all devices, then obtain a MediaStream for each deviceId in the
list and examine its settings.

Perhaps a concrete proposal to the RTC group might look like this (and I
think a specific proposal is highly recommended here):

1. Have each MediaDeviceInfo returned by the enumerateDevices() call
include a MediaStreamSettings object describing the device. This doesn't
allow any further fingerprinting than the existing API, because one can
always constrain getUserMedia() to return a MediaStream for a given
deviceID and then look at the MediaStream's MediaStreamSettings.

2. Expand both MediaStreamSettings and MediaStreamConstraints to include
channel count, configuration, output type, latency and output capabilities.

Can you or others in the group offer alternatives or improvements to the
above proposal?

Best
...Joe


On Thu, Apr 16, 2015 at 2:31 AM, Hofmann, Bill <bill.hofmann@dolby.com>
wrote:

>  So, speaking for myself, my feedback is that the MediaDeviceInfo result (
> http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/#idl-def-MediaDeviceInfo)
> lacks information that is typically available in the underlying OS
> implementations that we think would be very helpful for implementations:
>
>
>
> ·         Channel count and configuration (Mono, Stereo, 5.1, 7.1, etc…)
>
> ·         Physical Output (Headphone, Speaker, HDMI, …)
>
> ·         Latency (this matters a lot for gaming)
>
> ·         Output capabilities (bitstream passthrough vs PCM – relevant in
> digital media adapter cases (Chromecast, etc))
>
>
>
> It is perhaps sufficient from a user interface point of view to have a
> string to display, but for a program to be able to either adapt to the user
> selection or to guide the user selection, these are pretty important
> characteristics, at least in some use cases.  Many if not most of the host
> OSes that user agents run on expose these sorts of output device
> characteristics.
>
>
>
> Knowing relevant info on the input side is also relevant.
>
>
>
> -Bill
>
>
>
> *From:* Chris Wilson [mailto:cwilso@google.com]
> *Sent:* Wednesday, April 15, 2015 7:40 AM
> *To:* Joseph Berkovitz
> *Cc:* Audio Working Group
> *Subject:* Re: Fwd: Media Capture and Streams Last Call review
>
>
>
> Oops, ignore my crossposting from this morning!  Joe's much more eloquent
> introduction was what should have been (and was) said.
>
> On Apr 14, 2015 11:30 PM, "Joe Berkovitz" <joe@noteflight.com> wrote:
>
> Hi Group,
>
>
>
> This solicitation for feedback is a perfect moment to address once again
> the problems with audio device identification and access that we had
> discussed at the last F2F. I have not yet had a chance to look at this
> latest draft (I'm at a trade show this week), but if you are involved in
> this issue, could you please examine it as some of the content may have
> changed. Please post to the group this week if you have any additional
> observations on this subject after reading the draft, and we can discuss on
> tomorrow's conference call.
>
>
>
> ...Joe
>
>
>
> ---------- Forwarded message ----------
> From: *Stefan Håkansson LK* <stefan.lk.hakansson@ericsson.com>
> Date: Wed, Apr 15, 2015 at 7:31 AM
> Subject: Media Capture and Streams Last Call review
> To: "rubys@intertwingly.net" <rubys@intertwingly.net>, "
> Paul.Cotton@microsoft.com" <Paul.Cotton@microsoft.com>, "mjs@apple.com" <
> mjs@apple.com>, "chaals@yandex-team.ru" <chaals@yandex-team.ru>, "
> art.barstow@gmail.com" <art.barstow@gmail.com>, "joe@noteflight.com" <
> joe@noteflight.com>, "matthew.paradis@bbc.co.uk" <
> matthew.paradis@bbc.co.uk>, "hillbrad@fb.com" <hillbrad@fb.com>, "
> dveditz@mozilla.com" <dveditz@mozilla.com>, "w3c@adambarth.com" <
> w3c@adambarth.com>, "Virginie.GALINDO@gemalto.com" <
> Virginie.GALINDO@gemalto.com>, "yosuke@funahashi.cc" <yosuke@funahashi.cc>,
> "giuseppep@opera.com" <giuseppep@opera.com>, "
> mark_vickers@cable.comcast.com" <mark_vickers@cable.comcast.com>, "
> runnegar@isoc.org" <runnegar@isoc.org>, "tjwhalen@google.com" <
> tjwhalen@google.com>, "daniel.appelquist@telefonica.com" <
> daniel.appelquist@telefonica.com>, "peter.linss@hp.com" <
> peter.linss@hp.com>, "janina@rednote.net" <janina@rednote.net>
> Cc: "Chairs@w3.org Chairs" <Chairs@w3.org>
>
>
> The WebRTC and Device APIs Working Groups request feedback on the Last
> Call Working Draft of Media Capture and Streams, a JavaScript API that
> enables access to cameras and microphones from Web browsers as well as
> control of the use of the data generated (e.g. rendering what a camera
> captures in a html video element):
> http://www.w3.org/TR/2015/WD-mediacapture-streams-20150414/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_2015_WD-2Dmediacapture-2Dstreams-2D20150414_&d=AwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=qzKCNHFKJMzZBJ52at1DkA-_8TPxvcij-zS_VXs8c5A&m=PiflLuM3beNCS--ttpIt8UwALAoEwAf9VIZE85iJw6c&s=sfsZCzZoSM7S5DC1drdCbdI-pmtuCci4S5cv37zmIic&e=>
>
> The groups have identified the following other W3C Working Groups as
> likely sources of feedback:
>
> - HTML Working Group, especially the HTML Media Task Force, as our API
> extends the HTMLMediaElement interface and defines a new type of media
> input via MediaStream
>
> - WebApps Working Group, especially on the overall usage of Web IDL and
> the definition of error handling
> Audio Working Group, as the Web Audio API builds upon the MediaStream
> interface
>
> - WAI Protocol and Formats Working Group, especially on the impact of
> the user consent dialog and the applicability of the indicators of
> device usage in assistive tools
>
> - Web and TV Interest Group, as the manipulation of media input can be
> relevant to some of their use cases (e.g. glass to glass)
>
> - Web App Security Working Group, especially on our links between
> secured origins and persistent permissions, and our current policy with
> regard to handling access to this "powerful feature"
>
> - Web Security Interest Group, especially on our security considerations
> Privacy Interest Group, as access to camera and microphone has strong
> privacy implications
>
> - Technical Architecture Group, for an overall review of the API,
> especially the introduction of the concept of a IANA registry-based
> constraints system, the use of promises, and our handling of persistent
> permissions
>
> We naturally also welcome feedback from any other reviewers.
>
> The end of last call review for this specification is set to May 15
> 2015; should that deadline prove difficult to meet, please get in touch
> so that we can determine a new deadline for your group.
>
> As indicated in the document, comments should be sent to the
> public-media-capture@w3.org mailing list.
>
> Thanks,
>
> Frederick Hirsch, Device APIs Working Group Chair,
> Harald Alvestrand and Stefan Hakansson, WebRTC Working Group Chairs and
> Media Capture Task Force Chairs
>
>
>
>
>
> --
>
> .            .       .    .  . ...Joe
>
>
>
> *Joe Berkovitz*
>
> President
>
>
>
> *Noteflight LLC*
>
> Boston, Mass.
>
> phone: +1 978 314 6271
>
> www.noteflight.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.noteflight.com&d=AwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=qzKCNHFKJMzZBJ52at1DkA-_8TPxvcij-zS_VXs8c5A&m=PiflLuM3beNCS--ttpIt8UwALAoEwAf9VIZE85iJw6c&s=jbtvviX_pOtKvdia38O5v3FUP4LR2-J9kds0QfSE76Q&e=>
>
> "Your music, everywhere"
>



-- 
.            .       .    .  . ...Joe

*Joe Berkovitz*
President

*Noteflight LLC*
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"