henbos

Thanks for filing this issue, the lifetime issue deserves more attention. See https://github.com/w3c/webrtc-stats/pull/628#issuecomment-1159405398 regarding what happened and me filing an issue to make sure sender/receiver/transceiver gets its spot in the...

Update: sender/receiver/transceiver stats got added back to the provisional spec, see https://github.com/w3c/webrtc-provisional-stats/issues/32#issuecomment-1164198553

Regarding this issue... ### Topic A: When should RTP stream stats objects be created? Arguments in favor of adding sender/receiver/transceiver instead of creating RTP stream stats objects early: - It...

Here's another mind bender: what if you start out sending simulcast on ssrc 1 and 2 and then you change to send SVC on ssrc 1... what happens to ssrc...

I don't think sender/receiver/transceiver objects add enough information to justify adding more objects to the stats report, so I propose we don't add them back to webrtc-stats 1.0. If people...

I'm leaning towards Proposal 1.B and Proposal 2.B. Any thoughts or objections, @alvestrand @vr000m @jan-ivar ?

> Isn't 1A implemented? Or are the objects created by the receiver ahead of time? On second thought, yes 1.A is already implemented ([link](https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/pc/rtc_stats_collector.cc;l=1924;drc=2330c1533e39e4f8c195b0a2a05802ea9dee9c85)). I revise my vote to 1.A...

What about when a receiver is reconfigured for a different ssrc? Spec says to never delete the ssrc stats object, but the implementation does not cache data from old streams,...

Let's follow up in #667 and #668

I agree, for exact 1 second window frames this is already available by looking at delta total counters. This FPS is mostly for convenience and it looks like the libwebrtc...