W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > December 2019

Re: [mediacapture-main] Clarify getUserMedia({audio:{deviceId:{exact:<audiooutput_device>}}}) in this specification mandates capability to capture of audio output device - not exclusively microphone input device (#650)

From: guidou via GitHub <sysbot+gh@w3.org>
Date: Tue, 10 Dec 2019 07:12:49 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-563898676-1575961968-sysbot+gh@w3.org>
> @guidou
> 
> > Perhaps an extra clarification can be added there to indicate that "video or audio input" refers to devices marked as videoinput or audioinput in the results provided by enumerateDevices. The absence of that extra text so far has not led to any inconsistent behavior across various browsers. Feel free to send a PR for review with text along those lines, though.
> 
> Your acknowledgment that the current language is capable of more than one interpretation re `"audiooutput"` and "headphones" meaning capturing audio is part of this specification. 

I have no idea how you can conclude that the current language allows interpreting "audiooutput" devices as audio input devices. No implementer does and this is the first time that I see this interpretation.

> Will not be filing that PR. From perspective here the language indicates capture of audio output is specified, at least it is not clear that that capability is not intended. 

Where is it said that capture of audio output devices is specified? 
The spec is pretty clear saying getUserMedia operates on input devices.


> The prerogative here is to use that language to capture audio. If you bbelieve there is room to close that interpretation, then clarify the specification yourself, as that what this issue is asking for. Would file a PR to make it clear the specification _does_ include language already to indicate capturing audio output, not that it does not.

I don't think any extra language is needed. I'm just saying that an extra clarification saying that audio input refers to devices marked as "audioinput" and video input refers to devices marked as "videoinput" would not be out of place, but it's pretty obvious that "audioinput" refers to audio input and "audiooutput" refers to audio output.


> > The script there is broken for Chromium because it assumes "audiooutput" devices can be captured by getUserMedia(), which is not the case in Chromium or any other browser
> 
> At *nix the code works as expected.

No, it doesn't since it expects getUserMedia to capture from devices marked as "audiooutput".
It works in Firefox for Linux due to implementation-specific  characteristics such as how some exposed devices are named. If those strings were localized in Firefox It might not work in all locales, for example (I don't know if those strings are localized or not).


> 
> Have not used *indows in many years and have not used Mac at all.
> 
> Therefore, it is reasonable to conclude that *indows and Mac also provide such functionality. Evidently not. They should, per this specification, is the perspective here.
> 
> > Feel free to file a feature request for it at crbug.com
> 
> Already did. You closed the issue https://bugs.chromium.org/p/chromium/issues/detail?id=1013881 as `WontFix`.
> 
That was filed as a bug, which it is not. Therefore it cannot be "fixed". 
Feel free to file a feature request.

> > What you have here is a feature request for Chromium to expose "Monitor of ..." devices the way Firefox does so that they can be used by tt(). I think that's a valid feature request for Chromium, since it does not support it, but it does not need any adjustment to the spec
> 
> Kindly re-open the above linked Chromium bug.
File a new feature request entry at crbug.com. 

> and answer this question: Why should that functionality _not_ be available to users? 
I don't think anyone has an obligation to explain why something doesn't exist, in particular something probably no one had requested until now.

> Disregard the specification or not, the functionality is what matters, implementers do whatever they want anyway, irrespective of any specification, whether by omission, deliberate indifference to any spec, or by way of their arbitrary, undocumented "experiments".

My experience has been that implementers try to implement the spec and I would say they have succeeded for the most part since, although not perfect, there is large degree of interoperability across browsers. Things are sure to fail when you expect things that are not in the spec to work, such as having getUserMedia() capture from devices marked as "audiooutput" or having implementation specific details not covered by the spec to be the same in all implementations.


-- 
GitHub Notification of comment by guidou
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/650#issuecomment-563898676 using your GitHub account
Received on Tuesday, 10 December 2019 07:12:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:34 UTC