search for: opusprojectiondecoder

...macro, multiplication may overflow if int is 16 bits. > One of the operands of the multiplication should be cast to opus_int32 > in such cases to ensure a 32-bit multiply and avoid overflow. > > Done. > 4) get_multistream_decoder: align() must be applied separately to > sizeof(OpusProjectionDecoder) and st->demixing_matrix_size_in_bytes > since they may each have padding. Including the alignment padding in > demixing_matrix_size_in_bytes as in (5) avoids the second call to > align(). Similarly in opus_projection_decoder_get_size, align() > should just be applied to sizeof(Opu...

...y_short, and even in the MATRIX_INDEX macro, multiplication may overflow if int is 16 bits. One of the operands of the multiplication should be cast to opus_int32 in such cases to ensure a 32-bit multiply and avoid overflow. 4) get_multistream_decoder: align() must be applied separately to sizeof(OpusProjectionDecoder) and st->demixing_matrix_size_in_bytes since they may each have padding. Including the alignment padding in demixing_matrix_size_in_bytes as in (5) avoids the second call to align(). Similarly in opus_projection_decoder_get_size, align() should just be applied to sizeof(OpusProjectionDecoder);...

...verflow if int is 16 bits. > One of the operands of the multiplication should be cast to opus_int32 > in such cases to ensure a 32-bit multiply and avoid overflow. > > Done. >   > >  4) get_multistream_decoder: align() must be applied separately to > sizeof(OpusProjectionDecoder) and st->demixing_matrix_size_in_bytes > since they may each have padding.  Including the alignment padding in > demixing_matrix_size_in_bytes as in (5) avoids the second call to > align().  Similarly in opus_projection_decoder_get_size, align() > should just be appli...

On 11/09/2017 01:58 PM, Drew Allen wrote: > Attached is a quick patch that addresses a bug when exporting the matrix > from the encoder. Actually, I don't see what your encoder change is supposed to do. Are there cases where demixing_matrix->rows != nb_output_streams ? Cheers, Jean-Marc > Cheers, > Drew > > On Wed, Nov 8, 2017 at 4:44 PM Drew Allen <bitllama at

...x, so I would lean towards a graceful fail in that case. > > Similarly, changing the argument to op_decode_cb_func also breaks ABI. One > way to avoid this might be to add an op_set_projection_decode_callback() > function, which takes a new callback function pointer that takes the > OpusProjectionDecoder instead. Then an application would register both > callbacks, and libopusfile would call the correct one for the current link > in the file. If you have an ambisonics link, but no projection callback > registered, then it simply wouldn't call a decode callback for packets in > that...

Hello all, Attached are patches for libopusenc, opusfile and opus-tools in order to provide support for Ambisonics and the Projection API for encoding/decoding channel mapping 253 and 254. Please feel free to ask any questions or give any feedback you might have. :) Cheers, Drew -------------- next part -------------- An HTML attachment was scrubbed... URL:

...lease don't store pointers (MappingMatrix, OpusMSEncoder, ...) in > the OpusPEncoder/OpusPDecoder structs. All the data should be in a > single struct with no pointers (except to constant data) so that they > can be shallow-copied. > > *Done.* Well, I still see pointers in your OpusProjectionDecoder. Cheers, Jean-Marc > On Wed, Oct 4, 2017 at 10:30 AM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > Hi Drew, > > Here's some comments on your patch (in no particular order): > > 1) I see that it's ad...

...the > mappingmatrix struct. Note that we include the struct size when computing > the multistream decoder pointer in get_multistream_decoder(). > I will make it opus_int32 though. Where in get_multistream_decoder() does it include the size of struct MappingMatrix? It only includes sizeof(OpusProjectionDecoder) and st->demixing_matrix_size_in_bytes, neither of which includes the size of struct MappingMatrix. And if you're not going to use mapping_matrix_get_size() then you'll also need to include the alignment padding after the matrix data separately from alignment padding on each of the two...

...in the mapping[] array that existing callers would do something sane with?). Similarly, changing the argument to op_decode_cb_func also breaks ABI. One way to avoid this might be to add an op_set_projection_decode_callback() function, which takes a new callback function pointer that takes the OpusProjectionDecoder instead. Then an application would register both callbacks, and libopusfile would call the correct one for the current link in the file. If you have an ambisonics link, but no projection callback registered, then it simply wouldn't call a decode callback for packets in that link. That behav...

...appingMatrix, OpusMSEncoder, ...) in > > the OpusPEncoder/OpusPDecoder structs. All the data should be in a > > single struct with no pointers (except to constant data) so that they > > can be shallow-copied. > > > > *Done.* > > Well, I still see pointers in your OpusProjectionDecoder. > > Cheers, > > Jean-Marc > > > On Wed, Oct 4, 2017 at 10:30 AM Jean-Marc Valin <jmvalin at jmvalin.ca > > <mailto:jmvalin at jmvalin.ca>> wrote: > > > > Hi Drew, > > > > Here's some comments on your patch (in no pa...

...er, ...) in > > the OpusPEncoder/OpusPDecoder structs. All the data should be in a > > single struct with no pointers (except to constant data) so that they > > can be shallow-copied. > > > > *Done.* > > Well, I still see pointers in your OpusProjectionDecoder. > > Cheers, > > Jean-Marc > > > On Wed, Oct 4, 2017 at 10:30 AM Jean-Marc Valin > <jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca> > > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>> wrote: &gt...

Hi Drew, Here's some comments on your patch (in no particular order): 1) I see that it's adding an #include of stdarg.h to opus_multistream.h Is that left over from the previous version? 2) Someone on this list might know better than I do on that one, but for the new _ctl_va_list() calls, I believe the convention is for va_start() and va_end() to appear in the caller rather than in in