On 20 April 2018 at 18:23, Drew Allen <bitllama-at-google....@ffmpeg.org> wrote:
> Hello all, > > Attached is a revised patch based on your suggestions. > > Rostislav Pehlivanov - I'm not sure how to address your concerns. My patch > provides support for the ambisonics features already approved and present > in Opus 1.3. If there are ways I can change my patch, please let me know. > > Cheers, > Drew > > On Mon, Apr 9, 2018 at 10:57 AM Drew Allen <bitll...@google.com> wrote: > > > Friendly weekly ping about this patch. > > > > Can someone please let me know if I need to do anything more to submit > > this patch? Thanks! > > > > On Mon, Apr 2, 2018 at 9:13 AM Drew Allen <bitll...@google.com> wrote: > > > >> Friendly ping to allow this to push to the member list, please. > >> > >> On Wed, Mar 28, 2018 at 2:58 PM Drew Allen <bitll...@google.com> wrote: > >> > >>> Hello all, > >>> > >>> My name is Andrew Allen and I'm a contributor to Opus, supporting new > >>> channel mappings 2 and 3 for ambisonics compression. I've attached a > patch > >>> to support the new OpusProjectionEncoder and OpusProjectionDecoder > APIs for > >>> handling the new channel mapping 3 in OPUS. > >>> > >>> Please let me know of any changes I should make or if there are any > >>> questions I can help answer. > >>> > >>> Cheers, > >>> Drew > >>> > >> > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > I am sorry, I don't agree that this should be merged quite yet. First of all, the draft upon which how the channel family is interpreted (draft-ietf-codec-ambisonics-04) isn't finalized yet. What if it changes after we make a release? We can't really change it. This affects both encoding and decoding. Second, the API isn't in any libopus release yet. What if we make a release, the draft changes, so the API in libopus needs to be changed. Or the API in the current git master of libopus changes? We can't rely on an unstable API in a library. Third, this patch makes the decoder always do demixing with the data in extradata. What if someone wants to just decode and do their own demixing with positional information? We'd break decoding for anyone who's depending on the behaviour if we were to change this so the decoder outputs raw ambisonics. We never do any mixing or conversions in decoders. Hence ambisonics data needs to be exposed directly, and anyone wanting to demix it should use a filter (there's an unmerged filter to do that) or do it themselves. What we need to do to properly handle ambisonics is: 1. Be able to describe ambisonics. This needs a new API. 2. Be able to expose the demixing matrix via frame side data. 3. Have a filter which can use both to provide a demixed output, better yet with positional information. I think the draft should become an RFC first. That gives us enough time to work on 1.), which should take the longest time to do and agree on. 2.) is trivial and 3.) is from what I know mostly done. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
