search for: opusprojectionencod

..._ctl_va_list() calls, I believe the convention is for va_start() and va_end() to appear in the caller rather than in in the va_list() function itself. 3) I'm not sure I understand why the opus_copy_channel_out*() functions had to be moved. 4) OpusPEncoder: I'd prefer a more explicit name: OpusProjectionEncoder 5) Do you need to expose the "generic" opus_projection_encode() and opus_projection_encode_float() in the API? 6) In mapping_matrix_multiply_float(), for the !FIXED_POINT case you're multiplying by (1.f / 32768.f), but I think in the FIXED_POINT case, you should instead >>15...

...st() function itself. *My understanding is that it's impossible to pass ellipsis to another function.* 3) I'm not sure I understand why the opus_copy_channel_out*() functions had to be moved. *Not sure how that happened. Reverted.* 4) OpusPEncoder: I'd prefer a more explicit name: OpusProjectionEncoder *Done.* 5) Do you need to expose the "generic" opus_projection_encode() and opus_projection_encode_float() in the API? *I'm confused... How else would people be able to encode a packet of audio using the projection encoder? * 6) In mapping_matrix_multiply_float(), for the !FIXE...

...a_start() > and va_end() to appear in the caller rather than in in the va_list() > function itself. > > 3) I'm not sure I understand why the opus_copy_channel_out*() functions > had to be moved. > > 4) OpusPEncoder: I'd prefer a more explicit name: OpusProjectionEncoder > > 5) Do you need to expose the "generic" opus_projection_encode() and > opus_projection_encode_float() in the API? > > 6) In mapping_matrix_multiply_float(), for the !FIXED_POINT case you're > multiplying by (1.f / 32768.f), but I think in the F...

Hello all, Attached is an up-to-date patch for supporting channel mapping 253. Please advise and Thank you for your time. Cheers, Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170919/055d9034/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name:

...ear in the caller rather than in in the va_list() > > function itself. > > > > 3) I'm not sure I understand why the opus_copy_channel_out*() > functions > > had to be moved. > > > > 4) OpusPEncoder: I'd prefer a more explicit name: > OpusProjectionEncoder > > > > 5) Do you need to expose the "generic" opus_projection_encode() and > > opus_projection_encode_float() in the API? > > > > 6) In mapping_matrix_multiply_float(), for the !FIXED_POINT case > you're > > multiplying by (1.f...

...gt; va_list() > > function itself. > > > > 3) I'm not sure I understand why the opus_copy_channel_out*() > functions > > had to be moved. > > > > 4) OpusPEncoder: I'd prefer a more explicit name: > OpusProjectionEncoder > > > > 5) Do you need to expose the "generic" > opus_projection_encode() and > > opus_projection_encode_float() in the API? > > > > 6) In mapping_matrix_multiply_float(), for the !FIXED_POINT > case you're...

Hi Drew, I think the libopusenc patch is better, but there's still a few issues left: 1) The static MAX_PACKET_BUFFER_SIZE value is still problematic because if you link libopusenc with a new version of libopus that supports higher order projection or just more projection channels for order 3, then you will overflow the buffer. I think what you'd want is a _ope_opus_header_get_size() call

...ping)) + { + len=27+(h->channels*(h->nb_streams+h->nb_coupled)*2); + } + else + { + len=27+h->channels; + } The fixed part of the header is 19 bytes; where does the 27 come from here? +struct OpusGenericEncoder { + OpusMSEncoder *ms; +#ifdef OPUS_HAVE_OPUS_PROJECTION_H + OpusProjectionEncoder *pr; +#endif + int family; +}; opus_multistream.h needs to be included for OpusMSEncoder. opus_projection.h can't be relied upon to include it since opus_projection.h may not be available. +OpusGenericEncoder *_oge_surround_create( + int Fs, int channels, int channel_mapping, int *nb_s...