Now we have several ways of "generalized" desktop capture:
1. chooseDesktopMedia could launch a picker window, and let user to choose a source to capture, where the source could be "screen", "window" or a chrome "tab".

2. getUserMedia with constraint {video:{chromeMediaSource:screen}, audio:{chromeMediaSource:system}} to get screen capture stream.

3. tabCapture would get current tab stream.

Some defects:

1. The functionality partially overlaps, and so does the code paths. chooseDesktopMedia and getUserMedia use the same MediaStreamType[1]. It brings difficulty to tell apart which API initiates the request. For example, in [2], we used the characteristic whether an "id" was specified in the constraint to tell whether the request is from getUserMedia or chooseDesktopMedia, which looks confusing.

2. In [3], we hardcoded the criterion to unmute source audio during tab sharing for chooseDesktopMedia. This way is not generalizable, as we want to make mute/unmute be controlled by a constraint parameter.

Suggestions:
1. Add enum in MediaStreamType for getUserMedia({video:screen}...) use, so it can be distinguished from chooseDesktopMedia call.

2. Make mute/unmute information in device_id. We can prepare device_id in MediaStreamManager, where we can access MediaStreamType and constraint parameters. Let WebContentsAudioInputStream behave according to device_id.
Concretely, the tab stream source is described by device_id like "webcontents://<processId>:<frameId>", we can extend it to something like "webcontents://<processId>:<frameId>?mute_source=true".

[1] https://cs.chromium.org/chromium/src/content/public/common/media_stream_request.h?sq=package:chromium&rcl=1468927100&l=24

[2] https://cs.chromium.org/chromium/src/chrome/browser/media/desktop_capture_access_handler.cc?sq=package:chromium&l=357

[3] https://cs.chromium.org/chromium/src/content/browser/renderer_host/media/audio_input_renderer_host.cc?sq=package:chromium&rcl=1468927100&l=438