add fractionLost stats in RTCInboundRtpStreamStats

[bdrtc]

It seems there is no field describe packet loss rate of specfic audio/video inbound rtp stream,
the fractionLost field exist in RTCRemoteInboundRtpStreamStats, but it‘s about outbound loss rate.
packet loss rate is a common stats for rtc system，and it's calculated at rtp receiver(inbound), i think it’s necessary to import this to RTCinbounRtpStreamStats at rtp receiver side.

[vr000m]

There are two ways of calculating fractionLost:

1. using the difference of packetsLost over packetsReceived between two getStats calls.
2. Expose what the receiver calculates to send in the RTCP RR.

The (1) is already possible. For (2) the main issue is the timestamp reported in the object is based on the latest snapshot and not the timestamp when the RTCP RR was created.

We have discussed variations of this in #255 #283

[bdrtc]

yes, we calc fractionLost via 1 before, but we think fractionLost is more important ,it should be in standard getStats :>.

[vr000m]

Curious why the measurement in (1) would not be sufficient? Especially, if the receiver is making a local decision based on the data that it can calculate.

On further thought, one reason that I could see is if you want to correlate fractionLost received in RTCP RR at the sender (in inbound-remote, the same place we have roundTripTime) with what was measured at the receiver. For this case, I would need clarification from the current implementors-- does Chrome/Firefox keep a running counter for fractionLost or only calculate the metric when the RTCP RR is sent? The former case would not help correlate, but the latter will need an RTCP RR timestamp in addition to the fractionLost metric?

cc: @henbos @jan-ivar

[bdrtc]

as title described: suggest add fractionLost stats in RTCInboundRtpStreamStats, as rtp receiver, fractionLost field exist in RTCP RR and is calculated every RTCP RR internal, we just need export it to RTCInboundRtpStreamStats.

using the difference of packetsLost over packetsReceived between two getStats calls.
yes, user can manually calculate like this, but it leaving the user to Implement complexity, and does not align with existing fields in rtcremoteinboundrtpstreamstats.

just as fractionLost exist in rtcremoteinboundrtpstreamstats currently, it's filled via remote send RTCP RR.

This is just a personal opinion on improve this stats, discuss the feasibility with you.
Thanks :>

[balazskreith]

Though it is a derived metric that can be calculated by other already reported metrics, as this field is already surfaced in other stats it makes total sense to add this field too in order to avoid ambiguity. Or destroy the current surfaced fractional loss metric. Either way, confusion should be avoided.

[vr000m]

Remote inbound is at the sender and based on receiving an RTCP RR, the object is only updated when the RTCP RR is received. So there's is no ambiguity on when the data in the object is updated.

For exposing the stat on the receiver, it needs to be clarified when the fractionLost metric is updated, each time the snapshot is created, i.e., getStats() is called or when the RTCP RR is generated and sent. If it is the former, then yes -- adding the metric is fairly straightforward. However, if it's the latter, we will need to expose a rtcp send timestamp to indicate when the fractionLost metric was calculated. If there was other uses for the rtcpTimestamp, the case for the latter would indeed be more compelling.

Is there a patch for exposing this metric in Chrome or Firefox?