Delete FrameInput method and FrameInputWrapper class.

talk/app/webrtc/mediastreaminterface.h

Index: talk/app/webrtc/mediastreaminterface.h
diff --git a/talk/app/webrtc/mediastreaminterface.h b/talk/app/webrtc/mediastreaminterface.h
index 8d6feb02ef268a8115985d517e13cd0a40a018a3..0bff70a7cd483930c63a16f19c04b04bef9e3f25 100644
--- a/talk/app/webrtc/mediastreaminterface.h
+++ b/talk/app/webrtc/mediastreaminterface.h
@@ -146,6 +146,11 @@ class VideoTrackInterface : public MediaStreamTrackInterface {
   virtual void RemoveRenderer(VideoRendererInterface* renderer) = 0;
 
   virtual VideoSourceInterface* GetSource() const = 0;
+  // TODO(nisse): Return type should be changed to
+  // rtc::VideoSinkInterface<cricket::VideoFrame>*, as soon as
+  // VideoProviderInterface::SetVideoPlayout is changed to accept that
+  // type.
+  virtual cricket::VideoRenderer* GetSink() = 0;

[pthatcher1, 2016/02/03 16:17:39]

We should describe what this returns.  I believe it's a thing, that when given
frames, will allow the frames to go into the track.  

But that just makes me wonder: why doesn't VideoTrackInterface just implement
VideoRendererInterface?

[perkj_webrtc, 2016/02/04 07:32:44]

Doing that would force the track proxies to also have to implement
VideoRendererInterface and all frames would be marshalled onto the signaling
thread. Not so good. 
I like the other idea better that all tracks just pass AddSink on to the source
and let source do the frame forwarding. But before we can do that- this feels
like a step in the right direction.

However - if will break the possibility to use a remote track as input to
another PC. It will not affect Chrome though so I think that is acceptable while
we are doing this refactoring.  

[nisse-webrtc, 2016/02/04 08:22:37]

Done.
That's what I tried first ;-). It made sense to have a VideoTrack be a mux,
implementing both Source and Sink interfaces. 

I first got into a mundane problem: I did that on the branch after changing
these things from VideoRenderer to VideoSinkInterface. But I got compilation
errors when adding the OnFrame method to VideoTrackProxy which I couldn't sort
out.

And then after talking to Per, I realized that it's probably not a good idea
anyway to have the VideoTrackProxy implement OnFrame. It seemed better to have
the proxy implement GetSink(), and return a pointer to the underlying object.

[pthatcher1, 2016/02/04 17:30:45]

So a Track is neither a Source nor a Sink, but just has a Source and Sink.  I
guess that sort of makes sense.  Except... are they guaranteed not to change?  A
sure hope so.  In fact, can you put a comment saying something like "the value
returned by GetSink() must not change between calls", or something like that?

Also, can you write a comment explaining why VideoTrackInterface can't implement
VideoSinkInterface, so that next time someone asks this the answer will just be
right there?  I'm *sure* I won't be the last person to ask.

 
  protected:
   virtual ~VideoTrackInterface() {}