Allow ANA to receive RPLR (recoverable packet loss rate) indications

webrtc/audio/audio_send_stream.cc

Index: webrtc/audio/audio_send_stream.cc
diff --git a/webrtc/audio/audio_send_stream.cc b/webrtc/audio/audio_send_stream.cc
index a146ceb8e977bc0d8f302dd665d2e46dff669f43..81aa63bc24c30fdfa9f88d327b05420c40b5ee65 100644
--- a/webrtc/audio/audio_send_stream.cc
+++ b/webrtc/audio/audio_send_stream.cc
@@ -11,6 +11,7 @@
 #include "webrtc/audio/audio_send_stream.h"
 
 #include <string>
+#include <vector>
 
 #include "webrtc/audio/audio_state.h"
 #include "webrtc/audio/conversion.h"
@@ -274,6 +275,7 @@ void AudioSendStream::OnNewTransportFeedbackVector(
   rtc::CritScope lock(&packet_loss_tracker_cs_);
   packet_loss_tracker_.OnNewTransportFeedbackVector(packet_feedback_vector);
   const auto plr = packet_loss_tracker_.GetPacketLossRate();
+  const auto rplr = packet_loss_tracker_.GetRecoverablePacketLossRate();
   // TODO(elad.alon): Resolve the following known issue - if PLR goes back

[ossu, 2017/03/22 13:41:18]

I guess you've considered this: it looks like at least the RPLR is gotten as an
Optional, then stripped and sent along as a float only to eventually be put back
into an Optional. Sending an Optional all the way would give you a way to
invalidate the measurement.

Not going to insist on that here, though. I believe hooking up directly to the
encoder is still the way to go.

[elad.alon_webrtc.org, 2017/03/22 15:15:55]

I did consider it - even had a CL for it
(https://codereview.webrtc.org/2746333009/) - but after both online and offline
discussion, had to abandon it and place this TODO here instead, for future
handling.

   // to unknown, no indication is given that the previously sent value is no
   // longer relevant. This will be taken care of with some refactoring which is
@@ -281,6 +283,9 @@ void AudioSendStream::OnNewTransportFeedbackVector(
   if (plr) {
     channel_proxy_->OnTwccBasedUplinkPacketLossRate(*plr);
   }
+  if (rplr) {

[stefan-webrtc, 2017/03/22 12:15:46]

Can plr and rplr be active simultaneously? Should we comment on why and how that
works? Maybe it's handled somewhere else

[minyue-webrtc, 2017/03/22 12:17:36]

Yes, plr will be used for frame length adaptation etc, rplr mainly for FEC
tuning.

[elad.alon_webrtc.org, 2017/03/22 15:15:55]

I'm not sure what comment would make things clearer. I mean, they are two
separate metrics, after all. Minyue has given a good example with the
controllers. I'll add that the values might even theoretically be used by
something other than ANA, once it's passed to Channel. Is there a specific
comment you'd recommend?

+    channel_proxy_->OnRecoverableUplinkPacketLossRate(*rplr);
+  }
 }
 
 const webrtc::AudioSendStream::Config& AudioSendStream::config() const {