Image Capture: MediaStreamTrack::getCapabilities()

Image Capture: MediaStreamTrack::getCapabilities() 

This CL adds MediaTrackCapabilities.idl and 
MediaStreamTrack::getCapabilities(). The latter function is wired 
to grab the capabilities from image capture, since these are 
the only ones available ATM.  These capabilities should only 
be collected for Video tracks from devices (i.e. not for 
tab/window/cast/remote etc).

MediaStreamTrack.getCapabilities() is synchronous, whereas
image_capture mojom::getPhotoCapabities() is not -- the former 
probably doesn't make a lot of sense Spec-wise but, regardless,
I don't think is a good idea to make the Web thread wait for 
these capabilities to be collected, so what this CL does is
to trigger such collection upon MediaStreamTrack ctor, without
waiting for this process to be finished. (IOW I tried alternatives 
and were much worse).

Added LayoutTests for starters.

This bug is part of a transition from 
 ImageCapture.getPhotoCapabilities() to MediaStreamTrack.getCapabilities() 
but, since Image Capture is already in Origin Trials, I'm 
planning on landing the new infra in parallel, then send a PSA 
and switch over (that's why there's a few TODOs) in the code.

BUG=700607
Incidentally, it improves the state of 
external/wpt/mediacapture-streams/MediaStreamTrack-init.https.html
by allowing the test-for-getCapabilities() to PASS.

Review-Url: https://codereview.chromium.org/2747573002
Cr-Commit-Position: refs/heads/master@{#457150}
Committed: https://chromium.googlesource.com/chromium/src/+/30a67395e8cfccfd5954b9244440a7906d065563

[mcasas, 2017-03-11 17:20:19]

Description was changed from

==========
Image Capture: MediaStreamTrack::getCapabilities() [wip]

Added MediaTrackCapabilities.idl and MediaStreamTrack::getCapabilities()
under image_capture/ (since I see no plans to land in mediastream/)

(has https://codereview.chromium.org/2741803007/ patched in
but doesn't need it)


BUG=700607
==========

to

==========
Image Capture: MediaStreamTrack::getCapabilities() [wip]

Added MediaTrackCapabilities.idl and MediaStreamTrack::getCapabilities()
under image_capture/ (since I see no plans to land in mediastream/)

BUG=700607
==========

[mcasas, 2017-03-11 17:20:44]

Patchset #1 (id:1) has been deleted

[mcasas, 2017-03-14 16:44:31]

Description was changed from

==========
Image Capture: MediaStreamTrack::getCapabilities() [wip]

Added MediaTrackCapabilities.idl and MediaStreamTrack::getCapabilities()
under image_capture/ (since I see no plans to land in mediastream/)

BUG=700607
==========

to

==========
Image Capture: MediaStreamTrack::getCapabilities() [wip]

This CL adds MediaTrackCapabilities.idl and 
MediaStreamTrack::getCapabilities(). The latter function is wired 
to grab the capabilities from image capture, since these are 
the only ones available ATM.  These capabilities should only 
be collected for Video tracks from devices (i.e. not for 
tab/window/cast/remote etc).

MediaStreamTrack.getCapabilities() is synchronous, whereas
image_capture mojom::getPhotoCapabities() is not -- the former 
probably doesn't make a lot of sense Spec-wise but, regardless,
I don't think is a good idea to make the Web thread wait for 
these capabilities to be collected, so what this CL does is
to trigger such collection upon MediaStreamTrack ctor, without
waiting for this process to be finished. (IOW I tried alternatives 
and were much worse).

Added LayoutTests for starters.

This bug is part of a transition from 
 ImageCapture.getPhotoCapabilities() to MediaStreamTrack.getCapabilities() 
but, since Image Capture is already in Origin Trials, I'm 
planning on landing the new infra in parallel, then send a PSA 
and switch over (that's why there's a few TODOs) in the code.

BUG=700607
==========

[mcasas, 2017-03-14 16:44:47]

Patchset #1 (id:20001) has been deleted

[mcasas, 2017-03-14 16:45:02]

Patchset #1 (id:40001) has been deleted

[mcasas, 2017-03-14 16:45:10]

Patchset #1 (id:60001) has been deleted

[mcasas, 2017-03-14 17:47:53]

Patchset #1 (id:80001) has been deleted

[mcasas, 2017-03-14 18:38:20]

Patchset #1 (id:100001) has been deleted

[mcasas, 2017-03-14 18:39:10]

mcasas@chromium.org changed reviewers:
+ guidou@chromium.org, reillyg@chromium.org

[mcasas, 2017-03-14 18:39:10]

reillyg@: PTAL at the imagecapture/ parts

guidou@ PTAL the mediastream/ parts

[mcasas, 2017-03-14 18:39:21]

Description was changed from

==========
Image Capture: MediaStreamTrack::getCapabilities() [wip]

This CL adds MediaTrackCapabilities.idl and 
MediaStreamTrack::getCapabilities(). The latter function is wired 
to grab the capabilities from image capture, since these are 
the only ones available ATM.  These capabilities should only 
be collected for Video tracks from devices (i.e. not for 
tab/window/cast/remote etc).

MediaStreamTrack.getCapabilities() is synchronous, whereas
image_capture mojom::getPhotoCapabities() is not -- the former 
probably doesn't make a lot of sense Spec-wise but, regardless,
I don't think is a good idea to make the Web thread wait for 
these capabilities to be collected, so what this CL does is
to trigger such collection upon MediaStreamTrack ctor, without
waiting for this process to be finished. (IOW I tried alternatives 
and were much worse).

Added LayoutTests for starters.

This bug is part of a transition from 
 ImageCapture.getPhotoCapabilities() to MediaStreamTrack.getCapabilities() 
but, since Image Capture is already in Origin Trials, I'm 
planning on landing the new infra in parallel, then send a PSA 
and switch over (that's why there's a few TODOs) in the code.

BUG=700607
==========

to

==========
Image Capture: MediaStreamTrack::getCapabilities() 

This CL adds MediaTrackCapabilities.idl and 
MediaStreamTrack::getCapabilities(). The latter function is wired 
to grab the capabilities from image capture, since these are 
the only ones available ATM.  These capabilities should only 
be collected for Video tracks from devices (i.e. not for 
tab/window/cast/remote etc).

MediaStreamTrack.getCapabilities() is synchronous, whereas
image_capture mojom::getPhotoCapabities() is not -- the former 
probably doesn't make a lot of sense Spec-wise but, regardless,
I don't think is a good idea to make the Web thread wait for 
these capabilities to be collected, so what this CL does is
to trigger such collection upon MediaStreamTrack ctor, without
waiting for this process to be finished. (IOW I tried alternatives 
and were much worse).

Added LayoutTests for starters.

This bug is part of a transition from 
 ImageCapture.getPhotoCapabilities() to MediaStreamTrack.getCapabilities() 
but, since Image Capture is already in Origin Trials, I'm 
planning on landing the new infra in parallel, then send a PSA 
and switch over (that's why there's a few TODOs) in the code.

BUG=700607
==========

[haraken, 2017-03-14 19:56:37]

haraken@chromium.org changed reviewers:
+ haraken@chromium.org

[haraken, 2017-03-14 19:56:37]

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/imagecapture/ImageCapture.cpp (right):

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/imagecapture/ImageCapture.cpp:323:
caps->setIso(MediaSettingsRange::create(std::move(capabilities->iso)));

Why do we need to create a new MediaSettingsRange object?

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/imagecapture/ImageCapture.cpp:386:
m_capabilities.setWhiteBalanceMode(WTF::Vector<WTF::String>(

Why does the mode need to be a vector? It has only one entry?

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/imagecapture/ImageCapture.cpp:387:
{WebString::fromASCII(toString(capabilities->white_balance_mode))}));

Can we simply return WebString from toString()?

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/mediastream/MediaStreamTrack.cpp (right):

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/mediastream/MediaStreamTrack.cpp:75:
NonThrowableExceptionState exceptionState;

How is it guaranteed that the following create doesn't throw any exception?

[Reilly Grant (use Gerrit), 2017-03-14 21:38:57]

lgtm with nits

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/imagecapture/MediaStreamTrack-getCapabilities.html
(right):

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/imagecapture/MediaStreamTrack-getCapabilities.html:10:
// returns something.  (Other tests go deeper).
No parens.

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/imagecapture/MediaStreamTrack-getCapabilities.html:11:
async_test(function(test) {
Why not a synchronous test?

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/imagecapture/ImageCapture.cpp (right):

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/imagecapture/ImageCapture.cpp:61: std::string
toString(media::mojom::blink::MeteringMode value) {
Return String so you don't need to do a conversion below.

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/mediastream/MediaStreamTrack.cpp (right):

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/mediastream/MediaStreamTrack.cpp:72:
DCHECK(!m_imageCapture);
It seems odd to do this check in a constructor.

[mcasas, 2017-03-14 21:54:19]

Description was changed from

==========
Image Capture: MediaStreamTrack::getCapabilities() 

This CL adds MediaTrackCapabilities.idl and 
MediaStreamTrack::getCapabilities(). The latter function is wired 
to grab the capabilities from image capture, since these are 
the only ones available ATM.  These capabilities should only 
be collected for Video tracks from devices (i.e. not for 
tab/window/cast/remote etc).

MediaStreamTrack.getCapabilities() is synchronous, whereas
image_capture mojom::getPhotoCapabities() is not -- the former 
probably doesn't make a lot of sense Spec-wise but, regardless,
I don't think is a good idea to make the Web thread wait for 
these capabilities to be collected, so what this CL does is
to trigger such collection upon MediaStreamTrack ctor, without
waiting for this process to be finished. (IOW I tried alternatives 
and were much worse).

Added LayoutTests for starters.

This bug is part of a transition from 
 ImageCapture.getPhotoCapabilities() to MediaStreamTrack.getCapabilities() 
but, since Image Capture is already in Origin Trials, I'm 
planning on landing the new infra in parallel, then send a PSA 
and switch over (that's why there's a few TODOs) in the code.

BUG=700607
==========

to

==========
Image Capture: MediaStreamTrack::getCapabilities() 

This CL adds MediaTrackCapabilities.idl and 
MediaStreamTrack::getCapabilities(). The latter function is wired 
to grab the capabilities from image capture, since these are 
the only ones available ATM.  These capabilities should only 
be collected for Video tracks from devices (i.e. not for 
tab/window/cast/remote etc).

MediaStreamTrack.getCapabilities() is synchronous, whereas
image_capture mojom::getPhotoCapabities() is not -- the former 
probably doesn't make a lot of sense Spec-wise but, regardless,
I don't think is a good idea to make the Web thread wait for 
these capabilities to be collected, so what this CL does is
to trigger such collection upon MediaStreamTrack ctor, without
waiting for this process to be finished. (IOW I tried alternatives 
and were much worse).

Added LayoutTests for starters.

This bug is part of a transition from 
 ImageCapture.getPhotoCapabilities() to MediaStreamTrack.getCapabilities() 
but, since Image Capture is already in Origin Trials, I'm 
planning on landing the new infra in parallel, then send a PSA 
and switch over (that's why there's a few TODOs) in the code.

BUG=700607

Incidentally, it improves the state of 
external/wpt/mediacapture-streams/MediaStreamTrack-init.https.html
by allowing the test-for-getCapabilities() to PASS.
==========

[mcasas, 2017-03-14 22:16:46]

Patchset #2 (id:140001) has been deleted

[mcasas, 2017-03-14 22:21:27]

Patchset #2 (id:160001) has been deleted

[mcasas, 2017-03-14 22:28:02]

haraken@ PTAL

(guidou@ still ptal)

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Lay...
File
third_party/WebKit/LayoutTests/fast/imagecapture/MediaStreamTrack-getCapabilities.html
(right):

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/imagecapture/MediaStreamTrack-getCapabilities.html:10:
// returns something.  (Other tests go deeper).
On 2017/03/14 21:38:57, Reilly Grant wrote:
> No parens.

Done.

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/fast/imagecapture/MediaStreamTrack-getCapabilities.html:11:
async_test(function(test) {
On 2017/03/14 21:38:57, Reilly Grant wrote:
> Why not a synchronous test?

No reason, removed.

(Actually it was so because originally I used getUserMedia(),
which uses a callback, but I'm migrating all such uses
to canvas.captureStream() which is more upstream-able).

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/imagecapture/ImageCapture.cpp (right):

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/imagecapture/ImageCapture.cpp:61: std::string
toString(media::mojom::blink::MeteringMode value) {
On 2017/03/14 21:38:57, Reilly Grant wrote:
> Return String so you don't need to do a conversion below.

haraken@ recommended that too, done.

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/imagecapture/ImageCapture.cpp:323:
caps->setIso(MediaSettingsRange::create(std::move(capabilities->iso)));
On 2017/03/14 19:56:37, haraken wrote:
> 
> Why do we need to create a new MediaSettingsRange object?

Indeed; but StructTraits<> can't map a MediaSettingsRange
to a media::mojom::Range because the first one is GarbageCollected;
added a TODO for it). 

This ::create() method is a conveniency added in this CL to
produce better, yet not perfect, code.

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/imagecapture/ImageCapture.cpp:386:
m_capabilities.setWhiteBalanceMode(WTF::Vector<WTF::String>(
On 2017/03/14 19:56:37, haraken wrote:
> 
> Why does the mode need to be a vector? It has only one entry?

MediaTrackCapabilities.idl specifies these members as
sequence<DOMString>, so I need a vector here.

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/imagecapture/ImageCapture.cpp:387:
{WebString::fromASCII(toString(capabilities->white_balance_mode))}));
On 2017/03/14 19:56:37, haraken wrote:
> 
> Can we simply return WebString from toString()?

Done.

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/mediastream/MediaStreamTrack.cpp (right):

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/mediastream/MediaStreamTrack.cpp:72:
DCHECK(!m_imageCapture);
On 2017/03/14 21:38:57, Reilly Grant wrote:
> It seems odd to do this check in a constructor.

Done.

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/mediastream/MediaStreamTrack.cpp:75:
NonThrowableExceptionState exceptionState;
On 2017/03/14 19:56:37, haraken wrote:
> 
> How is it guaranteed that the following create doesn't throw any exception?

The only reason ImageCapture::create() throws is if the
track passed (|this|) is not of video type, which in this case
is guaranteed, hence no need to throw.  I'll add a comment.

[mcasas, 2017-03-14 23:28:01]

Patchset #2 (id:180001) has been deleted

[haraken, 2017-03-15 08:43:09]

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/imagecapture/ImageCapture.cpp (right):

https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/imagecapture/ImageCapture.cpp:323:
caps->setIso(MediaSettingsRange::create(std::move(capabilities->iso)));
On 2017/03/14 22:28:01, mcasas wrote:
> On 2017/03/14 19:56:37, haraken wrote:
> > 
> > Why do we need to create a new MediaSettingsRange object?
> 
> Indeed; but StructTraits<> can't map a MediaSettingsRange
> to a media::mojom::Range because the first one is GarbageCollected;
> added a TODO for it). 
> 
> This ::create() method is a conveniency added in this CL to
> produce better, yet not perfect, code.

Maybe would it be an option to define a struct and make MediaSettingsRange hold
the struct? Then you can simply map the struct to media::mojom::Range.

It's not really a good idea to create a lot of GarbageCollected objects.

[haraken, 2017-03-15 16:08:49]

On 2017/03/15 08:43:09, haraken wrote:
>
https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/modules/imagecapture/ImageCapture.cpp (right):
> 
>
https://codereview.chromium.org/2747573002/diff/120001/third_party/WebKit/Sou...
> third_party/WebKit/Source/modules/imagecapture/ImageCapture.cpp:323:
> caps->setIso(MediaSettingsRange::create(std::move(capabilities->iso)));
> On 2017/03/14 22:28:01, mcasas wrote:
> > On 2017/03/14 19:56:37, haraken wrote:
> > > 
> > > Why do we need to create a new MediaSettingsRange object?
> > 
> > Indeed; but StructTraits<> can't map a MediaSettingsRange
> > to a media::mojom::Range because the first one is GarbageCollected;
> > added a TODO for it). 
> > 
> > This ::create() method is a conveniency added in this CL to
> > produce better, yet not perfect, code.
> 
> Maybe would it be an option to define a struct and make MediaSettingsRange
hold
> the struct? Then you can simply map the struct to media::mojom::Range.
> 
> It's not really a good idea to create a lot of GarbageCollected objects.

Discussed offline and agreed on fixing it in a follow-up. LGTM.

[Guido Urdaneta, 2017-03-15 17:04:19]

mediastream lgtm, take a look at my question.

https://codereview.chromium.org/2747573002/diff/200001/third_party/WebKit/Sou...
File third_party/WebKit/Source/modules/mediastream/MediaStreamTrack.idl (right):

https://codereview.chromium.org/2747573002/diff/200001/third_party/WebKit/Sou...
third_party/WebKit/Source/modules/mediastream/MediaStreamTrack.idl:53:
[RuntimeEnabled=ImageCapture] MediaTrackCapabilities getCapabilities();
Should we have an additional getCapabilities flag to control enabling of
getCapabilities separately from ImageCapture?

[mcasas, 2017-03-15 17:20:29]

On 2017/03/15 17:04:19, Guido Urdaneta wrote:
> mediastream lgtm, take a look at my question.
> 
>
https://codereview.chromium.org/2747573002/diff/200001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/modules/mediastream/MediaStreamTrack.idl
(right):
> 
>
https://codereview.chromium.org/2747573002/diff/200001/third_party/WebKit/Sou...
> third_party/WebKit/Source/modules/mediastream/MediaStreamTrack.idl:53:
> [RuntimeEnabled=ImageCapture] MediaTrackCapabilities getCapabilities();
> Should we have an additional getCapabilities flag to control enabling of
> getCapabilities separately from ImageCapture?

Yeah! The new flag could be called  e.g. MediaTrackCapabilities
(to avoid confusion with the WICG Media Capabilities Spec)
and I can make it implied_by ImageCapture in the json5 [1]

Actually it might be event better if I make all 3 Constrainable
Pattern flags (i.e. the new flag, MediaConstraints and
MediaGetSettings) implied_by ImageCapture. Sounds good?

If you don't mind I can do it in the next CL
that will be only flag-manipulation (easy review).

[1]
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/Runti...

[mcasas, 2017-03-15 17:21:22]

The CQ bit was checked by mcasas@chromium.org

[mcasas, 2017-03-15 17:21:23]

The patchset sent to the CQ was uploaded after l-g-t-m from reillyg@chromium.org
Link to the patchset: https://codereview.chromium.org/2747573002/#ps200001
(title: "haraken@ and reillyg@s comments")

[commit-bot: I haz the power, 2017-03-15 17:21:55]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-15 18:50:15]

CQ is committing da patch.

Bot data: {"patchset_id": 200001, "attempt_start_ts": 1489598482820270,
"parent_rev": "b2e8c35d8bde821a28d0a648d75998efed7ad1c8", "commit_rev":
"30a67395e8cfccfd5954b9244440a7906d065563"}

[commit-bot: I haz the power, 2017-03-15 18:51:14]

Description was changed from

==========
Image Capture: MediaStreamTrack::getCapabilities() 

This CL adds MediaTrackCapabilities.idl and 
MediaStreamTrack::getCapabilities(). The latter function is wired 
to grab the capabilities from image capture, since these are 
the only ones available ATM.  These capabilities should only 
be collected for Video tracks from devices (i.e. not for 
tab/window/cast/remote etc).

MediaStreamTrack.getCapabilities() is synchronous, whereas
image_capture mojom::getPhotoCapabities() is not -- the former 
probably doesn't make a lot of sense Spec-wise but, regardless,
I don't think is a good idea to make the Web thread wait for 
these capabilities to be collected, so what this CL does is
to trigger such collection upon MediaStreamTrack ctor, without
waiting for this process to be finished. (IOW I tried alternatives 
and were much worse).

Added LayoutTests for starters.

This bug is part of a transition from 
 ImageCapture.getPhotoCapabilities() to MediaStreamTrack.getCapabilities() 
but, since Image Capture is already in Origin Trials, I'm 
planning on landing the new infra in parallel, then send a PSA 
and switch over (that's why there's a few TODOs) in the code.

BUG=700607

Incidentally, it improves the state of 
external/wpt/mediacapture-streams/MediaStreamTrack-init.https.html
by allowing the test-for-getCapabilities() to PASS.
==========

to

==========
Image Capture: MediaStreamTrack::getCapabilities() 

This CL adds MediaTrackCapabilities.idl and 
MediaStreamTrack::getCapabilities(). The latter function is wired 
to grab the capabilities from image capture, since these are 
the only ones available ATM.  These capabilities should only 
be collected for Video tracks from devices (i.e. not for 
tab/window/cast/remote etc).

MediaStreamTrack.getCapabilities() is synchronous, whereas
image_capture mojom::getPhotoCapabities() is not -- the former 
probably doesn't make a lot of sense Spec-wise but, regardless,
I don't think is a good idea to make the Web thread wait for 
these capabilities to be collected, so what this CL does is
to trigger such collection upon MediaStreamTrack ctor, without
waiting for this process to be finished. (IOW I tried alternatives 
and were much worse).

Added LayoutTests for starters.

This bug is part of a transition from 
 ImageCapture.getPhotoCapabilities() to MediaStreamTrack.getCapabilities() 
but, since Image Capture is already in Origin Trials, I'm 
planning on landing the new infra in parallel, then send a PSA 
and switch over (that's why there's a few TODOs) in the code.

BUG=700607

Incidentally, it improves the state of 
external/wpt/mediacapture-streams/MediaStreamTrack-init.https.html
by allowing the test-for-getCapabilities() to PASS.

Review-Url: https://codereview.chromium.org/2747573002
Cr-Commit-Position: refs/heads/master@{#457150}
Committed:
https://chromium.googlesource.com/chromium/src/+/30a67395e8cfccfd5954b9244440...
==========

[commit-bot: I haz the power, 2017-03-15 18:51:15]

Committed patchset #2 (id:200001) as
https://chromium.googlesource.com/chromium/src/+/30a67395e8cfccfd5954b9244440...