remove outbound-rtp totalEncodedBytesTarget

[fippo]

https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-totalencodedbytestarget is implemented by libwebrtc but returns 0. So far nobody has complained (but me but I complain about everything)

This doesn't offer much value over comparing targetBitrate to 8*bytesSent/second The difference is RTP packetization overhead which is a few bytes per RTP packet (or frame) which is depending on the codec and not modifiable in any way.

Additionally it poses some extra problems for encoded-transform. Since that operates on frames, adding encryption bytes to it should be accounted for in the totalEncodedBytesTarget. Which is a major headache given how this is currently implemented in libwebrtc at least.

Please vote with 👎 to remove or 👍 to keep

[henbos]

This was implemented at one point, so before removing it I would try to look into why it stopped working. Perhaps it broke in a refactoring and is easy to fix.

[henbos]

I think it got implemented in 2019 here and that it worked, but when implementing simulcast in 2020 here and total_encoded_bytes_target was supposedly moved from "per sender" VideoSendStream::Stats to "per layer" VideoSendStream::StreamStats it wasn't actually moved, just added and never touched. So we continued to set the value on the "per sender" stat but we began reading from the never-set "per layer" stat. The dangers of not using absl::optional<>.

I suggest filing a crbug since this may be easy to fix.

[fippo]

true, being 0 is indeed a regression between M84 where it broke and current M104.

[dontcallmedom]

@henbos / @fippo can one of you file the crbug and close this issue then?

[fippo]

the question whether it adds value over targetBitrate (implemented in Chrome as of today) remains

[henbos]

See https://github.com/w3c/webrtc-stats/issues/416 for motivation for totalEncodedBytesTarget despite targetBitrate existing at the time of adding it