Introduce RtpStreamReceiver and RtpStreamReceiverControllerInterface.

webrtc/call/rtp_transport_controller_receive.h

Index: webrtc/call/rtp_transport_controller_receive.h
diff --git a/webrtc/call/rtp_transport_controller_receive.h b/webrtc/call/rtp_transport_controller_receive.h
new file mode 100644
index 0000000000000000000000000000000000000000..2f73313846dbc5c8f8c4119dfec0837745349b24
--- /dev/null
+++ b/webrtc/call/rtp_transport_controller_receive.h
@@ -0,0 +1,64 @@
+/*
+ *  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.
+ */
+#ifndef WEBRTC_CALL_RTP_TRANSPORT_CONTROLLER_RECEIVE_H_
+#define WEBRTC_CALL_RTP_TRANSPORT_CONTROLLER_RECEIVE_H_
+
+#include <memory>
+
+#include "webrtc/base/array_view.h"
+
+// For DeliveryStatus.
+// TODO(nisse): This file ought to not depend on call.
+#include "webrtc/call/call.h"
+
+#include "webrtc/call/rtp_demuxer.h"
+#include "webrtc/call/rtp_transport_controller_receive_interface.h"
+
+namespace webrtc {
+
+class ReceiveSideCongestionController;
+class RtpPacketReceived;
+
+// This class represents the RTP receive parsing and demuxing, for a
+// single RTP session. It isn't thread aware, leaving responsibility
+// of multithreading issues to the user of this class. TODO(nisse):
+// Add RTCP processing, we should aim to terminate RTCP and not leave
+// any RTCP processing to individual receive streams. TODO(nisse):
+// Extract packet processing, including parsing and demuxing, into a
+// separate RtpSessionReceiver classes.

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

Shouldn't TODOs be on their own line?

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

Will fix in next ps.

+class RtpTransportControllerReceive
+    : public RtpTransportControllerReceiveInterface {
+ public:
+  // Implements RtpTransportControllerReceiveInterface.
+  std::unique_ptr<RtpTransportReceiver> CreateReceiver(
+      uint32_t ssrc,
+      RtpPacketSinkInterface* sink) override;
+
+  // TODO(nisse): Not yet responsible for parsing.
+  bool OnRtpPacket(const RtpPacketReceived& packet);
+
+ private:
+  class Receiver : public RtpTransportReceiver {
+   public:
+    Receiver(RtpDemuxer* demuxer_, uint32_t ssrc, RtpPacketSinkInterface* sink);
+
+    ~Receiver();
+
+   private:
+    RtpDemuxer* demuxer_;
+    RtpPacketSinkInterface* sink_;
+  };
+
+  RtpDemuxer demuxer_;
+};

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

what is preventing putting ReceiveSideCC into this class?

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

Two things at the moment:

1. The logic prior to calling receive_side_cc_.OnReceivedPacket. I moved that in
the larger cl
(https://codereview.webrtc.org/2709723003/diff/510001/webrtc/call/rtp_transpor...),
involving the flags use_send_side_bwe and enable_receive_side_bwe, which
reviewers found confusing. To simplify things, I tried to delete the latter of
the flags in https://codereview.webrtc.org/2840833002/, but it seems that's not
possible at the moment.

2. The registration of the receive_side_cc_ and
receive_side_cc_.GetRemoteBitrateEstimator(true) as modules on two distinct
ProcessThreads, currently done by Call. Could be worked around by exposing the
receive_side_cc of course.

So I agree receive_side_cc_ belong in this class, but I think move from Call is
tricky and best left for later cls.

+
+}  // namespace webrtc
+
+#endif  // WEBRTC_CALL_RTP_TRANSPORT_CONTROLLER_RECEIVE_H_