Creating controller manager from config string in audio network adaptor.

webrtc/modules/audio_coding/audio_network_adaptor/controller_manager.h

Index: webrtc/modules/audio_coding/audio_network_adaptor/controller_manager.h
diff --git a/webrtc/modules/audio_coding/audio_network_adaptor/controller_manager.h b/webrtc/modules/audio_coding/audio_network_adaptor/controller_manager.h
index c2ac9e35efbf9a42ca1cea1cb6da8d94202ef862..344c39e3991ec20689237ba545d7e435d54d1a84 100644
--- a/webrtc/modules/audio_coding/audio_network_adaptor/controller_manager.h
+++ b/webrtc/modules/audio_coding/audio_network_adaptor/controller_manager.h
@@ -45,6 +45,17 @@ class ControllerManagerImpl final : public ControllerManager {
     const Clock* clock;
   };
 
+  static std::unique_ptr<ControllerManager> Create(
+      const std::string& config_string,

[kwiberg-webrtc, 2016/09/28 08:59:22]

Is this the protobuf? In that case, isn't there a way to pass it around without
serializing it? You want the flexibility and version support of a protobuf, but
since you're not sending it outside the process, you shouldn't be encoding it, I
think. (Caveat: I know little about protobuf in particular; this is reasoning
from how I assume it probably works.)

[minyue-webrtc, 2016/09/28 12:47:26]

Serializing makes cross-platform/language possible. That is an advantage we want
to achieve here.

[kwiberg-webrtc, 2016/09/28 13:10:24]

But that argues for serialization at language and process boundaries, right? Not
anywhere else? And this isn't such a boundary?

[minyue-webrtc, 2016/09/28 16:32:34]

This is also because we want to limit the use of protobuf, which may be
unavailable. So by serializing it here, we let all middle layers carry a generic
type (string).

+      size_t num_encoder_channels,
+      const std::vector<int>& encoder_frame_lengths_ms,

[michaelt, 2016/09/27 15:51:26]

we could pass a array_view here. Since the supported frame lengths from the
encoder will be const.

[minyue-webrtc, 2016/09/27 19:43:59]

good. with do.

[hlundin-webrtc, 2016/09/27 20:21:15]

I wouldn't mind keeping this like this. It keeps us out of liftetime management
problems at a low cost.

[kwiberg-webrtc, 2016/09/28 08:59:22]

ArrayView is the right choice here; it wouldn't cause any lifetime problems.
Both ArrayView and const vector& are things the callee can read from (and copy)
but not save a pointer to or steal. The difference is that ArrayView doesn't
dictate how the caller must have allocated the array.

[minyue-webrtc, 2016/09/28 12:47:26]

Done.

+      size_t intial_channels_to_encode,
+      int initial_frame_length_ms,
+      int initial_bitrate_bps,
+      bool initial_fec_enabled,
+      bool initial_dtx_enabled,
+      const Clock* clock);
+
   explicit ControllerManagerImpl(const Config& config);
 
   // Dependency injection for testing.