webrtc-stats
webrtc-stats copied to clipboard
w3c
outbound-rtp.limited
In #597, we decided to expose whether or not the RTP stream is configured to be sent. However due to qualityLimitationReasons even a stream that is configured to send could be prevented from sending. Should we add an outbound-rtp.limited that can be true if it is prevented from sending even though active is also true?
Is there a difference between "prevented to be sent" and "target bitrate = 0"? I'm not sure we have all the moving pieces, but if we already have a per-stream targetBitrate and a per-stream qualityLimitationReason, we should have all the pieces present already to let the state be detected.
targetBitrate = 0 may work depending on the implementation - hoping there's no implementation that defaults this to 0 during ramp up time even though it is sending, I don't know what Chromium does.
limited has the benefit of being explicit and feature detectable, but we could make targetBitrate definition more explicit about this.
qualityLimitationReason does not say whether or not you are sending, only whether or not a limitation is occurring (e.g. could simply reduce resolution or frame rate without affecting sending). And while it may be possible do report something smart per-stream there, the implementation today reports the same QLR value for all outbound-rtps.
I wonder whether it is easier to just expose the opposite of limited -- sending without restrictions.
You might be limited for at least two reasons, bandwidth and cpu and then you might want to know why you are limited. You might further be limiting the number of temporal layers (which has an effect on the expected framerate) -- does this count as a limitation or not?
(lets wait with a PR until we have a POC implementation)
Anything that not only degrades but TURNS OFF an outbound RTP, despite it being "active = true", is in my opinion a limitation and what we want to measure. The only other case I can think of where sending might not be happening despite not being limited is if the transport is disconnected and all encoding is disabled on a transport-wide level or packets dropped later in the stack
SVC layers is something different than outbound-rtp streams, turning off SVC layers does not turn off the outbound-rtp (and if you want that, see https://github.com/w3c/webrtc-stats/pull/559) unless perhaps if all layers are turned off in which case you could say that the RTP stream is also off