Video Capture: Allow 0 fps frame rates to be deserializable

Video Capture: Allow 0 fps frame rates to be deserializable

Some webcams, notably the Win XSplit broadcaster, 
indicate 0 fps frame rate when they are not started/
configured. This rate is not deserializable 
(because is not IsValid()) [1]. This CL allows 
supported formats with 0 fps to be received via 
IPC.

XSplit walkthrough before-after:

Currently when XSplit lists 0 fps, the message
cannot be deserialized from the IPC and is 
discarded; getUserMedia constraint resolution 
@MediaStreamVideoCapturerSource never 
progresses since is expecting that message.

With this change, 0 fps will be used, and since
for unconfigured XSplit this is the only frame 
rate, it's used (unless the user constrains it 
via Mandatory constraint). When the 0 fps 
selected format is passed to the 
VideoCaptureDeviceWin to be used, this ignores
it (since is zero), and the capture happens
at whatever frame rate is native to the
source. And then we see an XSplit picture
indicating this fact. When streaming starts,
the picture is substituted with the feed.

BUG=383949
[1] https://code.google.com/p/chromium/codesearch#chromium/src/media/video/capture/video_capture_types.cc&sq=package:chromium&type=cs&q=IsValid%20video%20&l=26

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=279078

[mcasas, 2014-06-12 18:40:06]

bemasc@ PTAL.

[bemasc, 2014-06-12 18:51:38]

This seems hacky to me.

How about making getDeviceSupportedFormats return bool instead of void?  If it
returns false, then the device cannot be opened.

[mcasas, 2014-06-16 10:20:03]

On 2014/06/12 18:51:38, bemasc wrote:
> This seems hacky to me.

Changed approach: leaving the decision of what's good/no good fps to renderer
side.

> 
> How about making getDeviceSupportedFormats return bool instead of void?  If it
> returns false, then the device cannot be opened.

GDSF is a best-effort method so for it is the same if the device
didn't open correctly or if the enumeration has some quirky values.
Besides in this particular case, if the device enumerates 0 fps we
cannot know if it's in a usable state or not, so returning bool
would be linked to what condition?

[mcasas, 2014-06-16 10:20:25]

perkj@ bemasc@ PTAL.

[perkj_chrome, 2014-06-17 09:20:10]

ok with me but can you please add a test in the render process where capability
is 0fps? Maybe in MediaStreamVideoCaptureSource unittests  to make sure we don't
have division by zero somewhere due to this.

[bemasc, 2014-06-17 14:48:50]

Are you sure this is going to work?  From the discussion with the XSplit dev in
the bug, it sounds like 0 FPS means Variable Frame Rate, not that XSplit isn't
sending frames.

[perkj_chrome, 2014-06-19 11:23:35]

https://codereview.chromium.org/332863002/diff/60001/media/video/capture/win/...
File media/video/capture/win/video_capture_device_factory_win.cc (right):

https://codereview.chromium.org/332863002/diff/60001/media/video/capture/win/...
media/video/capture/win/video_capture_device_factory_win.cc:301: if
(!h->AvgTimePerFrame)
So this does not add the format at all. Is that really what you want?

[mcasas, 2014-06-19 12:20:41]

perkj@ PTAL

[perkj_chrome, 2014-06-19 12:26:07]

On 2014/06/19 12:20:41, mcasas wrote:
> perkj@ PTAL

lgtm with the test comment addressed.

[perkj_chrome, 2014-06-19 12:26:14]

https://codereview.chromium.org/332863002/diff/80001/content/renderer/media/m...
File content/renderer/media/media_stream_video_source_unittest.cc (right):

https://codereview.chromium.org/332863002/diff/80001/content/renderer/media/m...
content/renderer/media/media_stream_video_source_unittest.cc:679: EXPECT_EQ(1,
NumberOfSuccessConstraintsCallbacks());
Please also deliver a frame to a sink. See line 615 to 624.

[mcasas, 2014-06-23 07:30:47]

The CQ bit was checked by mcasas@chromium.org

[commit-bot: I haz the power, 2014-06-23 07:32:15]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/mcasas@chromium.org/332863002/100001

[commit-bot: I haz the power, 2014-06-23 10:04:08]

Change committed as 279078