Webrtc-pc: Clarify whether RTCRtpContributingSource members are live.

[jan-ivar]

@taylor-b Even with recent clarifications, I still find two ways of reading getContributingSources(). Even though it returns a sequence of platform object values, and the sequence itself is passed by value, it's not clear whether the objects in the sequence are the same each time or new ones.

Basically, assuming no external changes for a couple of seconds, which is right:

1. Each call returns a sequence of unique static snapshots of the most recent values at the time, or
2. Each call returns a sequence of the same platform objects, whose readonly members are "live"?

Where "live" means "may change on the next event loop". What's the intent; can we make it clearer?

[taylor-b]

Each call returns a sequence of the same platform objects, whose readonly members are "live"?

That's how I interpreted it. Otherwise why would they be interfaces and not just dictionaries? When we've talked about this API in virtual interims (for example, when discussing https://github.com/w3c/webrtc-pc/issues/1091), I mentioned this assumption and there wasn't any disagreement.

What would you suggest adding to make this more clear? Maybe add something to the description of getContributingSources like:

Only one RTCRtpContributingSource object will be created for each CSRC identifier received by this RTCRtpReceiver. Subsequent calls to getContributingSources will return the same objects if the set of contributing sources has not changed.

And/or we could add this somewhere:

Note that the RTCRtpContributingSource and RTCRtpSynchronizationSource objects will be updated regardless of whether getContributingSources/getSynchronizationSources is called again. Calls to getContributingSources and getSynchronizationSources are only needed to retrieve an updated list of objects, in case an additional CSRC or SSRC identifier has been seen since the last call.

Just some ideas.

[na-g]

@jan-ivar & @taylor-b To get one of these potentially live objects, one has to poll the getContributingSources, or getSynchronizationSources interfaces until the CSRC or SSRC has contributed to playout (which may never happen). Without a way to ask for one to ask for one of these live objects by source identifier, is there a added value in its liveness when one is already polling for discovery purposes?

[na-g]

@taylor-b There may also need to be additional clarification around the value of the live objects that have not been updated in the last 10 seconds. Is the intent that the live objects retain the last value they had even if the timestamp is past the 10 second window, or for that matter the lifetime of the associated receiver?

[taylor-b]

Without a way to ask for one to ask for one of these live objects by source identifier, is there a added value in its liveness when one is already polling for discovery purposes?

That's a very good point, I've wondered this myself. Based on git history, it looks like this API was introduced by @fluffy, so maybe he has an answer.

Is the intent that the live objects retain the last value they had even if the timestamp is past the 10 second window, or for that matter the lifetime of the associated receiver?

My assumption was that:

• Live objects retain the last value they had (which is the behavior even before the 10 second mark is hit)
• getContributingSources doesn't return the objects any more
• They're eligible for garbage collection. If there's, say, a 20 second gap of receiving no packets, and the object is garbage collected, once packets start being received again, getContributingSources MAY return a new object.

But that's just my assumption; I'm not sure about the original intentions. Again, Cullen may be a better person to ask (or he may know who to ask).

[fluffy]

I wasn't really thinking about if it was the same object or not or how long it lived when the original stuff got written.I was mostly thinking about what RTP data needed to be returned, not how it got packaged in the JS. I don't think I imagine that the API would return live objects - Instead the API returned a snap shot of what the values at the time of the API call but perhaps others were thinking live objects. I don't recall any huge old history that caused these to need to be one way or the other. We should choose what makes most sense now. From my point of view it is important that we get the list of CSRC for the current (where that means the stuff that recently played or is playing)_ and be able to use that to drive look up the name of the "Active Speaker" and display that. The Active speaker changes frequently ( like more than 1 per second but less than 1/10 of a second ).

[taylor-b]

Ok... Maybe we should consider changing them from interfaces to dictionaries then. That would certainly be simpler from an implementation perspective. Our current implementation in Chrome basically does this through most the layers of code, then relies on the upper JS/Blink layer of code to map the structures to existing objects.

Do you remember the history for them being interfaces instead of dictionaries? Or was this likely just an oversight? I'm surprised no one mentioned this when discussing #1091 at the virtual interim...

[alvestrand]

Live objects make people's heads hurt - apps trying to do "what's changed" will have totally different results depending on whether they store the objects or the values from the objects.

I don't see (at the moment) a compelling reason not to change them to dictionaries (with "required" on the members), just to make the point clear that they're copied data. I think the choice of interface vs dictionary was not very thought-through; we seem to have flipped back and forth over which was preferred a number of times.

[aboba]

@taylor-b Can you submit a PR?

[na-g]

@taylor-b & all, thanks for looking at this.

[taylor-b]

@aboba Will do.

[jan-ivar]

@taylor-b How's the PR coming? - I'll add a slide for tomorrow. I think we can cover it even without one.

[aboba]

Consensus from TPAC discussion (https://www.w3.org/2017/11/06-webrtc-minutes.html):
Agreed no live objects (interpretation #1 is correct)

@jan-ivar What changes (if any) are needed to make this more clear?

[jan-ivar]

@aboba I'll provide a PR that switches the returned objects to dictionaries.

[alvestrand]

Closed per #1668