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

[Rostislav Pehlivanov]

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.