Add individual rate adjustment per substream for Opus

[thirv]

This is an experimental tool that is useful for sound quality optimization. Open to suggestions about the UI etc. Also, not sure if this would somehow be a hindrance and is better left out.

Usage example in a .textproto config file:

codec_config_metadata {
  codec_config_id: 200
  codec_config {
    codec_id: CODEC_ID_OPUS
    num_samples_per_frame: 960
    audio_roll_distance: -4
    decoder_config_opus {
      version: 1
      pre_skip: 312
      input_sample_rate: 48000
      opus_encoder_metadata {
        target_bitrate_per_channel: 16000
        application: APPLICATION_AUDIO
        use_float_api: false
        use_substream_rate_override: true
        substream_rate_overrides: [64000, 57000, 30000, 9000]
      }
    }
  }
}

[jwcullen]

I think the proto may be better as

map<uint32, int32> substream_id_to_bitrate_override = 5;

In textproto it would look like.

# Substream ID 123 has a bitrate of 1000.
substream_id_to_bitrate_override {
key: 123
value: 1000 
}

This would be more reasonable if large substream IDs are used - which are generally supported elsewhere in the encoder.

I think in this case it makes sense to check presence of the substream in the map, and there does not need to be a use_substream_rate_override. When the substream is not present that implies it is not being overrided - using the "default" calculation would be reasonable.

[thirv]

Thanks for the help, was considering it but was not sure how maps worked here.

[jwcullen]

This introduces an error if encoder_metadata_.substream_rate_overrides()[substream_id_] goes out of bounds.

Before performing the lookup validate that it does not go out of bounds. At review time check against the size of the array. But if you take the "map"-based suggestion in another comment check that the substream_id is present.

I think if it would go out of bounds it is OK to fallback to the calculation based on target_bitrate_per_channels.

Same in the else.

[thirv]

Thanks for the help, was considering it but was not sure how maps worked here.

[jwcullen]

Do you imagine any use cases where application should vary per substream (or per audio element)?

I'm thinking of a use case where one audio element is music (best encoded as APPLICATION_AUDIO) and a second audio element is voice chat (best encoded as APPLICATION_VOIP).

If you think this would be useful, we may want to consider how we would handle this - even if it does not get implemented in this PR.

[thirv]

I personally don't see this as a critical addition right now; I'd think separate audio elements would be used in that case. But yeah, the need may materialize suddenly at some point.

[jwcullen]

Suggested change

	std::unique_ptr<EncoderBase>& encoder, int substream_id = NULL) {
	std::unique_ptr<EncoderBase>& encoder, int substream_id = 0) {