[FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.
bitllama at google.com
Fri May 11 17:55:21 EEST 2018
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
On Mon, Apr 23, 2018 at 12:28 PM Rostislav Pehlivanov <atomnuker at gmail.com>
> On 23 April 2018 at 17:02, Drew Allen <bitllama-at-google.com at ffmpeg.org>
> > 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
> > 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*
> > 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
> > 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
More information about the ffmpeg-devel