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>
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>
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>
On Fri, Jul 6, 2018 at 6:07 PM, Joshua Bowman <silverbacknet at gmail.com> wrote:> Minor thing missed: Adding the files to the VS project file.Thanks. Should these source files also be added to win32/VS2015/opus.vxcproj.filters? - Mark