[opus] [PATCH] Support for Ambisonics

Drew Allen bitllama at google.com
Mon Mar 26 19:31:53 UTC 2018


Ok, this patch should work as the latest "Ambisonics" support patch for
opusfile.

Cheers,
Drew

On Mon, Mar 26, 2018 at 12:17 PM Drew Allen <bitllama at google.com> wrote:

> Apologies! That patch will not work correctly with Opus 1.2. Will send an
> updated patch shortly!!
>
> On Mon, Mar 26, 2018 at 11:56 AM Drew Allen <bitllama at google.com> wrote:
>
>> Hello all!
>>
>> I've attached an updated patch for opusfile, based on formatting
>> suggestions I got for the opus and libopusenc patches.
>>
>> Cheers!
>> Drew
>>
>> On Thu, Mar 22, 2018 at 9:19 AM Drew Allen <bitllama at google.com> wrote:
>>
>>> Thanks! 2 down, 2 to go. :D :D :D
>>>
>>> On Wed, Mar 21, 2018 at 11:19 PM Jean-Marc Valin <jmvalin at jmvalin.ca>
>>> wrote:
>>>
>>>> Thanks, the libopus and the libopusenc patches are now merged.
>>>>
>>>> Cheers,
>>>>
>>>>         Jean-Marc
>>>>
>>>> On 03/20/2018 12:36 PM, Drew Allen wrote:
>>>> > Attached is an updated patch based on Jean-Marc and Mark's comments.
>>>> :)
>>>> >
>>>> > Cheers,
>>>> > Drew
>>>> >
>>>> > On Tue, Mar 20, 2018 at 9:20 AM Jean-Marc Valin <jmvalin at jmvalin.ca
>>>> > <mailto:jmvalin at jmvalin.ca>> wrote:
>>>> >
>>>> >     On 03/20/2018 11:51 AM, Drew Allen wrote:
>>>> >     > Just to confirm, I would use opeint_* for all the
>>>> >     > OpusGenericEncoder-related functions?
>>>> >
>>>> >     Correct. Or you can also use oge_ if you like. Just don't use
>>>> something
>>>> >     that starts with an underscore.
>>>> >
>>>> >
>>>> >     > On Tue, Mar 20, 2018 at 8:38 AM Jean-Marc Valin
>>>> >     <jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>
>>>> >     > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>> wrote:
>>>> >     >
>>>> >     >     Hi Mark, Drew,
>>>> >     >
>>>> >     >     On 03/20/2018 02:40 AM, Mark Harris wrote:
>>>> >     >     > + int _oge_use_projection(int channel_mapping);
>>>> >     >     >
>>>> >     >     > These functions are part of libopusenc, so I'd expect them
>>>> >     to have an
>>>> >     >     > ope prefix like the other functions in the libopusenc
>>>> library.
>>>> >     >
>>>> >     >     I'd like to avoid using the ope_ prefix for functions that's
>>>> >     aren't in
>>>> >     >     the public API. Right now there are other functions with a
>>>> leading
>>>> >     >     underscore, so we'll have to fix them as well (not in this
>>>> >     patch of
>>>> >     >     course). Maybe an "opeint_" prefix would do the job here
>>>> >     (unless anyone
>>>> >     >     has a better idea)?
>>>> >     >
>>>> >     >     > +int ope_encoder_deferred_init_with_mapping(OggOpusEnc
>>>> *enc, int
>>>> >     >     > family, int streams,
>>>> >     >     >      int coupled_streams, 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
>>>> >     >
>>>> >     >
>>>> >     >     >  - Mark
>>>> >     >     >
>>>> >     >     >
>>>> >     >     > On Mon, Mar 19, 2018 at 3:00 PM, Drew Allen
>>>> >     <bitllama at google.com <mailto:bitllama at google.com>
>>>> >     >     <mailto:bitllama at google.com <mailto:bitllama at google.com>>>
>>>> wrote:
>>>> >     >     >> Hi Jean-Marc,
>>>> >     >     >>
>>>> >     >     >> I've modified my patches for libopus and libopusenc based
>>>> >     on your
>>>> >     >     >> suggestions.
>>>> >     >     >>
>>>> >     >     >> Cheers,
>>>> >     >     >> Drew
>>>> >     >     >>
>>>> >     >     >> On Mon, Mar 19, 2018 at 2:05 PM Jean-Marc Valin
>>>> >     >     <jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>
>>>> >     <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>> wrote:
>>>> >     >     >>>
>>>> >     >     >>> 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 that would return how
>>>> >     large the
>>>> >     >     header
>>>> >     >     >>> *actually* is. Then you can use that value instead of
>>>> >     >     >>> MAX_PACKET_BUFFER_SIZE in init_stream()
>>>> >     >     >>> 2) I think the remaining if()s in ope_encoder_ctl() can
>>>> >     also be
>>>> >     >     removed
>>>> >     >     >>> by adding another ctl() macro (like _oge_ctl()) with an
>>>> extra
>>>> >     >     argument.
>>>> >     >     >>> In the case of
>>>> OPUS_MULTISTREAM_GET_ENCODER_STATE_REQUEST,
>>>> >     you can
>>>> >     >     >>> simply use _oge_ctl(enc->st,
>>>> >     >     >>> OPUS_MULTISTREAM_GET_ENCODER_STATE(stream_id, value))
>>>> >     >     >>> 3) On libopus itself, why "#define
>>>> >     OPUS_HAVE_OPUS_PROJECTION_H 9000"
>>>> >     >     >>> instead of just "#define OPUS_HAVE_OPUS_PROJECTION_H"?
>>>> >     >     >>>
>>>> >     >     >>> Cheers,
>>>> >     >     >>>
>>>> >     >     >>>         Jean-Marc
>>>> >     >     >>>
>>>> >     >     >>> On 03/19/2018 02:53 PM, Drew Allen wrote:
>>>> >     >     >>>>
>>>> >     >     >>>> On Mon, Mar 19, 2018 at 11:52 AM Drew Allen
>>>> >     >     <bitllama at google.com <mailto:bitllama at google.com>
>>>> >     <mailto:bitllama at google.com <mailto:bitllama at google.com>>
>>>> >     >     >>>> <mailto:bitllama at google.com <mailto:
>>>> bitllama at google.com>
>>>> >     <mailto:bitllama at google.com <mailto:bitllama at google.com>>>>
>>>> wrote:
>>>> >     >     >>>>
>>>> >     >     >>>>     Hello all,
>>>> >     >     >>>>
>>>> >     >     >>>>     Sorry for the delay (got really sick last week).
>>>> >     >     >>>>
>>>> >     >     >>>>     Attached are updated patches for libopus,
>>>> libopusenc,
>>>> >     >     opusfile and
>>>> >     >     >>>>     opus-tools.
>>>> >     >     >>>>
>>>> >     >     >>>>     Note that the patches for libopusenc, opusfile and
>>>> >     >     opus-tools are
>>>> >     >     >>>>     dependent on the patch for libopus.
>>>> >     >     >>>>
>>>> >     >     >>>>     Please let me know if you have any additional
>>>> followup
>>>> >     >     comments or
>>>> >     >     >>>>     questions.
>>>> >     >     >>>>
>>>> >     >     >>>>     Cheers,
>>>> >     >     >>>>     Drew
>>>> >     >     >>>>
>>>> >     >     >>>>
>>>> >     >     >>>>
>>>> >     >     >>>> _______________________________________________
>>>> >     >     >>>> opus mailing list
>>>> >     >     >>>> opus at xiph.org <mailto:opus at xiph.org>
>>>> >     <mailto:opus at xiph.org <mailto:opus at xiph.org>>
>>>> >     >     >>>> http://lists.xiph.org/mailman/listinfo/opus
>>>> >     >     >>>>
>>>> >     >     >>
>>>> >     >     >>
>>>> >     >     >> _______________________________________________
>>>> >     >     >> opus mailing list
>>>> >     >     >> opus at xiph.org <mailto:opus at xiph.org> <mailto:
>>>> opus at xiph.org
>>>> >     <mailto:opus at xiph.org>>
>>>> >     >     >> http://lists.xiph.org/mailman/listinfo/opus
>>>> >     >     >>
>>>> >     >
>>>> >
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/opus/attachments/20180326/97920e88/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opusfile-Support-Ambisonics.patch
Type: text/x-patch
Size: 20828 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/opus/attachments/20180326/97920e88/attachment-0001.bin>


More information about the opus mailing list