Re: [mediacapture-screen-share] Either fully support or remove audio capture entirely: "MAY" re audio capture is ambiguous (#140)

Consider playing a video at `mpv`, `getDisplayMedia({video: true, audio: true})` executed _after_ the video is already playing, video is output to the application screen and audio is output to headphones if plugged in or speakers. The expected result is for both video (screen) and audio to be captured. The platform, *nix with PulseAudio managing audio devices and output, supports audio capture. 

The fact that audio is being output at the system _before_ `getDisplayMedia({video: true, audio: true})` nullifies the criteria 

> If the user agent knows no audio will be shared for the lifetime of the stream it MUST NOT include an audio track in the resulting stream.

which appears to be impossible to determine - how does the user agent "know" anything about the entire lifetime of the stream, particularly when  the constraint `{audio: true}` is included as constraint to the function? Unless the constraint is ignored and inapplicable in any case as determined by the user agent, not the technical capabilities of of the platform?

Why would audio _not_ be captured in the case of a local media player application playing a video with audio track of the resource being output, if in fact the `{audio: true}` constraint is actually being processed through an algorithm by the user agent (to comport with the implementation of the specification) to verify that the application window being captured, and as in this case, system audio to headphones or speakers, is actually outputting audio, and because the system supports capturing the device, MUST be captured because the physical user granted the user agent permission to do so?

"Who" is responsible for _not_ capturing audio when the system supports such capture; the specification, the implementation?

-- 
GitHub Notification of comment by guest271314
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/140#issuecomment-626205541 using your GitHub account

Received on Saturday, 9 May 2020 16:57:22 UTC