Replace VideoCaptureDataCallback by VideoSinkInterface.

Replace VideoCaptureDataCallback by VideoSinkInterface.

This also deletes unused features of the video_capturer interface, the classes
VideoCaptureFeedBack, VideoCaptureEncodeInterface and related methods,
and the module id which used to be passed as an argument to the
VideoCaptureDataCallback.

In theory the module id could have been used to let a single
VideoCaptureDataCallback serve several capturers, and demultiplex
on the id, but in practice, it was unused. With this change, it is
required to use a separate VideoSinkInterface for each capturer.

BUG=webrtc:6789
Committed: https://crrev.com/b29b9c8e49934e4b9435f8c482bd0bbacdf8f350
Cr-Commit-Position: refs/heads/master@{#15540}

[nisse-webrtc, 2016-11-28 15:01:05]

nisse@webrtc.org changed reviewers:
+ kjellander@webrtc.org, perkj@webrtc.org

[nisse-webrtc, 2016-11-28 15:01:06]

PTAL.

This breaks presubmit because of a banned include of 
webrtc/media/base/videosinkinterface.h

Not sure how to deal with that. I'm considering moving it to api/video, as part
of https://codereview.webrtc.org/2517173004/

[kjellander_webrtc, 2016-11-29 07:56:26]

Will the removal of the ID make it harder/impossible to use more than one
capture device at the same time? I don't know how this code works in practice.
If not, it would be useful to explain why in the CL description.

I see you changed a few Chromium Clang plugin warnings. Are those fixes
sufficient for removing the //build/config/clang:find_bad_constructs entries in
webrtc/modules/video_capture/BUILD.gn?

On 2016/11/28 15:01:06, nisse-webrtc wrote:
> PTAL.
> 
> This breaks presubmit because of a banned include of 
> webrtc/media/base/videosinkinterface.h
> 
> Not sure how to deal with that. I'm considering moving it to api/video, as
part
> of https://codereview.webrtc.org/2517173004/

To avoid the PRESUBMIT warning about including
webrtc/media/base/videosinkinterface.h in
webrtc/modules/video_capture/video_capture.h; you just need to add a line like:
"+webrtc/media/base",
in webrtc/modules/video_capture/DEPS.

[nisse-webrtc, 2016-11-29 08:07:08]

On 2016/11/29 07:56:26, kjellander_webrtc wrote:
> Will the removal of the ID make it harder/impossible to use more than one
> capture device at the same time? I don't know how this code works in practice.

I don't think so. One needs to use a separate VideoSinkInterface object for each
capturer, 
but as far as found there was no code which used the same
VideoCaptureDataCallback for 
multiple capturers and used the id to demultiplex. I asked perkj about it, and
it seems
the module id has never been used for anything but logging. Code instantiating
the capturer objects
set it to some arbitrary constant.

> I see you changed a few Chromium Clang plugin warnings. Are those fixes
> sufficient for removing the //build/config/clang:find_bad_constructs entries
in
> webrtc/modules/video_capture/BUILD.gn?

I'm afraid I'm not following you. Can you give an example of a "bad construct"
which I change or delete?

> To avoid the PRESUBMIT warning about including
> webrtc/media/base/videosinkinterface.h in
> webrtc/modules/video_capture/video_capture.h; you just need to add a line
like:
> "+webrtc/media/base",
> in webrtc/modules/video_capture/DEPS.

Thanks, I'll try that.

[kjellander_webrtc, 2016-11-29 08:31:07]

On 2016/11/29 08:07:08, nisse-webrtc wrote:
> On 2016/11/29 07:56:26, kjellander_webrtc wrote:
> > Will the removal of the ID make it harder/impossible to use more than one
> > capture device at the same time? I don't know how this code works in
practice.
> 
> I don't think so. One needs to use a separate VideoSinkInterface object for
each
> capturer, 
> but as far as found there was no code which used the same
> VideoCaptureDataCallback for 
> multiple capturers and used the id to demultiplex. I asked perkj about it, and
> it seems
> the module id has never been used for anything but logging. Code instantiating
> the capturer objects
> set it to some arbitrary constant.

Thanks for explaining. I'll leave it up to you to copy-pasting some of that into
the description.

> > I see you changed a few Chromium Clang plugin warnings. Are those fixes
> > sufficient for removing the //build/config/clang:find_bad_constructs entries
> in
> > webrtc/modules/video_capture/BUILD.gn?
> 
> I'm afraid I'm not following you. Can you give an example of a "bad construct"
> which I change or delete?

See
https://www.chromium.org/developers/coding-style/chromium-style-checker-errors
I noticed a few virtual -> override changes in
webrtc/modules/video_capture/video_capture_impl.h
as an example - that's why I asked.

> > To avoid the PRESUBMIT warning about including
> > webrtc/media/base/videosinkinterface.h in
> > webrtc/modules/video_capture/video_capture.h; you just need to add a line
> like:
> > "+webrtc/media/base",
> > in webrtc/modules/video_capture/DEPS.
> 
> Thanks, I'll try that.

[nisse-webrtc, 2016-11-29 08:53:09]

Description was changed from

==========
Replace VideoCaptureDataCallback by VideoSinkInterface.

This also deletes unused features of the video_capturer interface, the classes
VideoCaptureFeedBack, VideoCaptureEncodeInterface and related methods,
and the module id which used to be passed as an argument to the
VideoCaptureDataCallback.

BUG=None
==========

to

==========
Replace VideoCaptureDataCallback by VideoSinkInterface.

This also deletes unused features of the video_capturer interface, the classes
VideoCaptureFeedBack, VideoCaptureEncodeInterface and related methods,
and the module id which used to be passed as an argument to the
VideoCaptureDataCallback. 

In theory the module id could have been used to let a single 
VideoCaptureDataCallback serve several capturers, and demultiplex 
on the id, but in practice, it was unused. With this change, it is 
required to use a separate VideoSinkInterface for each capturer.

BUG=None
==========

[nisse-webrtc, 2016-11-29 08:57:31]

Updated description, and fixed presubmit error (still a few warnings on long
lines, which I'll get to in time).

[kjellander_webrtc, 2016-11-29 08:59:55]

On 2016/11/29 08:57:31, nisse-webrtc wrote:
> Updated description, and fixed presubmit error (still a few warnings on long
> lines, which I'll get to in time).

Nice. You do have a BUG= for this, no? If not we should create one (and possibly
connect it to 5716)

[nisse-webrtc, 2016-11-29 09:50:29]

Description was changed from

==========
Replace VideoCaptureDataCallback by VideoSinkInterface.

This also deletes unused features of the video_capturer interface, the classes
VideoCaptureFeedBack, VideoCaptureEncodeInterface and related methods,
and the module id which used to be passed as an argument to the
VideoCaptureDataCallback. 

In theory the module id could have been used to let a single 
VideoCaptureDataCallback serve several capturers, and demultiplex 
on the id, but in practice, it was unused. With this change, it is 
required to use a separate VideoSinkInterface for each capturer.

BUG=None
==========

to

==========
Replace VideoCaptureDataCallback by VideoSinkInterface.

This also deletes unused features of the video_capturer interface, the classes
VideoCaptureFeedBack, VideoCaptureEncodeInterface and related methods,
and the module id which used to be passed as an argument to the
VideoCaptureDataCallback. 

In theory the module id could have been used to let a single 
VideoCaptureDataCallback serve several capturers, and demultiplex 
on the id, but in practice, it was unused. With this change, it is 
required to use a separate VideoSinkInterface for each capturer.

BUG=webrtc:6789
==========

[nisse-webrtc, 2016-11-29 09:51:15]

On 2016/11/29 08:59:55, kjellander_webrtc wrote:
> On 2016/11/29 08:57:31, nisse-webrtc wrote:
> > Updated description, and fixed presubmit error (still a few warnings on long
> > lines, which I'll get to in time).
> 
> Nice. You do have a BUG= for this, no? If not we should create one (and
possibly
> connect it to 5716)

Filed bug https://bugs.chromium.org/p/webrtc/issues/detail?id=6789

[kjellander_webrtc, 2016-11-29 09:58:14]

lgtm but please weigh Per's review higher since he knows this code better (I
don't).

[perkj_webrtc, 2016-11-29 12:55:56]

looks good. But if you do this much cleaning I would like you to do some more
:->

https://codereview.webrtc.org/2534553002/diff/200001/webrtc/modules/video_cap...
File webrtc/modules/video_capture/video_capture_impl.cc (right):

https://codereview.webrtc.org/2534553002/diff/200001/webrtc/modules/video_cap...
webrtc/modules/video_capture/video_capture_impl.cc:92: void
VideoCaptureImpl::Process()
VideoCaptureImpl no longer need ::Process and VideoCaptureModule no longer need
to inherit from public RefCountedModule.

[nisse-webrtc, 2016-11-29 13:58:17]

Done.

What about VideoCaptureCapability, is that used for anything?

Tests give a bunch of warnings, "No of timing warnings 5", which seem related to
capability_.maxFPS.

https://codereview.webrtc.org/2534553002/diff/200001/webrtc/modules/video_cap...
File webrtc/modules/video_capture/video_capture_impl.cc (right):

https://codereview.webrtc.org/2534553002/diff/200001/webrtc/modules/video_cap...
webrtc/modules/video_capture/video_capture_impl.cc:92: void
VideoCaptureImpl::Process()
On 2016/11/29 12:55:56, perkj_webrtc wrote:
> VideoCaptureImpl no longer need ::Process and VideoCaptureModule no longer
need
> to inherit from public RefCountedModule.

Nice!

And TimeUntilNextProcess should also be deleted. But it still has to inherit
rtc::RefCountInterface, right?

https://codereview.webrtc.org/2534553002/diff/200001/webrtc/modules/video_cap...
webrtc/modules/video_capture/video_capture_impl.cc:94: CriticalSectionScoped
cs(&_callBackCs);
And it seems _callBackCs can also be deleted? In all remaining uses it is locked
together with _apiCs.

[perkj_webrtc, 2016-11-30 06:28:49]

Isnt VideoCaptureCapabilities used for enumerating what formats a camera
supports.

https://codereview.webrtc.org/2534553002/diff/200001/webrtc/modules/video_cap...
File webrtc/modules/video_capture/video_capture_impl.cc (right):

https://codereview.webrtc.org/2534553002/diff/200001/webrtc/modules/video_cap...
webrtc/modules/video_capture/video_capture_impl.cc:92: void
VideoCaptureImpl::Process()
On 2016/11/29 13:58:17, nisse-webrtc wrote:
> On 2016/11/29 12:55:56, perkj_webrtc wrote:
> > VideoCaptureImpl no longer need ::Process and VideoCaptureModule no longer
> need
> > to inherit from public RefCountedModule.
> 
> Nice!
> 
> And TimeUntilNextProcess should also be deleted. But it still has to inherit
> rtc::RefCountInterface, right?

I don't think so. It does not have to be ref counted.

https://codereview.webrtc.org/2534553002/diff/200001/webrtc/modules/video_cap...
webrtc/modules/video_capture/video_capture_impl.cc:94: CriticalSectionScoped
cs(&_callBackCs);
On 2016/11/29 13:58:17, nisse-webrtc wrote:
> And it seems _callBackCs can also be deleted? In all remaining uses it is
locked
> together with _apiCs.

You can use GUARDED_BY().. But yes, there is no reason to have two locks.

[nisse-webrtc, 2016-11-30 07:54:01]

https://codereview.webrtc.org/2534553002/diff/200001/webrtc/modules/video_cap...
File webrtc/modules/video_capture/video_capture_impl.cc (right):

https://codereview.webrtc.org/2534553002/diff/200001/webrtc/modules/video_cap...
webrtc/modules/video_capture/video_capture_impl.cc:92: void
VideoCaptureImpl::Process()
On 2016/11/30 06:28:48, perkj_webrtc wrote:
> On 2016/11/29 13:58:17, nisse-webrtc wrote:
> > On 2016/11/29 12:55:56, perkj_webrtc wrote:
> > > VideoCaptureImpl no longer need ::Process and VideoCaptureModule no longer
> > need
> > > to inherit from public RefCountedModule.
> > 
> > Nice!
> > 
> > And TimeUntilNextProcess should also be deleted. But it still has to inherit
> > rtc::RefCountInterface, right?
> 
> I don't think so. It does not have to be ref counted.

There's a method, WebRtcVcmFactory::Create, which returns a
scoped_refptr<VideoCaptureModule>. Should we keep ref counting in for this cl,
or can we change that Create method (and whatever calls it) to use a unique_ptr
instead?

[perkj_webrtc, 2016-11-30 19:00:34]

On 2016/11/30 07:54:01, nisse-webrtc wrote:
>
https://codereview.webrtc.org/2534553002/diff/200001/webrtc/modules/video_cap...
> File webrtc/modules/video_capture/video_capture_impl.cc (right):
> 
>
https://codereview.webrtc.org/2534553002/diff/200001/webrtc/modules/video_cap...
> webrtc/modules/video_capture/video_capture_impl.cc:92: void
> VideoCaptureImpl::Process()
> On 2016/11/30 06:28:48, perkj_webrtc wrote:
> > On 2016/11/29 13:58:17, nisse-webrtc wrote:
> > > On 2016/11/29 12:55:56, perkj_webrtc wrote:
> > > > VideoCaptureImpl no longer need ::Process and VideoCaptureModule no
longer
> > > need
> > > > to inherit from public RefCountedModule.
> > > 
> > > Nice!
> > > 
> > > And TimeUntilNextProcess should also be deleted. But it still has to
inherit
> > > rtc::RefCountInterface, right?
> > 
> > I don't think so. It does not have to be ref counted.
> 
> There's a method, WebRtcVcmFactory::Create, which returns a
> scoped_refptr<VideoCaptureModule>. Should we keep ref counting in for this cl,
> or can we change that Create method (and whatever calls it) to use a
unique_ptr
> instead?

yes

[nisse-webrtc, 2016-12-01 14:21:13]

https://codereview.webrtc.org/2534553002/diff/220001/webrtc/media/engine/fake...
File webrtc/media/engine/fakewebrtcvcmfactory.h (right):

https://codereview.webrtc.org/2534553002/diff/220001/webrtc/media/engine/fake...
webrtc/media/engine/fakewebrtcvcmfactory.h:30: return module;
This piece of code really wants reference counting; we can't keep a list of
created objects and at the same time give away ownership.

It's a pretty large change to drop reference counting from VideoCaptureModule,
so I'd prefer to not do that in this cl.

For this code, I much prefer changes that can delete lots of code to other types
of changes. Ultimately, we really should cut away most of these layers.

[perkj_webrtc, 2016-12-01 14:32:04]

On 2016/12/01 14:21:13, nisse-webrtc wrote:
>
https://codereview.webrtc.org/2534553002/diff/220001/webrtc/media/engine/fake...
> File webrtc/media/engine/fakewebrtcvcmfactory.h (right):
> 
>
https://codereview.webrtc.org/2534553002/diff/220001/webrtc/media/engine/fake...
> webrtc/media/engine/fakewebrtcvcmfactory.h:30: return module;
> This piece of code really wants reference counting; we can't keep a list of
> created objects and at the same time give away ownership.
> 
> It's a pretty large change to drop reference counting from VideoCaptureModule,
> so I'd prefer to not do that in this cl.
> 
> For this code, I much prefer changes that can delete lots of code to other
types
> of changes. Ultimately, we really should cut away most of these layers.

I can only find one use and that is this one.
https://cs.chromium.org/chromium/src/third_party/webrtc/media/engine/webrtcvi...

 rtc::scoped_refptr<webrtc::VideoCaptureModule> module_;

But ok.

[perkj_webrtc, 2016-12-01 14:35:13]

lgtm but please test that peerconnection_client works on windows and linux and 
video_loopback on win and linux.

[nisse-webrtc, 2016-12-01 14:42:23]

On 2016/12/01 14:32:04, perkj_webrtc wrote:
> On 2016/12/01 14:21:13, nisse-webrtc wrote:
> >
>
https://codereview.webrtc.org/2534553002/diff/220001/webrtc/media/engine/fake...
> > File webrtc/media/engine/fakewebrtcvcmfactory.h (right):
> > 
> >
>
https://codereview.webrtc.org/2534553002/diff/220001/webrtc/media/engine/fake...
> > webrtc/media/engine/fakewebrtcvcmfactory.h:30: return module;
> > This piece of code really wants reference counting; we can't keep a list of
> > created objects and at the same time give away ownership.
> > 
> > It's a pretty large change to drop reference counting from
VideoCaptureModule,
> > so I'd prefer to not do that in this cl.
> > 
> > For this code, I much prefer changes that can delete lots of code to other
> types
> > of changes. Ultimately, we really should cut away most of these layers.
> 
> I can only find one use and that is this one.
>
https://cs.chromium.org/chromium/src/third_party/webrtc/media/engine/webrtcvi...
> 
>  rtc::scoped_refptr<webrtc::VideoCaptureModule> module_;
> 
> But ok.

I have a wip change to change rtc::scoped_refptr<webrtc::VideoCaptureModule> to
unique_ptr everywhere. So far it affects these files,

 webrtc/media/engine/fakewebrtcvcmfactory.h                            |  6
+++---
 webrtc/media/engine/webrtcvideocapturer.cc                            |  6
+++---
 webrtc/media/engine/webrtcvideocapturer.h                             |  7
+++----
 webrtc/modules/video_capture/external/video_capture_external.cc       |  4 ++--
 webrtc/modules/video_capture/linux/video_capture_linux.cc             |  5
++---
 webrtc/modules/video_capture/objc/video_capture.h                     |  3 +--
 webrtc/modules/video_capture/objc/video_capture.mm                    |  9
++++-----
 webrtc/modules/video_capture/test/video_capture_unittest.cc           | 14
+++++++-------
 webrtc/modules/video_capture/video_capture.h                          |  7
+++----
 webrtc/modules/video_capture/video_capture_factory.cc                 |  4 ++--
 webrtc/modules/video_capture/video_capture_factory.h                  |  4 ++--
 webrtc/modules/video_capture/video_capture_impl.cc                    |  4 ++--
 webrtc/modules/video_capture/video_capture_impl.h                     |  7
+++----
 webrtc/modules/video_capture/windows/video_capture_factory_windows.cc |  6
++----
 webrtc/test/vcm_capturer.cc                                           |  2 +-
 webrtc/test/vcm_capturer.h                                            |  3 +--
 16 files changed, 41 insertions(+), 50 deletions(-)

Among other things, there are a dozen of Create methods.

[nisse-webrtc, 2016-12-05 15:13:17]

On 2016/12/01 14:35:13, perkj_webrtc wrote:
> lgtm but please test that peerconnection_client works on windows and linux and

> video_loopback on win and linux.

video_loopback works fine, tested on linux.

peerconnect_client seems a bit broken, also when building on master. What I try:

In one terminal:
./out/Debug/peerconnection_server --port=8888 &
./out/Debug/peerconnection_client --autoconnect

In a second terminal
./out/Debug/peerconnection_client --autoconnect --autocall

Then I get two windows. One of them displays the image from my camera, but in 
all red colors. Second window empty. I haven't used this tool before, so I'm not

quite sure what to expect, but this doesn't seem right.

[nisse-webrtc, 2016-12-08 12:57:30]

On 2016/12/05 15:13:17, nisse-webrtc wrote:
> On 2016/12/01 14:35:13, perkj_webrtc wrote:
> > lgtm but please test that peerconnection_client works on windows and linux
and
> 
> > video_loopback on win and linux.
> 
> video_loopback works fine, tested on linux.
> 
> peerconnect_client seems a bit broken, also when building on master. What I
try:
> 
> In one terminal:
> ./out/Debug/peerconnection_server --port=8888 &
> ./out/Debug/peerconnection_client --autoconnect
> 
> In a second terminal
> ./out/Debug/peerconnection_client --autoconnect --autocall
> 
> Then I get two windows. One of them displays the image from my camera, but in 
> all red colors. Second window empty. I haven't used this tool before, so I'm
not
> 
> quite sure what to expect, but this doesn't seem right.

Who could I ask about testing video_loopback on a windows machine?

And what to do about peerconnection_client and _server, which appeared broken
both 
with and without this cl?

[kjellander_webrtc, 2016-12-08 14:32:50]

Sorry for not responding to this, I've been behind on e-mail.

On 2016/12/08 12:57:30, nisse-webrtc wrote:
> On 2016/12/05 15:13:17, nisse-webrtc wrote:
> > On 2016/12/01 14:35:13, perkj_webrtc wrote:
> > > lgtm but please test that peerconnection_client works on windows and linux
> and
> > 
> > > video_loopback on win and linux.
> > 
> > video_loopback works fine, tested on linux.
> > 
> > peerconnect_client seems a bit broken, also when building on master. What I
> try:
> > 
> > In one terminal:
> > ./out/Debug/peerconnection_server --port=8888 &
> > ./out/Debug/peerconnection_client --autoconnect
> > 
> > In a second terminal
> > ./out/Debug/peerconnection_client --autoconnect --autocall
> > 
> > Then I get two windows. One of them displays the image from my camera, but
in 
> > all red colors. Second window empty. I haven't used this tool before, so I'm
> not
> > 
> > quite sure what to expect, but this doesn't seem right.
> 
> Who could I ask about testing video_loopback on a windows machine?

You can ask Edward or Chris, they have win machines (corp and non-corp).

> And what to do about peerconnection_client and _server, which appeared broken
> both 
> with and without this cl?

Since it sounds like a bug; file a bug and put your observations in there?

[nisse-webrtc, 2016-12-09 08:42:28]

On 2016/12/08 14:32:50, kjellander_webrtc wrote:
> Sorry for not responding to this, I've been behind on e-mail.
> 
> On 2016/12/08 12:57:30, nisse-webrtc wrote:
> > And what to do about peerconnection_client and _server, which appeared
broken
> > both 
> > with and without this cl?
> 
> Since it sounds like a bug; file a bug and put your observations in there?

Filed bug https://bugs.chromium.org/p/webrtc/issues/detail?id=6857

[nisse-webrtc, 2016-12-12 07:35:22]

On 2016/12/08 14:32:50, kjellander_webrtc wrote:
> 
> On 2016/12/08 12:57:30, nisse-webrtc wrote:
> > Who could I ask about testing video_loopback on a windows machine?
> 
> You can ask Edward or Chris, they have win machines (corp and non-corp).

Edward helped me, and it seems video_loopback still works on windows.

So I'll try to land this now.

[nisse-webrtc, 2016-12-12 07:35:41]

The CQ bit was checked by nisse@webrtc.org

[nisse-webrtc, 2016-12-12 07:35:42]

The patchset sent to the CQ was uploaded after l-g-t-m from
kjellander@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2534553002/#ps220001 (title:
"Drop inheritance of RefCountedModule. Drop tests of capture delay.")

[commit-bot: I haz the power, 2016-12-12 07:35:48]

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

[commit-bot: I haz the power, 2016-12-12 07:41:16]

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

[commit-bot: I haz the power, 2016-12-12 07:41:17]

Try jobs failed on following builders:
  presubmit on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/presubmit/builds/11309)

[nisse-webrtc, 2016-12-12 08:05:46]

The CQ bit was checked by nisse@webrtc.org

[nisse-webrtc, 2016-12-12 08:05:46]

The patchset sent to the CQ was uploaded after l-g-t-m from
kjellander@webrtc.org, perkj@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2534553002/#ps240001 (title:
"Break overlong lines.")

[commit-bot: I haz the power, 2016-12-12 08:05:55]

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

[commit-bot: I haz the power, 2016-12-12 08:22:57]

CQ is committing da patch.

Bot data: {"patchset_id": 240001, "attempt_start_ts": 1481529946025180,
"parent_rev": "4fb75f302b15c833ea0e9bcc45cd9d3946f00b44", "commit_rev":
"b7ee38d2c24aae135ebbae5641d743e44aaf5a4f"}

[commit-bot: I haz the power, 2016-12-12 08:23:00]

Description was changed from

==========
Replace VideoCaptureDataCallback by VideoSinkInterface.

This also deletes unused features of the video_capturer interface, the classes
VideoCaptureFeedBack, VideoCaptureEncodeInterface and related methods,
and the module id which used to be passed as an argument to the
VideoCaptureDataCallback. 

In theory the module id could have been used to let a single 
VideoCaptureDataCallback serve several capturers, and demultiplex 
on the id, but in practice, it was unused. With this change, it is 
required to use a separate VideoSinkInterface for each capturer.

BUG=webrtc:6789
==========

to

==========
Replace VideoCaptureDataCallback by VideoSinkInterface.

This also deletes unused features of the video_capturer interface, the classes
VideoCaptureFeedBack, VideoCaptureEncodeInterface and related methods,
and the module id which used to be passed as an argument to the
VideoCaptureDataCallback. 

In theory the module id could have been used to let a single 
VideoCaptureDataCallback serve several capturers, and demultiplex 
on the id, but in practice, it was unused. With this change, it is 
required to use a separate VideoSinkInterface for each capturer.

BUG=webrtc:6789

Review-Url: https://codereview.webrtc.org/2534553002
==========

[commit-bot: I haz the power, 2016-12-12 08:23:01]

Committed patchset #13 (id:240001)

[commit-bot: I haz the power, 2016-12-12 08:23:08]

Description was changed from

==========
Replace VideoCaptureDataCallback by VideoSinkInterface.

This also deletes unused features of the video_capturer interface, the classes
VideoCaptureFeedBack, VideoCaptureEncodeInterface and related methods,
and the module id which used to be passed as an argument to the
VideoCaptureDataCallback. 

In theory the module id could have been used to let a single 
VideoCaptureDataCallback serve several capturers, and demultiplex 
on the id, but in practice, it was unused. With this change, it is 
required to use a separate VideoSinkInterface for each capturer.

BUG=webrtc:6789

Review-Url: https://codereview.webrtc.org/2534553002
==========

to

==========
Replace VideoCaptureDataCallback by VideoSinkInterface.

This also deletes unused features of the video_capturer interface, the classes
VideoCaptureFeedBack, VideoCaptureEncodeInterface and related methods,
and the module id which used to be passed as an argument to the
VideoCaptureDataCallback.

In theory the module id could have been used to let a single
VideoCaptureDataCallback serve several capturers, and demultiplex
on the id, but in practice, it was unused. With this change, it is
required to use a separate VideoSinkInterface for each capturer.

BUG=webrtc:6789

Committed: https://crrev.com/b29b9c8e49934e4b9435f8c482bd0bbacdf8f350
Cr-Commit-Position: refs/heads/master@{#15540}
==========

[commit-bot: I haz the power, 2016-12-12 08:23:10]

Patchset 13 (id:??) landed as
https://crrev.com/b29b9c8e49934e4b9435f8c482bd0bbacdf8f350
Cr-Commit-Position: refs/heads/master@{#15540}