[opus] [PATCH] Support for Ambisonics
Drew Allen
bitllama at google.com
Mon Mar 26 19:17:16 UTC 2018
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/846cd737/attachment.html>
More information about the opus
mailing list