Win video capture: Fix capture format and frame buffer mismatch

Win video capture: Fix capture format and frame buffer mismatch

BUG=613556
Committed: https://crrev.com/1c5204b6bcb428d524e9c63f751850e1f1c4bd22
Cr-Commit-Position: refs/heads/master@{#422801}

[magjed_chromium, 2016-09-27 13:19:35]

Patchset #1 (id:1) has been deleted

[magjed_chromium, 2016-09-27 13:20:04]

The CQ bit was checked by magjed@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-27 13:20:13]

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

[magjed_chromium, 2016-09-27 13:20:38]

Description was changed from

==========
Video OnIncomingCapturedData: Avoid crash when insufficient frame memory

BUG=chromium:650382
==========

to

==========
Video OnIncomingCapturedData: Avoid crash when insufficient frame memory

BUG=chromium:650382
==========

[magjed_chromium, 2016-09-27 13:20:38]

magjed@chromium.org changed reviewers:
+ mcasas@chromium.org

[magjed_chromium, 2016-09-27 14:07:10]

Miguel - please take a look.

[commit-bot: I haz the power, 2016-09-27 14:07:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-27 14:07:20]

Dry run: This issue passed the CQ dry run.

[mcasas, 2016-09-27 14:36:02]

https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
File content/browser/renderer_host/media/video_capture_device_client.cc (right):

https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_device_client.cc:1: //
Copyright 2015 The Chromium Authors. All rights reserved.
There's no need to specify the project
in the bug line: BUG=650382 is enough.

https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_device_client.cc:220: if
(static_cast<size_t>(length) < frame_format.ImageAllocationSize()) {
IIUC, the DCHECK has never been hit before 
except for this particular devices, but the 
bug says that ManyCam doesn't work at all 
anyway. If so, the correct handling is to 
blacklist it as we do in [1] -- which I 
totally thought we already did for ManyCam.


[1]
https://cs.chromium.org/chromium/src/media/capture/video/win/video_capture_de...

https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_device_client.cc:224: << "
bytes, but only " << length << " bytes was given.";
Who is going to read this DLOG anyway? Code
in media/ seems to be verbose for no reason
already.

[magjed_chromium, 2016-09-27 15:11:50]

Description was changed from

==========
Video OnIncomingCapturedData: Avoid crash when insufficient frame memory

BUG=chromium:650382
==========

to

==========
Video OnIncomingCapturedData: Avoid crash when insufficient frame memory

BUG=650382
==========

[magjed_chromium, 2016-09-27 15:19:56]

https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
File content/browser/renderer_host/media/video_capture_device_client.cc (right):

https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_device_client.cc:1: //
Copyright 2015 The Chromium Authors. All rights reserved.
On 2016/09/27 14:36:02, mcasas wrote:
> There's no need to specify the project
> in the bug line: BUG=650382 is enough.

Done.

https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_device_client.cc:220: if
(static_cast<size_t>(length) < frame_format.ImageAllocationSize()) {
On 2016/09/27 14:36:01, mcasas wrote:
> IIUC, the DCHECK has never been hit before 
> except for this particular devices, but the 
> bug says that ManyCam doesn't work at all 
> anyway. If so, the correct handling is to 
> blacklist it as we do in [1] -- which I 
> totally thought we already did for ManyCam.
> 
> 
> [1]
>
https://cs.chromium.org/chromium/src/media/capture/video/win/video_capture_de...

ManyCam doesn't work for the bug reporter in any browser. ManyCam typically
works though, I have tried it myself on Windows 8 and on my MacBook. I think
it's better to drop frames in these cases than to crash the browser.

https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_device_client.cc:224: << "
bytes, but only " << length << " bytes was given.";
On 2016/09/27 14:36:01, mcasas wrote:
> Who is going to read this DLOG anyway? Code
> in media/ seems to be verbose for no reason
> already.

I don't know if anyone will use it. We can remove the log and just return if you
prefer that.

[mcasas, 2016-09-28 16:39:22]

https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
File content/browser/renderer_host/media/video_capture_device_client.cc (right):

https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_device_client.cc:220: if
(static_cast<size_t>(length) < frame_format.ImageAllocationSize()) {
On 2016/09/27 15:19:56, magjed_chromium wrote:
> On 2016/09/27 14:36:01, mcasas wrote:
> > IIUC, the DCHECK has never been hit before 
> > except for this particular devices, but the 
> > bug says that ManyCam doesn't work at all 
> > anyway. If so, the correct handling is to 
> > blacklist it as we do in [1] -- which I 
> > totally thought we already did for ManyCam.
> > 
> > 
> > [1]
> >
>
https://cs.chromium.org/chromium/src/media/capture/video/win/video_capture_de...
> 
> ManyCam doesn't work for the bug reporter in any browser. ManyCam typically
> works though, I have tried it myself on Windows 8 and on my MacBook. I think
> it's better to drop frames in these cases than to crash the browser.

I'm not sure this is the right thing to do. 
1- since both |length| and |frame_format| are input 
parameters, this DCHECK should happen at the start of 
the method. 

2- the bug description essentially points to some 
corrupted driver's memory (?) being funky when 
accessed, so how's this change going to help?

3- this problem affects Windows only Manycams,
so I'd strongly encourage addressing this issue, if
anywhere,  in SinkInputPin::Receive(...) or 
VideoCaptureDeviceWin::FrameReceived(...). In
those locations we receive data but don't validate
its length against the expected |capture_format_|
length, which is configured previously in time.

Finally, a bit of accountancy: this CL's bug
https://crbug.com/650382 is marked duped of
https://crbugcom/613556 but the latter was closed 
as WontFix, I guess one of them is wrongly labelled.

https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_device_client.cc:224: << "
bytes, but only " << length << " bytes was given.";
On 2016/09/27 15:19:56, magjed_chromium wrote:
> On 2016/09/27 14:36:01, mcasas wrote:
> > Who is going to read this DLOG anyway? Code
> > in media/ seems to be verbose for no reason
> > already.
> 
> I don't know if anyone will use it. We can remove the log and just return if
you
> prefer that.

Yes, by all means, but probably you would revert 
this file's changes in light of my comments before.

[magjed_chromium, 2016-09-29 10:09:56]

The CQ bit was checked by magjed@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-29 10:10:08]

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

[magjed_chromium, 2016-09-29 10:12:12]

Description was changed from

==========
Video OnIncomingCapturedData: Avoid crash when insufficient frame memory

BUG=650382
==========

to

==========
Win video capture: Avoid crash when insufficient frame memory

BUG=650382
==========

[commit-bot: I haz the power, 2016-09-29 10:12:28]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-29 10:12:29]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[magjed_chromium, 2016-09-29 10:43:43]

The CQ bit was checked by magjed@chromium.org to run a CQ dry run

[magjed_chromium, 2016-09-29 10:43:48]

Patchset #2 (id:40001) has been deleted

[commit-bot: I haz the power, 2016-09-29 10:43:59]

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

[magjed_chromium, 2016-09-29 10:58:58]

Patchset #2 (id:60001) has been deleted

[magjed_chromium, 2016-09-29 11:00:36]

https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
File content/browser/renderer_host/media/video_capture_device_client.cc (right):

https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_device_client.cc:220: if
(static_cast<size_t>(length) < frame_format.ImageAllocationSize()) {
On 2016/09/28 16:39:22, mcasas wrote:
> On 2016/09/27 15:19:56, magjed_chromium wrote:
> > On 2016/09/27 14:36:01, mcasas wrote:
> > > IIUC, the DCHECK has never been hit before 
> > > except for this particular devices, but the 
> > > bug says that ManyCam doesn't work at all 
> > > anyway. If so, the correct handling is to 
> > > blacklist it as we do in [1] -- which I 
> > > totally thought we already did for ManyCam.
> > > 
> > > 
> > > [1]
> > >
> >
>
https://cs.chromium.org/chromium/src/media/capture/video/win/video_capture_de...
> > 
> > ManyCam doesn't work for the bug reporter in any browser. ManyCam typically
> > works though, I have tried it myself on Windows 8 and on my MacBook. I think
> > it's better to drop frames in these cases than to crash the browser.
> 
> I'm not sure this is the right thing to do. 
> 1- since both |length| and |frame_format| are input 
> parameters, this DCHECK should happen at the start of 
> the method. 
> 
> 2- the bug description essentially points to some 
> corrupted driver's memory (?) being funky when 
> accessed, so how's this change going to help?
> 
> 3- this problem affects Windows only Manycams,
> so I'd strongly encourage addressing this issue, if
> anywhere,  in SinkInputPin::Receive(...) or 
> VideoCaptureDeviceWin::FrameReceived(...). In
> those locations we receive data but don't validate
> its length against the expected |capture_format_|
> length, which is configured previously in time.
> 
> Finally, a bit of accountancy: this CL's bug
> https://crbug.com/650382 is marked duped of
> https://crbugcom/613556 but the latter was closed 
> as WontFix, I guess one of them is wrongly labelled.
> 
> 
> 

1. That's an unrelated change, but sure, I moved the DCHECK to the top of the
method.

2. This change is going to help by not crashing the browser. Video will still
not work of course.

3. Ok, I moved it into Win specific code. Let's hope it doesn't happen on other
platforms.

Regarding the bugs: 650382 has not been marked a duplicate of 613556 yet, it's
still an open bug. I will group them together now.

[magjed_chromium, 2016-09-29 11:04:25]

Description was changed from

==========
Win video capture: Avoid crash when insufficient frame memory

BUG=650382
==========

to

==========
Win video capture: Avoid crash when insufficient frame memory

BUG=613556
==========

[mcasas, 2016-09-29 20:43:31]

https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
File content/browser/renderer_host/media/video_capture_device_client.cc (right):

https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
content/browser/renderer_host/media/video_capture_device_client.cc:220: if
(static_cast<size_t>(length) < frame_format.ImageAllocationSize()) {
On 2016/09/29 11:00:35, magjed_chromium wrote:
> On 2016/09/28 16:39:22, mcasas wrote:
> > On 2016/09/27 15:19:56, magjed_chromium wrote:
> > > On 2016/09/27 14:36:01, mcasas wrote:
> > > > IIUC, the DCHECK has never been hit before 
> > > > except for this particular devices, but the 
> > > > bug says that ManyCam doesn't work at all 
> > > > anyway. If so, the correct handling is to 
> > > > blacklist it as we do in [1] -- which I 
> > > > totally thought we already did for ManyCam.
> > > > 
> > > > 
> > > > [1]
> > > >
> > >
> >
>
https://cs.chromium.org/chromium/src/media/capture/video/win/video_capture_de...
> > > 
> > > ManyCam doesn't work for the bug reporter in any browser. ManyCam
typically
> > > works though, I have tried it myself on Windows 8 and on my MacBook. I
think
> > > it's better to drop frames in these cases than to crash the browser.
> > 
> > I'm not sure this is the right thing to do. 
> > 1- since both |length| and |frame_format| are input 
> > parameters, this DCHECK should happen at the start of 
> > the method. 
> > 
> > 2- the bug description essentially points to some 
> > corrupted driver's memory (?) being funky when 
> > accessed, so how's this change going to help?
> > 
> > 3- this problem affects Windows only Manycams,
> > so I'd strongly encourage addressing this issue, if
> > anywhere,  in SinkInputPin::Receive(...) or 
> > VideoCaptureDeviceWin::FrameReceived(...). In
> > those locations we receive data but don't validate
> > its length against the expected |capture_format_|
> > length, which is configured previously in time.
> > 
> > Finally, a bit of accountancy: this CL's bug
> > https://crbug.com/650382 is marked duped of
> > https://crbugcom/613556 but the latter was closed 
> > as WontFix, I guess one of them is wrongly labelled.
> > 
> > 
> > 
> 
> 1. That's an unrelated change, but sure, I moved the DCHECK to the top of the
> method.
> 
> 2. This change is going to help by not crashing the browser. Video will still
> not work of course.
> 
> 3. Ok, I moved it into Win specific code. Let's hope it doesn't happen on
other
> platforms.

The crash is only present in Win, and Manycam is available
in Win and Mac only. 

> 
> Regarding the bugs: 650382 has not been marked a duplicate of 613556 yet, it's
> still an open bug. I will group them together now.

https://codereview.chromium.org/2369983003/diff/80001/media/capture/video/win...
File media/capture/video/win/video_capture_device_win.cc (right):

https://codereview.chromium.org/2369983003/diff/80001/media/capture/video/win...
media/capture/video/win/video_capture_device_win.cc:462: return;
With this we will just be ignoring the incoming frame,
never doing anything about it and capturing nothing. 
I suggest adding the condition to the lines around [1],
so the start of that method reads:

  const int length = sample->GetActualDataLength();
  if (length <= 0 ||
      static_cast<size_t>(length) < resulting_format_.ImageAllocationSize()) {
    DLOG(WARNING) << "Wrong media sample length";
    return S_FALSE;
  }

  uint8_t* buffer = nullptr;
  if (FAILED(sample->GetPointer(&buffer)))
    return S_FALSE;

so we can inform Win DirectShow that something
wrong has happened, and we don't do unnecessary
work :)

Actually I wrote this and just noticed that SinkInputPin's
fills in |resulting_format_| but does not propagate this
information, and that's probably the root cause of this
crash. Notwithstanding my recommended code, you
should also extend SinkFilterObserver::FrameReceived()
signature to have a const VideoCaptureFormat& as
a parameter, send |resulting_format_| to
VideoCaptureDeviceWin::FrameReceived() and there
forward it instead of the hoped-for |capture_format_|.

[1]
https://cs.chromium.org/chromium/src/media/capture/video/win/sink_input_pin_w...
[2]
https://cs.chromium.org/chromium/src/media/capture/video/win/sink_filter_obse...

[mcasas, 2016-10-03 16:16:17]

On 2016/09/29 20:43:31, mcasas wrote:
>
https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
> File content/browser/renderer_host/media/video_capture_device_client.cc
(right):
> 
>
https://codereview.chromium.org/2369983003/diff/20001/content/browser/rendere...
> content/browser/renderer_host/media/video_capture_device_client.cc:220: if
> (static_cast<size_t>(length) < frame_format.ImageAllocationSize()) {
> On 2016/09/29 11:00:35, magjed_chromium wrote:
> > On 2016/09/28 16:39:22, mcasas wrote:
> > > On 2016/09/27 15:19:56, magjed_chromium wrote:
> > > > On 2016/09/27 14:36:01, mcasas wrote:
> > > > > IIUC, the DCHECK has never been hit before 
> > > > > except for this particular devices, but the 
> > > > > bug says that ManyCam doesn't work at all 
> > > > > anyway. If so, the correct handling is to 
> > > > > blacklist it as we do in [1] -- which I 
> > > > > totally thought we already did for ManyCam.
> > > > > 
> > > > > 
> > > > > [1]
> > > > >
> > > >
> > >
> >
>
https://cs.chromium.org/chromium/src/media/capture/video/win/video_capture_de...
> > > > 
> > > > ManyCam doesn't work for the bug reporter in any browser. ManyCam
> typically
> > > > works though, I have tried it myself on Windows 8 and on my MacBook. I
> think
> > > > it's better to drop frames in these cases than to crash the browser.
> > > 
> > > I'm not sure this is the right thing to do. 
> > > 1- since both |length| and |frame_format| are input 
> > > parameters, this DCHECK should happen at the start of 
> > > the method. 
> > > 
> > > 2- the bug description essentially points to some 
> > > corrupted driver's memory (?) being funky when 
> > > accessed, so how's this change going to help?
> > > 
> > > 3- this problem affects Windows only Manycams,
> > > so I'd strongly encourage addressing this issue, if
> > > anywhere,  in SinkInputPin::Receive(...) or 
> > > VideoCaptureDeviceWin::FrameReceived(...). In
> > > those locations we receive data but don't validate
> > > its length against the expected |capture_format_|
> > > length, which is configured previously in time.
> > > 
> > > Finally, a bit of accountancy: this CL's bug
> > > https://crbug.com/650382 is marked duped of
> > > https://crbugcom/613556 but the latter was closed 
> > > as WontFix, I guess one of them is wrongly labelled.
> > > 
> > > 
> > > 
> > 
> > 1. That's an unrelated change, but sure, I moved the DCHECK to the top of
the
> > method.
> > 
> > 2. This change is going to help by not crashing the browser. Video will
still
> > not work of course.
> > 
> > 3. Ok, I moved it into Win specific code. Let's hope it doesn't happen on
> other
> > platforms.
> 
> The crash is only present in Win, and Manycam is available
> in Win and Mac only. 
> 
> > 
> > Regarding the bugs: 650382 has not been marked a duplicate of 613556 yet,
it's
> > still an open bug. I will group them together now.
> 
>
https://codereview.chromium.org/2369983003/diff/80001/media/capture/video/win...
> File media/capture/video/win/video_capture_device_win.cc (right):
> 
>
https://codereview.chromium.org/2369983003/diff/80001/media/capture/video/win...
> media/capture/video/win/video_capture_device_win.cc:462: return;
> With this we will just be ignoring the incoming frame,
> never doing anything about it and capturing nothing. 
> I suggest adding the condition to the lines around [1],
> so the start of that method reads:
> 
>   const int length = sample->GetActualDataLength();
>   if (length <= 0 ||
>       static_cast<size_t>(length) < resulting_format_.ImageAllocationSize()) {
>     DLOG(WARNING) << "Wrong media sample length";
>     return S_FALSE;
>   }
> 
>   uint8_t* buffer = nullptr;
>   if (FAILED(sample->GetPointer(&buffer)))
>     return S_FALSE;
> 
> so we can inform Win DirectShow that something
> wrong has happened, and we don't do unnecessary
> work :)
> 
> Actually I wrote this and just noticed that SinkInputPin's
> fills in |resulting_format_| but does not propagate this
> information, and that's probably the root cause of this
> crash. Notwithstanding my recommended code, you
> should also extend SinkFilterObserver::FrameReceived()
> signature to have a const VideoCaptureFormat& as
> a parameter, send |resulting_format_| to
> VideoCaptureDeviceWin::FrameReceived() and there
> forward it instead of the hoped-for |capture_format_|.
> 
> [1]
>
https://cs.chromium.org/chromium/src/media/capture/video/win/sink_input_pin_w...
> [2]
>
https://cs.chromium.org/chromium/src/media/capture/video/win/sink_filter_obse...

Ping. I'm happy to take this over from you if
you don't have the time.

[magjed_chromium, 2016-10-03 17:19:45]

Patchset #3 (id:100001) has been deleted

[magjed_chromium, 2016-10-03 17:22:27]

Patchset #3 (id:120001) has been deleted

[magjed_chromium, 2016-10-03 17:25:43]

Sorry, forgot about this CL. I uploaded a new patch now. Let's hope it will fix
the actual problem.

[mcasas, 2016-10-03 17:32:32]

lgtm with nits

https://codereview.chromium.org/2369983003/diff/140001/media/capture/video/wi...
File media/capture/video/win/sink_filter_observer_win.h (right):

https://codereview.chromium.org/2369983003/diff/140001/media/capture/video/wi...
media/capture/video/win/sink_filter_observer_win.h:23: const VideoCaptureFormat&
format,
nit: can this be forward declared?

https://codereview.chromium.org/2369983003/diff/140001/media/capture/video/wi...
File media/capture/video/win/sink_input_pin_win.cc (right):

https://codereview.chromium.org/2369983003/diff/140001/media/capture/video/wi...
media/capture/video/win/sink_input_pin_win.cc:194: uint8_t* buffer = NULL;
nit: move this to l. 202 and s/NULL/nullptr/

[magjed_chromium, 2016-10-04 08:52:40]

Description was changed from

==========
Win video capture: Avoid crash when insufficient frame memory

BUG=613556
==========

to

==========
Win video capture: Fix capture format and frame buffer mismatch

BUG=613556
==========

[magjed_chromium, 2016-10-04 08:52:51]

The CQ bit was checked by magjed@chromium.org

[magjed_chromium, 2016-10-04 08:52:52]

The patchset sent to the CQ was uploaded after l-g-t-m from mcasas@chromium.org
Link to the patchset: https://codereview.chromium.org/2369983003/#ps160001
(title: "Fix nits")

[commit-bot: I haz the power, 2016-10-04 08:53:06]

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, 2016-10-04 09:15:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-04 09:15:26]

Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[magjed_chromium, 2016-10-04 13:55:03]

I had to revert changes to video_capture_device_client.cc because the DCHECK
will hit before we silently ignore invalid frame formats, so the test:
VideoCaptureDeviceClientTest.FailsSilentlyGivenInvalidFrameFormat would fail.

[magjed_chromium, 2016-10-04 13:55:11]

The CQ bit was checked by magjed@chromium.org

[magjed_chromium, 2016-10-04 13:55:12]

The patchset sent to the CQ was uploaded after l-g-t-m from mcasas@chromium.org
Link to the patchset: https://codereview.chromium.org/2369983003/#ps180001
(title: "Revert changes to video_capture_device_client.cc")

[commit-bot: I haz the power, 2016-10-04 13:55:23]

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, 2016-10-04 15:18:07]

Description was changed from

==========
Win video capture: Fix capture format and frame buffer mismatch

BUG=613556
==========

to

==========
Win video capture: Fix capture format and frame buffer mismatch

BUG=613556
==========

[commit-bot: I haz the power, 2016-10-04 15:18:09]

Committed patchset #5 (id:180001)

[commit-bot: I haz the power, 2016-10-04 15:20:18]

Description was changed from

==========
Win video capture: Fix capture format and frame buffer mismatch

BUG=613556
==========

to

==========
Win video capture: Fix capture format and frame buffer mismatch

BUG=613556

Committed: https://crrev.com/1c5204b6bcb428d524e9c63f751850e1f1c4bd22
Cr-Commit-Position: refs/heads/master@{#422801}
==========

[commit-bot: I haz the power, 2016-10-04 15:20:19]

Patchset 5 (id:??) landed as
https://crrev.com/1c5204b6bcb428d524e9c63f751850e1f1c4bd22
Cr-Commit-Position: refs/heads/master@{#422801}