- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Fri, 06 May 2022 10:27:41 +0000
- To: public-webrtc-logs@w3.org
No I think you need a new metric for this. Just wondering if this metric should or should not be exposed in JavaScript and which dictionary it belongs to. If this is C++ only behavior we can add an RTCNonStandardStatsMember, but if this is a control surface that translates into what we can do in JavaScript, we could consider an RTCStatsMember. Is your use case Web or Native? The spec way to limit bitrate is with [RTCRtpEncodingParameters.maxBitrate](https://w3c.github.io/webrtc-pc/#dom-rtcrtpencodingparameters-maxbitrate), but this is on a per RTP stream basis. For example you could limit one RTP stream but not another. In that case exposing the bitrate limit on a per-stream basis makes sense, e.g. "RTCOutboundRtpStreamStats.maxBitrate". But are you referring to [PeerConnectionInterface::SetBitrate](https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/api/peer_connection_interface.h;l=1148?q=PeerConnectionInterface&originalUrl=https:%2F%2Fcs.chromium.org%2F)? In this case I wonder if this is trickling down the bitrate limitation to all outbound RTP streams (same as calling maxBitrate on all of them and "RTCOutboundRtpStreamStats.maxBitrate" still makes sense), or if the bitrate is dynamically adjusted for the transport, in which case we need a separate maxBitrate metric on the RTCTransportStats. Or if this truly is an RTCPeerConnection-wide limitation, in which case the metric belongs to the RTCPeerConnectionStats. Can you clarify the scope of the bitrate limitation? :) -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-provisional-stats/issues/22#issuecomment-1119473750 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 6 May 2022 10:27:42 UTC