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

[Drew Allen]

Hi Rostislav et all,

The IETF document has just been moved to a working group last call.

Do you think it would it be possible to land this patch under an
experimental flag?

Cheers,
Drew

On Mon, Apr 23, 2018 at 12:28 PM Rostislav Pehlivanov <atomnuker at gmail.com>
wrote:

> On 23 April 2018 at 17:02, Drew Allen <bitllama-at-google.com at ffmpeg.org>
> wrote:
>
> > We have spent the past 2 years with the draft relatively unchanged aside
> > from minor edits on the draft. It is headed to a working group for
> > finalization very soon and no one has yet raised a single issue regarding
> > any proposed changes that this patch introduces. I wrote the
> > OpusProjection* API and it has been adopted in all Opus-related xiph
> master
> > branches.
> >
>
> Good to hear. I know the IETF can take an extraordinarily long amount of
> time to publish a draft and make it an RFC and wish you all the luck on
> getting it completed quickly.
>
>
> I worked closely with Jean-Marc Valin to design the API in Opus 1.3 to his
> > specification. Opus 1.3 beta already contains this new API and upon
> > release, I have 100% assurance from Jean-Marc that the OpusProjection*
> API
> > will be supported in 1.3 RC.
> >
>
> ...hidden behind a configure flag and not enabled by default. No one will
> enable it until its ready and becomes accepted, which is why it isn't
> enabled by default.
>
>
>
> > I disagree that a filter or some other layer of abstraction is necessary
> > here. OpusProjection* does not code the ambisonic channels directly.
> > Instead, they are mixed using a mixing matrix that minimizes coding
> > artifacts over the sphere. The demixing matrix on the decoder is vital in
> > order to get back the original ambisonic channels and
> OpusProjectionDecoder
> > handles this automatically.
> >
>
> Ah, okay. In which case what we need still is an API to signal the
> ambisonics order and any other metadata needed. We can't just say "here's a
> frame with a bunch of channels, based on their numer you could probably
> figure its some ambisonics" and clients shouldn't use heuristics like "this
> frame has 16 channels, its probably ambisonics". This information needs to
> be indicated properly.
>
>
> I completely disagree. The IETF draft has been stable for over a year and
> > these same changes to support the new API are already present in Opus,
> > libopusenc, opusfile and opus-tools.
>
>
> Stable != accepted. The option to enable the API is still hidden behind a
> configure flag for libopus. And it will remain like this until it becomes
> an RFC, just like the previous RFC which butc... updated the codec with
> some fixes.
>
> If libopus had the new API enabled by default I wouldn't mind this patch at
> all and would apply it, since I'd be sure it wouldn't change. But as it
> stands, both it and the signalling changes in the RFC can change at any
> time despite being stable by yourself.
>
> Also your mail client stripped the quote marks and made things confusing.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>