Introduce RtpStreamReceiver and RtpStreamReceiverControllerInterface.

webrtc/call/rtp_transport_controller_receive.cc

Index: webrtc/call/rtp_transport_controller_receive.cc
diff --git a/webrtc/call/rtp_transport_controller_receive.cc b/webrtc/call/rtp_transport_controller_receive.cc
new file mode 100644
index 0000000000000000000000000000000000000000..0394269f8ff75419cf8e2cefd6774dc9e26be87f
--- /dev/null
+++ b/webrtc/call/rtp_transport_controller_receive.cc
@@ -0,0 +1,37 @@
+/*
+ *  Copyright (c) 2017 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.
+ */
+
+#include "webrtc/call/rtp_transport_controller_receive.h"
+#include "webrtc/base/ptr_util.h"
+
+namespace webrtc {
+
+RtpTransportControllerReceive::Receiver::Receiver(RtpDemuxer* demuxer,
+                                                  uint32_t ssrc,
+                                                  RtpPacketSinkInterface* sink)
+    : demuxer_(demuxer), sink_(sink) {
+  demuxer_->AddSink(ssrc, sink_);
+}
+
+RtpTransportControllerReceive::Receiver::~Receiver() {
+  demuxer_->RemoveSink(sink_);

[pthatcher1, 2017/05/17 23:24:53]

So a Receiver is a thing that adds and removes itself from the demuxer?

[nisse-webrtc, 2017/05/18 08:45:43]

Correct, it doesn't yet have any other responsibilities. (And it's according to
the design doc).

[pthatcher1, 2017/05/24 03:57:38]

Can you explain this in a comment in the code?

And can you send me a link to the doc?  That might help me understand all these
things and how they interact.

+}
+
+std::unique_ptr<RtpTransportReceiver>
+RtpTransportControllerReceive::CreateReceiver(uint32_t ssrc,
+                                              RtpPacketSinkInterface* sink) {
+  return rtc::MakeUnique<Receiver>(&demuxer_, ssrc, sink);

[danilchap, 2017/05/19 15:37:43]

returning pointer to non-thread-safe &demux is an error-prone pattern.
Do not think there is an easy safe solution.
Making demuxer thread-safe (with read-write lock or with a task queue) might be
better option.

[nisse-webrtc, 2017/05/22 07:09:37]

Note that the demuxer pointer is only passed to the Receiver object, which is
intimately related to the controller. But I agree it's not ideal; if the
receiver is destroyed on the wrong thread, we get unsafe use of the demuxer.
Still I think I'd like to have the demuxer itself simple and not thread aware.
What do you think of the following:

Make the RtpTransportControllerReceive thread-safe, and replace the &demuxer_
pointer above by this?

As for synchronization primitive, I don't think a read-write lock is the right
tool. It makes sense to replace a plain mutex by a read-write lock only if we
get lock contention from multiple threads who all need only read access. I don't
quite understand the current threading model for Call, but I guess all demuxing
happens on the same thread, likely the network thread?

And migrating to task queue, do you think that is easy to do at this point?

[nisse-webrtc, 2017/05/22 12:41:13]

Done now.

+}
+
+bool RtpTransportControllerReceive::OnRtpPacket(RtpPacketReceived& packet) {
+  return demuxer_.OnRtpPacket(packet);
+}
+
+}  // namespace webrtc