[webrtc-stats] Rethinking RTCOutboundRtpStreamStats.targetBitrate (#416)

henbos has just created a new issue for https://github.com/w3c/webrtc-stats:

== Rethinking RTCOutboundRtpStreamStats.targetBitrate ==
Knowing something about the target encode bitrate is important, for example when debugging issues related to too large frames being encoded.

The current definition of [targetBitrate](https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-targetbitrate) is:

> It is the current target bitrate configured for this particular SSRC and is the Transport Independent Application Specific (TIAS) bitrate [RFC3890]. Typically, the target bitrate is a configuration parameter provided to the codec's encoder and does not count the size of the IP or other transport layers like TCP or UDP. It is measured in bits per second and the bitrate is calculated over a 1 second window.

Two problems:
- Measuring the bitrate over a 1 second window is not what implementations necessarily should do. Chrome doesn't. We should not force implementation strategies about when this bitrate can and cannot update the target.
- This is a bitrate. If an application would like calculate the difference between target and actual bytes produced, there is no way to do this. You would have to estimate target total bytes based on bitrate and compare to total bytes sent. Why doesn't the stat provide accumulative counters instead?

**Proposal**
Replace targetBitrate with targetTotalBytesEncoded, to be defined as:

> The total number of bytes the encoder would have produced if it exactly matched the configured target. In reality, the actual number of bytes may be higher or lower on a frame-by-frame basis. This value is updated each time a frame has been encoded.

This definition is agnostic towards when or how the target is updated, the counter would go up with whatever the target was for each frame, which makes it directly comparable to bytesSent.

Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/416 using your GitHub account

Received on Wednesday, 3 April 2019 09:24:58 UTC