Implemented the GetSources() in native code.

webrtc/api/rtpreceiverinterface.h

Index: webrtc/api/rtpreceiverinterface.h
diff --git a/webrtc/api/rtpreceiverinterface.h b/webrtc/api/rtpreceiverinterface.h
index 8607d935a232be6364327ad0af4d966280ec65c4..7b844ed5cefb47a22370a3d89a5d5ae8b105f60c 100644
--- a/webrtc/api/rtpreceiverinterface.h
+++ b/webrtc/api/rtpreceiverinterface.h
@@ -14,7 +14,9 @@
 #ifndef WEBRTC_API_RTPRECEIVERINTERFACE_H_
 #define WEBRTC_API_RTPRECEIVERINTERFACE_H_
 
+#include <memory>
 #include <string>
+#include <vector>
 
 #include "webrtc/api/mediatypes.h"
 #include "webrtc/api/mediastreaminterface.h"
@@ -25,6 +27,18 @@
 
 namespace webrtc {
 
+class RtpContributingSourceInterface {
+ public:
+  virtual ~RtpContributingSourceInterface() {}
+
+  virtual int64_t timestamp() const = 0;
+
+  // Can be either the SSRC or the CSRC.
+  virtual uint32_t source() const = 0;
+
+  virtual int8_t audio_level() const = 0;

[hbos, 2017/03/30 09:51:54]

This should be rtc::Optional<...>. 0 is a meaningful value. Otherwise, if a
negative value is supposed to mean undefined then document that, but I think
rtc::Optional is self-documenting.

Even if an implementation supports this field it would only be used if the RTP
header extension is used and might be undefined, if I understand this correctly.

Also: int8_t or uint8_t?

[Taylor Brandstetter, 2017/03/30 22:55:37]

It only ranges from 0 to 127. So might as well make it an int8_t, since we
prefer signed types by default.

I'd also suggest adding a comment making it clear that this isn't implemented
yet, and will always return an empty Optional.

+};
+
 class RtpReceiverObserverInterface {
  public:
   // Note: Currently if there are multiple RtpReceivers of the same media type,
@@ -61,6 +75,9 @@ class RtpReceiverInterface : public rtc::RefCountInterface {
   // Must call SetObserver(nullptr) before the observer is destroyed.
   virtual void SetObserver(RtpReceiverObserverInterface* observer) = 0;
 
+  virtual std::vector<std::unique_ptr<RtpContributingSourceInterface>>

[Taylor Brandstetter, 2017/03/30 22:55:37]

Since this looks so similar to the JS API, but behaves differently, there should
be a comment that documents the differences. Namely:

* Each time the method is called, a vector of new objects is created. If the
application wants to identify them across calls, it should use the "source()"
value, not the value of the pointer.
* The returned RtpContributingSource objects don't get updated automatically
when more packets are received, as will happen with the JS
RTCRtpContributingSource objects. They're just structs, basically.

This confusion may be a good reason to just return a vector of structs, instead
of unique_ptrs wrapping an interface. In short, the issue is that returning a
pointer to an abstract class may make API users think that a "smart" object is
being returned, when really it isn't.

[Zhi Huang, 2017/03/31 06:44:04]

Yeah, I agree that returning plain structs would be more clear.

Done.

[the sun, 2017/03/31 07:03:49]

Perhaps that is the guideline we were looking for? :)

+  GetContributingSources() = 0;
+
  protected:
   virtual ~RtpReceiverInterface() {}
 };
@@ -76,7 +93,9 @@ BEGIN_SIGNALING_PROXY_MAP(RtpReceiver)
   PROXY_CONSTMETHOD0(RtpParameters, GetParameters);
   PROXY_METHOD1(bool, SetParameters, const RtpParameters&)
   PROXY_METHOD1(void, SetObserver, RtpReceiverObserverInterface*);
-END_PROXY_MAP()
+  PROXY_METHOD0(std::vector<std::unique_ptr<RtpContributingSourceInterface>>,
+                GetContributingSources);
+  END_PROXY_MAP()
 
 }  // namespace webrtc