[FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.

[Rostislav Pehlivanov]

On 20 April 2018 at 18:23, Drew Allen <bitllama-at-google.com at 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 <bitllama at 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 <bitllama at 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 <bitllama at 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 at 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.