RTCRtpReceiver.getContributingSources() added.

third_party/WebKit/Source/modules/peerconnection/RTCRtpContributingSource.cpp

Index: third_party/WebKit/Source/modules/peerconnection/RTCRtpContributingSource.cpp
diff --git a/third_party/WebKit/Source/modules/peerconnection/RTCRtpContributingSource.cpp b/third_party/WebKit/Source/modules/peerconnection/RTCRtpContributingSource.cpp
new file mode 100644
index 0000000000000000000000000000000000000000..9c57286dc9b58308ddb2e2bc9488f7c516b27e02
--- /dev/null
+++ b/third_party/WebKit/Source/modules/peerconnection/RTCRtpContributingSource.cpp
@@ -0,0 +1,42 @@
+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "modules/peerconnection/RTCRtpContributingSource.h"
+
+#include "modules/peerconnection/RTCRtpReceiver.h"
+#include "public/platform/WebRTCRtpContributingSource.h"
+
+namespace blink {
+
+RTCRtpContributingSource::RTCRtpContributingSource(
+    RTCRtpReceiver* receiver,
+    const WebRTCRtpContributingSource& webContributingSource)
+    : m_receiver(receiver),
+      m_timestampMs(webContributingSource.timestampMs()),
+      m_source(webContributingSource.source()) {
+  DCHECK(m_receiver);
+}
+
+RTCRtpContributingSource& RTCRtpContributingSource::operator=(
+    const WebRTCRtpContributingSource& webContributingSource) {
+  m_timestampMs = webContributingSource.timestampMs();
+  DCHECK_EQ(webContributingSource.source(), m_source);
+  return *this;
+}
+
+double RTCRtpContributingSource::timestamp() {
+  m_receiver->updateSourcesIfNeeded();

[foolip, 2017/04/06 10:07:23]

This is a bit odd, and suggests that it's possible for the source.timestamp to
change if one keeps the object alive and checks back later. In the spec, it
looks like these objects are basically PODs, and could in fact be dictionaries
although I assume that's too late and not worth pursuing.

The spec doesn't seem to say if getContributingSources() should return the same
RTCRtpContributingSource instances every time, what do other implementation do?

[hbos_chromium, 2017/04/06 11:10:15]

The spec says its an interface, not a dictionary, and explicitly says that when
an RTP packet is received the RTCRtpContributingSource objects corresponding to
those SSRCs/CSRCs are updated. This means we have to updateSourcesIfNeeded, even
when examining existing objects.

[Taylor_Brandstetter, 2017/04/06 20:34:41]

I interpreted the spec the same way. It may not be stated explicitly, but it's
heavily implied.

[foolip, 2017/04/07 06:49:51]

OK, so the spec says "Each time an RTP packet is received, the
RTCRtpContributingSource objects are updated" but doesn't do anything to try to
avoid the values changing at random times if the networking is on another
thread.

Also, if it's necessary to have a link back to the RTCRtpReceiver to implement
this, should the spec just expose that as well?

[hbos_chromium, 2017/04/07 08:18:51]

Good point, filed https://github.com/w3c/webrtc-pc/issues/1117

+  return m_timestampMs;
+}
+
+uint32_t RTCRtpContributingSource::source() const {
+  // Skip |m_receiver->updateSourcesIfNeeded()|, |m_source| is a constant.
+  return m_source;
+}
+
+DEFINE_TRACE(RTCRtpContributingSource) {
+  visitor->trace(m_receiver);
+}
+
+}  // namespace blink