Should track also contain RTCRtpReceiver stats?

[karthikbr82]

Currently definition for track is defined as
Contains statistics related to a specific MediaStreamTrack's attachment to an RTCRtpSender and the corresponding media-level metrics. It is accessed by either RTCSenderVideoTrackAttachmentStats or RTCSenderAudioTrackAttachmentStats, both inherited from RTCMediaHandlerStats.

The monitored "track" object is deleted when the sender it reports on has its "track" value changed to no longer refer to the same track.

So my question is should it contain both RTCRtpSender and RTCRtpReciever

[alvestrand]

When we switched from monitoring tracks to monitoring senders, the thought was that the tracks were there for legacy purposes; it's actually a bit hard to get them to function correctly.
But given that they were already there, we thought we couldn't delete them.

So we'd prefer that people use stats from senders and receivers, respectively.

[henbos]

For backwards compatible reasons we should have a "track" for the attachment to a receiver. Because a receiver has a life-long attachment, this would always be a copy of the "receiver" stats object. But without such language, you would not find the receiving tracks as a "track".

[henbos]

@alvestrand Yes we want to remove "track" altogether, but it would be strange to have the backwards compatible "track" in the sender case but not the receiver case. If the spec was implemented properly as written today, all the receiver "tracks" would disappear.

We could move it to the Obsolete stats section though to be clear about this being old.

[karthikbr82]

if we are moving "tracks" Obsolete stats section then we could do the same for "stream".
We also have to delete trackIdentifier from senders and receivers.

[henbos]

Yes that sounds like a good idea to me.
Other uses of "trackId" that should move to the obsolete section: RTCInboundRtpStreamStats.trackId, RTCOutboundRtpStreamStats.trackId.

If we still want to expose stream identifiers that more properly belongs to the sender and receiver state as a sequence<DOMString> streamIdentifiers. The webrtc-pc spec has shied away from streams for a while now so these might not be very interesting but that would be the right way to do it.

[jan-ivar]

Firefox has not yet implement "track" stats, so we'd be OK with obsoleting them.

But we should check with @vr000m who I believe was the proponent of keeping "track" stats sender-side (with differently-offset packet and byte counters from the corresponding "sender" stats), as well as having statsended fire with "track" stats whenever a sender's track is removed or replaced (e.g. with replaceTrack).

[jan-ivar]

if we are moving "tracks" Obsolete stats section then we could do the same for "stream".

👍 I've filed #365.

We also have to delete trackIdentifier from senders and receivers.

Not necessarily. trackIdentifier is different from trackId.

trackIdentifier is sender.track.id or receiver.track.id respectively, and useful for locating stats when you have a track.

[vr000m]

From the discussion above, it seems we are leaning on a Yes, there must be receiver stats. It is an orthogonal discussion if the track stats should be deprecated.

We can make some tests on replace track, simulcast, and SVC tracks and observe if it breaks anything. If senders cover the trackability/diagnostics in these situations, I am happy to get rid of the tracks.

[vr000m]

Related to #402

[henbos]

TPAC decision: Add receiving "track" stats to the obsolete section.