Make cricket::VideoCapturer implement VideoSourceInterface

webrtc/media/base/videosinkinterface.h

 /*
  *  Copyright (c) 2016 The WebRTC project authors. All Rights Reserved.
  *
  *  Use of this source code is governed by a BSD-style license
  *  that can be found in the LICENSE file in the root of the source
  *  tree. An additional intellectual property rights grant can be found
  *  in the file PATENTS.  All contributing project authors may
  *  be found in the AUTHORS file in the root of the source tree.
  */
 
 #ifndef WEBRTC_MEDIA_BASE_VIDEOSINKINTERFACE_H_
 #define WEBRTC_MEDIA_BASE_VIDEOSINKINTERFACE_H_
 
 namespace rtc {
 
+struct VideoSinkCapabilities {
+  bool can_apply_rotation_ = false;

[pthatcher, 2016/02/01 18:40:54]

Shouldn't that be can_apply_rotation (no "_" on the end)?

[perkj_webrtc, 2016/02/02 16:24:00]

Done.

+};
+
 template <typename VideoFrameT>
 class VideoSinkInterface {
  public:
   virtual void OnFrame(const VideoFrameT& frame) = 0;
+  virtual VideoSinkCapabilities getCapabilities() { return  VideoSinkCapabilities(); }

[pthatcher, 2016/02/01 18:40:54]

These needs a SignalCapabilitiesChanged signal to indicate when it changes.  In
the case of the video engine, it will need to change the capabilities whenever
the CVO header extension changes.  In the case of the capturers, they will need
to change rotation behavior whenever the signal is fired and the
can_apply_rotation bit is changed.

[pthatcher, 2016/02/01 18:40:54]

Can you rename getCapabilities() to be just capabilities()?

[nisse-webrtc, 2016/02/02 09:52:30]

Will all flags really be capabilities, or is it better to just call them
properties? We were just discussing how to do android-specific hacks, where we
may need to pass things like texture references up and down the pipeline.

[nisse-webrtc, 2016/02/02 09:52:30]

I'm not sure what you mean by "signal" here. We really should keep this as
simple as possible. I'd really prefer not to add a separate callback function
for it. Some possibilities:

1. Let the sink just call RemoveSink and AddSink. Potential drawback is that we
might miss one frame if OnFrame is called on a separate thread. If we add the
capabilities as an argument to AddSink, we don't even need the getCapabilities
method.
 
2. Add a method which is equivalent to RemoveSink and AddSink, except that it
doesn't modify the list, avoiding the above race. Could be called
SignalCapabilitiesChanged, or ReAddSink, or whatever. Should take capabilities
as an argument, so still no need for getCapabilities.

3. Give OnFrame a return value, where true indicates changed capabilities. The
idea is that the source shouldn't care about capabilities when it's not
generating any frames. Potential drawback is that the new capabilities will not
be taken into consideration until the next frame, but that's probably no big
deal. Has the advantage over (1) and (2) that the sink doesn't need to keep any
backpointer to its source. Which makes things a little more flexible, the
responsibility for linking source and sink together (calling AddSink and
RemoveSink at the right time can be given to some other object). We could
consider having the new capabilities returned at the same time, via a pointer
argument to OnFrame.

[perkj_webrtc, 2016/02/02 16:24:00]

I had not got that far yesterday but I would really like to avoid sigslots and
Signals in an interface. 
I went with nisses suggestion 1 here.


Another think- we can remove VideoSinkInterface all together and just register a
callback object (Functor in bind.h) to receive VideoFrames through the new
VideoSourceInterface::AddSink.  Then no one have to implement
VideoSinkInterface. I don't have a strong opinion but the it would mean that all
current places where we receive video frames does not have to be renamed.  

 
  protected:
   ~VideoSinkInterface() {}
 };
 
 }  // namespace rtc
 
 #endif  // WEBRTC_MEDIA_BASE_VIDEOSINKINTERFACE_H_