- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Jul 2017 12:57:32 +0000
- To: public-webrtc-logs@w3.org
@vr000m Happy to hear it makes sense! > Do the sender track stats in the case of hold keep increasing (across all implementations)? Well, stats report on implementation performance, which is generally not spec'ed, and why we have stats. We see that for instance in [sending a disabled track](https://blog.mozilla.org/webrtc/fiddle-week-spec-compliant-getstats/), where some browsers send 1 frame per second for video, while others send 30. That said, "hold" in the spec example renegotiates to "inactive" or "recvonly", so stats would reflect however browsers implement that. I believe they're barred from sending frames in that case, so you should see `framesSent` stop. But would `framesCaptured` stop? [It](https://w3c.github.io/webrtc-stats/#dom-rtcmediastreamtrackstats-framescaptured) doesn't even say if it stops for `!track.enabled`, so that seems out of scope / implementation dependent. > I think the local track stats make sense in this case to know if this are being sent or not I believe "sender" should tell you the same thing, assuming you know what you're sending. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/231#issuecomment-314760961 using your GitHub account
Received on Wednesday, 12 July 2017 12:57:37 UTC