AcmReceiver: Look up last decoder in NetEq's table of decoders

webrtc/modules/audio_coding/neteq/neteq_impl.cc

Index: webrtc/modules/audio_coding/neteq/neteq_impl.cc
diff --git a/webrtc/modules/audio_coding/neteq/neteq_impl.cc b/webrtc/modules/audio_coding/neteq/neteq_impl.cc
index 9c4f5809068f8964ef74882c0414f184ce37eef0..71eea2114c2d3892e13d160ba43d8e700e20dea7 100644
--- a/webrtc/modules/audio_coding/neteq/neteq_impl.cc
+++ b/webrtc/modules/audio_coding/neteq/neteq_impl.cc
@@ -431,6 +431,27 @@ int NetEqImpl::last_output_sample_rate_hz() const {
   return last_output_sample_rate_hz_;
 }
 
+rtc::Optional<CodecInst> NetEqImpl::GetDecoder(int payload_type) const {
+  rtc::CritScope lock(&crit_sect_);
+  const DecoderDatabase::DecoderInfo* di =
+      decoder_database_->GetDecoderInfo(payload_type);
+  if (!di) {
+    return rtc::Optional<CodecInst>();
+  }
+
+  // Create a CodecInst with some fields set. The remaining fields are zeroed,
+  // but we tell MSan to consider them uninitialized.
+  CodecInst ci = {0};
+  rtc::MsanMarkUninitialized(rtc::MakeArrayView(&ci, 1));
+  ci.pltype = payload_type;
+  std::strncpy(ci.plname, di->name.c_str(), sizeof(ci.plname));
+  ci.plname[sizeof(ci.plname) - 1] = '\0';
+  ci.plfreq = di->IsRed() || di->IsDtmf() ? 8000 : di->SampleRateHz();

[ossu, 2016/09/16 11:39:32]

This looks like a place where something might go wrong in the confluence of my
(upcoming) changes to DecoderDatabase, these changes, and solenberg's change
adding DTMF support at other clockrates. I'm not certain what, if anything, can
be done about this right here and now, though.

[kwiberg-webrtc, 2016/09/16 11:50:38]

It sounds like my best strategy is to land this quickly, then, so that I won't
be the one sitting with a broken CL when the dust settles. :-)

Seriously though, adding support for multiple DTMF clockrates would probably
involve letting NetEq keep track of the DTMF clockrate, meaning we could
actually get rid of one of the two special cases here. ...see, a perfectly
rational-sounding reason for why I should land this CL as-is. :-)

[ossu, 2016/09/16 11:55:59]

Hmm. I think di->GetFormat().clockrate_hz instead of 8000 should keep you safe
including upcoming changes.

[kwiberg-webrtc, 2016/09/16 12:04:20]

No, because (1) that's the RTP timestamp rate, not the sample rate (since it's
taken directly from the SdpAudioFormat), and (2) GetFormat() only works if the
DecoderInfo was created from a NetEqDecoder that makes
RentACodec::NetEqDecoderToSdpAudioFormat return a non-empty value.

[ossu, 2016/09/16 12:10:06]

Yes, but for DTMF the clockrate == sample rate, so that would be correct. For
RED, though, that would probably not work. :/ Should this method really return a
non-empty value for RED?

+  AudioDecoder* const decoder = di->GetDecoder();
+  ci.channels = decoder ? decoder->Channels() : 1;
+  return rtc::Optional<CodecInst>(ci);
+}
+
 int NetEqImpl::SetTargetNumberOfChannels() {
   return kNotImplemented;
 }