[opus] [PATCH] Support for Ambisonics

Joshua Bowman silverbacknet at gmail.com
Sat Jul 7 01:07:09 UTC 2018


 Minor thing missed: Adding the files to the VS project file.

(Sorry for the direct reply, Drew, Gmail's interface always trips me up on
mailing lists.)


On Fri, Jul 6, 2018 at 6:06 PM Joshua Bowman <silverbacknet at gmail.com>
wrote:

> Minor thing missed: Adding the files to the VS project file.
>
> (Sorry for the direct reply, Drew, Gmail's interface always trips me up on
> mailing lists.)
>
> On Fri, Jul 6, 2018 at 6:05 PM Joshua Bowman <silverbacknet at gmail.com>
> wrote:
>
>> Minor thing missed: Adding the files to the VS project file.
>>
>> On Mon, Mar 26, 2018 at 12:32 PM Drew Allen <bitllama at google.com> wrote:
>>
>>> 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
>>>>>>> >     >     >>
>>>>>>> >     >
>>>>>>> >
>>>>>>>
>>>>>> _______________________________________________
>>> opus mailing list
>>> 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/20180706/524b76cf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opus-patch-vs-solution.diff
Type: application/octet-stream
Size: 752 bytes
Desc: not available
URL: <http://lists.xiph.org/pipermail/opus/attachments/20180706/524b76cf/attachment-0001.obj>


More information about the opus mailing list