what is ssrcIds? about webrtc-stats HOT 16 CLOSED

Good question - the suspicion is what I intended when I wrote it.

As for mediaType, that's issue #84 - yes, I intend to add it.

from webrtc-stats.

List to RTP streams identified by ssrc? Why not a list of RTCRTPStream.id:s? Because they come in both In- and Outbound flavors?

from webrtc-stats.

+1 to identifying them with the ids. Also resolves my question (elsewhere) why ssrc is a string there.

from webrtc-stats.

RTCRTPMediaStreamStats.ssrc is string and RTCMediaStreamTrackStats.ssrcIds is a sequence of strings. Question: What does "ssrcIds" mean? Shouldn't it be "ssrcs" or "ssrcIdentifiers"? The "-Ids" bit implies it's an RTCStats.id but there are no SSRCStats. Should we file another bug?

from webrtc-stats.

Oh brainfart it's what this bug is about. But ssrc is string elsewhere too.

from webrtc-stats.

Hm. This seems like something that should have been updated but isn't.

We need a linkage between RTCRtpStreamStats and RTCMediaStreamTrackStats. There's a mediaTrackId in RTCRtpStreamStats; I think ssrcIds was meant to be the opposite of that, but it's misnamed.

Options:

1. Rename it to RtpStreamStatsIds
2. Delete it, and let people reverse-map by walking the stats tree.

What is best?

(I tend to favor the "fewer fields" solution - we can always add fields, but it's very hard to delete them)

from webrtc-stats.

I prefer relationships to be explicit, not only does it make lookup easier but it also documents the relationships. (That being said, I haven't implemented this field and wouldn't mind not having to do it ;) )

from webrtc-stats.

The relationship is explicit, we're just debating if we need one-way pointers or two-way pointers.

from webrtc-stats.

I will go with the RtpStreamStatsIds, making the relationship explicit. And just one way is fine.

from webrtc-stats.

One way would mean removing RTPStreamStatsIds and leaving just mediaTrackId in RTCRTPStreamStats....

from webrtc-stats.

I'd lean towards removing it, for consistency with the rest of the spec. We have one-way pointers everywhere else.

from webrtc-stats.

As for "everywhere else": the following "ids" exist:

• RTCMediaStreamStats.trackIds
• RTCMediaStreamTrackStats.ssrcIds

The first one has to exist becaue the stream<->track relationship is many-to-many; reverse pointers can't save you. So we can't just delete the entire "Ids" concept.

Are we 100% sure there's no case (repair SSRC, flexfec SSRC, simulcast SSRC, layered encoding SSRC) where an SSRC needs to be referenced from multiple MediaStreamTracks?

If this is true (I'm looking at Taylor), I'm in favor of dropping the field.

NOTE: If it's false, the single-valued "mediaTrackId" in RTCRTPStreamStats is in trouble, too. So I hope it's true.

from webrtc-stats.

This is somewhat related to #116 in that if we want a formal definition for "what do we return if we ask for a track in the selector", we can't use "the track and whatever is referenced", since it's pretty certain that people who want stats on a track will want the related RTP sessions. So the rule would become either "the track, everything that references it, and everything those objects have references to" or "the track, and ". We can't use "The track, and everything it references".

This is a note so that I remember, it shouldn't influence this decision much.

from webrtc-stats.

I have created a PR to implement the removal once we've verified (again) that it's OK for participants.

from webrtc-stats.

I can't see any way one RTP stream could be used for multiple tracks simultaneously; there's a 1:M relationship between media descriptions and RTP streams. However, if you're not bundling, I think it would be valid to have two RTP streams using the same SSRC. Which shouldn't matter, since each RTCRTPStreamStats has its own id independent from SSRCs.

from webrtc-stats.

Concluded that removal is OK.

from webrtc-stats.