search

w3c / webrtc-provisional-stats

https://w3c.github.io/webrtc-provisional-stats/
Other
7 stars 11 forks source link

Add sender/receiver/transceiver to provisional spec #32

Closed henbos closed 2 years ago

henbos commented 2 years ago

These got lost on the way when mid and trackIdentifier got added to the rtp stats but there has been discussions around if these are still needed due to lifetime differences with rtp stats

henbos commented 2 years ago

With the flattening of the hierarchies (reflecting track stats being obsolete) we can add sender/receiver/transceiver back.

I would add them back as standalone dictionaries since track stats are obsolete anyway, but if we for historical reasons want to document the old track tie we can make the dictionaries extend RTCMediaStreamTrackStats

henbos commented 2 years ago

(The historical connection is that track stats were per attachment but the same metrics also existed per lifetime of the sender. Nowadays all the track metrics exist per RTP stream. Having RTP metrics on something other than an RTP stream didn’t make sense and was made obsolete)

henbos commented 2 years ago

I merged PR #34 as previously discussed, which added back the sender/receiver/transceiver dictionaries to the provisional spec (see https://w3c.github.io/webrtc-provisional-stats/#RTCRtpTransceiverStats-dict*).

But before I close this issue, please take a look @jan-ivar @vr000m @alvestrand.

I want to be perfectly clear that when I added back sender and receiver I did not have these dictionaries extend RTCMediaStreamTrackStats so this is technically not just editorial.

The reason I did not make them extend "track" is because that dictionary is obsolete. We could certainly have them extend "track" stats in order for this to be a purely editorial change (let me know and I will create a PR) but the reason I did not do this is because a) nobody ever implemented this and it would only serve to document git history, and b) having sender extend track is horribly under-specified and makes absolutely no sense for simulcast stats. It seems like a silly maintenance burden to have the sender extend the obsolete track in a provisional stats spec, and not extending receiver with track stats is the consistent thing to do.

Let me know if I can close this.

henbos commented 2 years ago

Follow-up: #35.

vr000m commented 2 years ago

Given track stats were only visible in Chrome for a bit but not implemented by anyone else. further, track stats were deprecated, I see no reason for the provisional stats to inherit from track stats. And the linkability/discoverability of inbound/outbound streams is discussed in #35

henbos commented 2 years ago

Thanks, closing this. #35 for the remaining follow up