search for: demix

Move demixing matrix defines to opus_define to better determine availability of Projection API. Allows libopusenc, opusfile and opus-tools to much more easily determine availability of Projection API. Cheers, Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lis...

...gt; I suspect with the current set of patches you might have problems with > case 3) since you will find the symbols in the header file, but the > functionality won't be there. > > Cheers, > > Jean-Marc > > On 03/07/2018 02:40 PM, Drew Allen wrote: > > Move demixing matrix defines to opus_define to better determine > > availability of Projection API. > > > > Allows libopusenc, opusfile and opus-tools to much more easily determine > > availability of Projection API. > > > > Cheers, > > Drew > > > > > &...

...opus master (or 1.3-beta) with --disable-ambisonics I suspect with the current set of patches you might have problems with case 3) since you will find the symbols in the header file, but the functionality won't be there. Cheers, Jean-Marc On 03/07/2018 02:40 PM, Drew Allen wrote: > Move demixing matrix defines to opus_define to better determine > availability of Projection API. > > Allows libopusenc, opusfile and opus-tools to much more easily determine > availability of Projection API. > > Cheers, > Drew > > > __________________________________________...

...ent set of patches you might have problems with > case 3) since you will find the symbols in the header file, but the > functionality won't be there. > > Cheers, > >         Jean-Marc > > On 03/07/2018 02:40 PM, Drew Allen wrote: > > Move demixing matrix defines to opus_define to better determine > > availability of Projection API. > > > > Allows libopusenc, opusfile and opus-tools to much more easily > determine > > availability of Projection API. > > > > Cheers, >...

Friendly ping for supporting ambisonics in opus-tools & opusfile Please LMK any ?s you might have. Cheers, Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20180410/fd4a3709/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name:

...t, it duplicates a lot of code from opus_head_parse(), the user still needs to call opus_head_parse() (so the work gets duplicated at runtime, too), and they have to pass in a buffer of exactly the right size (which means they need to know some details of the specific mapping family and how the demixing matrix works). I think a slightly better approach is along the lines of the opus_head_parse_ext() I originally suggested, but just return a pointer into the user-supplied packet instead of copying the data. For the simple case where the user is just going to pass the data immediately to opu...

...lo all, Attached is the initial proposed implementation for ch.mapping 253/3, based on the IETF proposal: https://tools.ietf.org/html/draft-ietf-codec-ambisonics-03 A brief overview of the patch, as it is slightly lengthy: After discussion with Jean-Marc, we determined that ch.253/3 will need the demixing matrix as part of the encoder/decoder struct stack and thus will require a new Encoder/Decoder structure. For this, I've proposed OpusPEnc/OpusPDec (for "projection"), which wraps OpusMSEnc/OpusMSDec aside from the addition of the mixing matrix structure. The functionality also wra...

...ng 253/3, > based > > on the IETF proposal: > > https://tools.ietf.org/html/draft-ietf-codec-ambisonics-03 > > > > A brief overview of the patch, as it is slightly lengthy: > > After discussion with Jean-Marc, we determined that ch.253/3 will need > the > > demixing matrix as part of the encoder/decoder struct stack and thus will > > require a new Encoder/Decoder structure. For this, I've proposed > > OpusPEnc/OpusPDec (for "projection"), which wraps OpusMSEnc/OpusMSDec > aside > > from the addition of the mixing matrix st...

...sal: >>> > https://tools.ietf.org/html/draft-ietf-codec-ambisonics-03 >>> > >>> > A brief overview of the patch, as it is slightly lengthy: >>> > After discussion with Jean-Marc, we determined that ch.253/3 will need >>> the >>> > demixing matrix as part of the encoder/decoder struct stack and thus >>> will >>> > require a new Encoder/Decoder structure. For this, I've proposed >>> > OpusPEnc/OpusPDec (for "projection"), which wraps OpusMSEnc/OpusMSDec >>> aside >>> &...

...ial proposed implementation for ch.mapping 253/3, based > on the IETF proposal: > https://tools.ietf.org/html/draft-ietf-codec-ambisonics-03 > > A brief overview of the patch, as it is slightly lengthy: > After discussion with Jean-Marc, we determined that ch.253/3 will need the > demixing matrix as part of the encoder/decoder struct stack and thus will > require a new Encoder/Decoder structure. For this, I've proposed > OpusPEnc/OpusPDec (for "projection"), which wraps OpusMSEnc/OpusMSDec aside > from the addition of the mixing matrix structure. The functio...

...) { > > int ret; > > int i; > > > > This code is allowing family 253 for a deferred init, but does not > > create a projection encoder in that case, so it looks like it will > > fail when writing the id header since it won't be able to get the > > demixing matrix. It should probably not be allowing family 253 here. > > Actually, in the case of ope_encoder_deferred_init_with_mapping(), I > think it's probably best to just keep the existing code (not use > wrappers), since that function cannot be used by the projection encoder >...

...8000, enc->channels, streams, coupled_streams, mapping, OPUS_APPLICATION_AUDIO, &ret); This code is allowing family 253 for a deferred init, but does not create a projection encoder in that case, so it looks like it will fail when writing the id header since it won't be able to get the demixing matrix. It should probably not be allowing family 253 here. - Mark On Mon, Mar 19, 2018 at 3:00 PM, Drew Allen <bitllama at google.com> wrote: > Hi Jean-Marc, > > I've modified my patches for libopus and libopusenc based on your > suggestions. > > Cheers, > Dr...

...; > on the IETF proposal: >> > https://tools.ietf.org/html/draft-ietf-codec-ambisonics-03 >> > >> > A brief overview of the patch, as it is slightly lengthy: >> > After discussion with Jean-Marc, we determined that ch.253/3 will need >> the >> > demixing matrix as part of the encoder/decoder struct stack and thus >> will >> > require a new Encoder/Decoder structure. For this, I've proposed >> > OpusPEnc/OpusPDec (for "projection"), which wraps OpusMSEnc/OpusMSDec >> aside >> > from the additio...

...> > > > > > This code is allowing family 253 for a deferred init, but does not > > > create a projection encoder in that case, so it looks like it will > > > fail when writing the id header since it won't be able to get the > > > demixing matrix. It should probably not be allowing family 253 > here. > > > > Actually, in the case of ope_encoder_deferred_init_with_mapping(), I > > think it's probably best to just keep the existing code (not use > > wrappers), since that function cannot be...

...53 for a deferred init, but > > does not > > > > create a projection encoder in that case, so it looks like > > it will > > > > fail when writing the id header since it won't be able to > > get the > > > > demixing matrix. It should probably not be allowing family > > 253 here. > > > > > > Actually, in the case of > > ope_encoder_deferred_init_with_mapping(), I > > > think it's probably best to just keep the existing code (not > use...

...eplaced by an asssert or (if the user can cause a > failure) actually checked. > > Done. > 8) I see there's a "gain" field in the matrix, but I can't see it used > anywhere. Did I miss something? > Gain should be pulled out by the user via a OPUS_PROJECTION_GET_DEMIXING_MATRIX_GAIN call and add it to the overall output gain. We assume the mixing matrix gain is always zero and that this only matters for the output gain from the demixing matrix. > > 9) In get_streams_from_channels(), I think it'd be simpler to just replace: > *streams = channels / 2...

...#include around this #define. This will also allow us to not have to explicitly enable ambisonics. :) > > The addition of fields to the OpusHead struct is a breaking ABI change > (specifically, all callers of opus_head_parse() would need to be rebuilt > from source). > > Is OPUS_DEMIXING_MATRIX_SIZE_MAX future-proof? I seem to recall much > larger matrices being allowed according to the spec. You'll note that > OPUS_CHANNEL_COUNT_MAX is 255, even though opusfile currently only supports > mappings with up to 8 channels (see the private OP_NCHANNELS_MAX used > inte...

...does not >>> > > > create a projection encoder in that case, so it looks like >>> > it will >>> > > > fail when writing the id header since it won't be able to >>> > get the >>> > > > demixing matrix. It should probably not be allowing family >>> > 253 here. >>> > > >>> > > Actually, in the case of >>> > ope_encoder_deferred_init_with_mapping(), I >>> > > think it's probably best to j...

...eams, const unsigned char *mapping) { > int ret; > int i; > > This code is allowing family 253 for a deferred init, but does not > create a projection encoder in that case, so it looks like it will > fail when writing the id header since it won't be able to get the > demixing matrix. It should probably not be allowing family 253 here. Actually, in the case of ope_encoder_deferred_init_with_mapping(), I think it's probably best to just keep the existing code (not use wrappers), since that function cannot be used by the projection encoder at all. Jean-Marc &g...

...ually checked. > > > > Done. > > > > 8) I see there's a "gain" field in the matrix, but I can't see it > used > > anywhere. Did I miss something? > > > > Gain should be pulled out by the user via > > a OPUS_PROJECTION_GET_DEMIXING_MATRIX_GAIN call and add it to the > > overall output gain. We assume the mixing matrix gain is always zero and > > that this only matters for the output gain from the demixing matrix. > > > > > > 9) In get_streams_from_channels(), I think it'd be simpler to...