opus - May 2016 - [PATCH] Add Functions to Create Ambisonic Multistream Encoder

This patch adds top level functions to create an ambisonic multistream
encoder. The implementation currently just calls the analogous
surround sound functions with channel mapping 255 to create an encoder
that bundles uncoupled streams. Forthcoming patches will actually set
channel bitrate and other configuration.

My main concern is that adding additional
opus_multistream_*_encoder_create/init/get_size functions is
unnecessary. Should we instead just add new channel mappings to
opus_multistream_surround_encoder_*, despite the name?

Thanks,
Michael Graczyk
-------------- next part --------------

Hi Michael,

Is there any reason you can't just use the generic multi-stream API,
i.e. opus_multistream_encoder_init() and give it the mapping you need?
This is how surround was originally done (in 1.0) and only got changed
when surround needed a more complex mapping and more data in the
encoder. If it turns out you need this kind of thing too, then yes we
would probably just want to extend the
opus_multistream_surround_encoder_*() calls since they already take a
family argument.

Cheers,

	Jean-Marc

On 05/04/2016 06:24 PM, Michael Graczyk wrote:
> This patch adds top level functions to create an ambisonic multistream
> encoder. The implementation currently just calls the analogous
> surround sound functions with channel mapping 255 to create an encoder
> that bundles uncoupled streams. Forthcoming patches will actually set
> channel bitrate and other configuration.
> 
> My main concern is that adding additional
> opus_multistream_*_encoder_create/init/get_size functions is
> unnecessary. Should we instead just add new channel mappings to
> opus_multistream_surround_encoder_*, despite the name?
> 
> Thanks,
> Michael Graczyk
> 
> 
> 
> _______________________________________________
> opus mailing list
> opus at xiph.org
> http://lists.xiph.org/mailman/listinfo/opus
>

Jean-Marc,
> Is there any reason you can't just use the generic multi-stream API,
> i.e. opus_multistream_encoder_init() and give it the mapping you need?
I would like the encoder to make decisions based on the fact that the
audio is Ambisonics. For example, the bitrate allocation should not be
the same for every channel. The original multistream API does not
provide a way to pass in mapping family so I don't know how we could
signal "ambisonics" to the
> If it turns out you need this kind of thing too, then yes we
> would probably just want to extend the
> opus_multistream_surround_encoder_*() calls since they already take a
> family argument.
Alright, that is simpler. I can modify the patch to simply add
"mapping_family == 2" to the allowed values in the surround encoder
functions.