Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.
On Thu, Jul 26, 2018 at 4:15 PM, Rostislav Pehlivanov wrote: > Hey, > > As of now, the ambisonics API is enabled by default in libopus. We still > don't have a way to signal ambisonics yet. > We still have plenty of bits left in libavutil/channel_layout.h to signal > many orders of ambisonics but some people have had opinions against > extending that API. We could instead extend AVMatrixEncoding but I don't > think that's entirely appropriate. > What opinions do people have on this? > I had been working on a new API that would encompass ambisonic ordering (see https://github.com/kodabb/libav/commit/98d9b0a7b28525b29e40ae4c564e51e7c94449eb). The downside is that it requires updating the whole channel layout API (see https://github.com/kodabb/libav/commit/c023b553e6ad6da5af6d0d4ff067ff844b2fcfac ) I got it mostly working but ran into issues during backward compatibility, and didn't have time to debug and fix it. If anyone wants to finish the set, backport it, and add the missing lswr part it would be easy work. I'm available to help in the process just to get this completed. The full branch is available at https://github.com/kodabb/libav/commits/chl (I hope this will be a mature discussion even though the patches belong to another tree). -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.
Hey, As of now, the ambisonics API is enabled by default in libopus. We still don't have a way to signal ambisonics yet. We still have plenty of bits left in libavutil/channel_layout.h to signal many orders of ambisonics but some people have had opinions against extending that API. We could instead extend AVMatrixEncoding but I don't think that's entirely appropriate. What opinions do people have on this? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.
On 11 May 2018 at 15:55, Drew Allen wrote: > 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? No, libopus itself still hides the new API under an experimental flag. We also don't do experimental flags for decoders and there's no API yet to signal a channel layout is ambisonics. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.
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 wrote: > On 23 April 2018 at 17:02, Drew Allen > 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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.
On 23 April 2018 at 17:02, Drew Allen 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@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.
Hi Rostislav, Here is my feedback: 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. 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. 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. 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. 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 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. 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. 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.
On 20 April 2018 at 18:23, Drew Allen 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 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 wrote: > > > >> Friendly ping to allow this to push to the member list, please. > >> > >> On Wed, Mar 28, 2018 at 2:58 PM Drew Allen 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
Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.
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 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 wrote:
>
>> Friendly ping to allow this to push to the member list, please.
>>
>> On Wed, Mar 28, 2018 at 2:58 PM Drew Allen 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
>>>
>>
From 35f9b25fbe5dd086b6fab0276d00491b4783cd64 Mon Sep 17 00:00:00 2001
From: Andrew Allen
Date: Wed, 28 Mar 2018 14:48:46 -0700
Subject: [PATCH] Support for Ambisonics and OpusProjection* API.
---
libavcodec/libopusdec.c | 159 -
libavcodec/libopusenc.c | 253 ++--
libavcodec/opus.c | 18 ++-
3 files changed, 350 insertions(+), 80 deletions(-)
diff --git a/libavcodec/libopusdec.c b/libavcodec/libopusdec.c
index 2a97811d18..5caf8f3f53 100644
--- a/libavcodec/libopusdec.c
+++ b/libavcodec/libopusdec.c
@@ -21,6 +21,9 @@
#include
#include
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+#include
+#endif
#include "libavutil/internal.h"
#include "libavutil/intreadwrite.h"
@@ -33,9 +36,89 @@
#include "mathops.h"
#include "libopus.h"
+typedef struct OpusGenericDecoder {
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+OpusProjectionDecoder *pr;
+#endif
+OpusMSDecoder *ms;
+} OpusGenericDecoder;
+
+static int libopus_generic_decoder_init(OpusGenericDecoder *enc, int Fs,
+int channels, int nb_streams,
+int nb_coupled, uint8_t *mapping,
+uint8_t *dmatrix) {
+int err;
+if (dmatrix != NULL) {
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+opus_int32 size;
+size = 2 * channels * (nb_streams + nb_coupled);
+enc->pr = opus_projection_decoder_create(Fs, channels, nb_streams,
+nb_coupled, dmatrix, size, &err);
+#else
+err = OPUS_UNIMPLEMENTED;
+#endif
+return err;
+}
+enc->ms = opus_multistream_decoder_create(Fs, channels, nb_streams,
+nb_coupled, mapping, &err);
+return err;
+}
+
+static void libopus_generic_decoder_cleanup(OpusGenericDecoder *enc)
+{
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+if (enc->pr) opus_projection_decoder_destroy(enc->pr);
+#endif
+if (enc->ms) opus_multistream_decoder_destroy(enc->ms);
+}
+
+static int libopus_generic_decode(OpusGenericDecoder *enc,
+const unsigned char *data, opus_int32 len, opus_int16 *pcm,
+int frame_size, int decode_fec) {
+int ret;
+
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+if (enc->pr){
+ret=opus_projection_decode(enc->pr, data, len, pcm, frame_size,
+decode_fec);
+return ret;
+}
+#endif
+ret=opus_multistream_decode(enc->ms, data, len, pcm, frame_size,
+decode_fec);
+return ret;
+}
+
+static int libopus_generic_decode_float(OpusGenericDecoder *enc,
+const unsigned char *data, opus_int32 len, float *pcm, int frame_size,
+int decode_fec) {
+int ret;
+
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+if (enc->pr){
+ret=opus_projection_decode_float(enc->pr, data, len, pcm, frame_size,
+decode_fec);
+return ret;
+}
+#endif
+ret=opus_multistream_decode_float(enc->ms, data, len, pcm, frame_size,
+decode_fec);
+return ret;
+}
+
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+# define libopus_generic_decoder_ctl(enc, request) \
+((enc)->pr != NULL ? \
+opus_projection_decoder_ctl((enc)->pr, request) : \
+opus_multistream_decoder_ctl((enc)->ms, request))
+#else
+# define libopus_generic_decoder_ctl(enc, request) \
+opus_multistream_decoder_ctl((enc)->ms, request)
+#endif
+
struct libopus_context {
AVClass *class;
-OpusMSDecoder *dec;
+OpusGenericDecoder dec;
int pre_skip;
#ifndef OPUS_SET_GAIN
union { int i; double d; } gain;
@@ -46,12 +129,17 @@ struct libopus_context {
};
#define OPUS_HEAD_SIZE 19
+#ifdef OPUS_HAVE_OPUS_PROJECTION_H
+# define OPUS_MAX_CHANNELS 18
+#else
+# define OPUS_MAX_CHANNELS 8
+#endif
static av_cold int libopus_decode_init(AVCodecContext *avc)
{
struct libopus_context *opus = avc->priv_data;
int ret, channel_map = 0, gain_db = 0, nb
Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.
On Wed, 11 Apr 2018 14:01:08 +0100 Rostislav Pehlivanov wrote: > On 28 March 2018 at 22:59, Drew Allen > 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 > > > > > You don't set the channel layout to anything. We have support for some > ambisonics formats. Use them. How else would users know what is what? Check > the number of channels? > Also what about mapping families 240(?) -> 254? > I thought they were reserved for ambisonics (very recently too, though they > don't define any specific layouts :/). > > IMO this might need a new channel layout API with support for ambisonics > because things are messy there as-is. Libav has a patchset, but it's stalled. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.
On 28 March 2018 at 22:59, Drew Allen 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 > > You don't set the channel layout to anything. We have support for some ambisonics formats. Use them. How else would users know what is what? Check the number of channels? Also what about mapping families 240(?) -> 254? I thought they were reserved for ambisonics (very recently too, though they don't define any specific layouts :/). IMO this might need a new channel layout API with support for ambisonics because things are messy there as-is. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.
On Wed, Mar 28, 2018 at 09:59:00PM +, Drew Allen 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
> libopusdec.c | 160 ++--
> libopusenc.c | 257
> ++-
> opus.c | 18 +---
> 3 files changed, 358 insertions(+), 77 deletions(-)
> 1f1fae1e93478880b50cd5432bb7479bc816f659 ffmpeg-Support-Ambisonics.patch
> From a897b4d9b1ebe9031b98a9e507c28355ef9a44ba Mon Sep 17 00:00:00 2001
> From: Andrew Allen
> Date: Wed, 28 Mar 2018 14:48:46 -0700
> Subject: [PATCH] Support for Ambisonics and OpusProjection* API.
>
> ---
> libavcodec/libopusdec.c | 160 -
> libavcodec/libopusenc.c | 257 ++--
> libavcodec/opus.c | 18 ++-
> 3 files changed, 358 insertions(+), 77 deletions(-)
>
> diff --git a/libavcodec/libopusdec.c b/libavcodec/libopusdec.c
> index 3d2ee5b61b..d4b5a459b9 100644
> --- a/libavcodec/libopusdec.c
> +++ b/libavcodec/libopusdec.c
> @@ -21,6 +21,9 @@
>
> #include
> #include
> +#ifdef OPUS_HAVE_OPUS_PROJECTION_H
> +#include
> +#endif
>
> #include "libavutil/internal.h"
> #include "libavutil/intreadwrite.h"
> @@ -33,9 +36,93 @@
> #include "mathops.h"
> #include "libopus.h"
>
> +typedef struct OpusGenericDecoder {
> +#ifdef OPUS_HAVE_OPUS_PROJECTION_H
> +OpusProjectionDecoder *pr;
> +#endif
> +OpusMSDecoder *ms;
> +} OpusGenericDecoder;
> +
> +static int libopus_generic_decoder_init(OpusGenericDecoder *st, int Fs,
> +int channels, int nb_streams,
> +int nb_coupled, uint8_t *mapping,
> +uint8_t *dmatrix) {
> +int err;
> +if (dmatrix != NULL) {
> +#ifdef OPUS_HAVE_OPUS_PROJECTION_H
> +opus_int32 size;
> +size = 2 * channels * (nb_streams + nb_coupled);
> +st->pr = opus_projection_decoder_create(Fs, channels, nb_streams,
> +nb_coupled, dmatrix, size, &err);
> +#else
> +err = OPUS_UNIMPLEMENTED;
> +#endif
> +st->ms = NULL;
> +return err;
> +}
> +#ifdef OPUS_HAVE_OPUS_PROJECTION_H
> +st->pr = NULL;
> +#endif
> +st->ms = opus_multistream_decoder_create(Fs, channels, nb_streams,
> +nb_coupled, mapping, &err);
> +return err;
> +}
> +
> +static void libopus_generic_decoder_cleanup(OpusGenericDecoder *st)
> +{
> +#ifdef OPUS_HAVE_OPUS_PROJECTION_H
> +if (st->pr) opus_projection_decoder_destroy(st->pr);
> +#endif
> +if (st->ms) opus_multistream_decoder_destroy(st->ms);
> +}
> +
> +static int libopus_generic_decode(OpusGenericDecoder *st,
> +const unsigned char *data, opus_int32 len, opus_int16 *pcm,
> +int frame_size, int decode_fec) {
> +int ret;
> +
> +#if defined(OPUS_HAVE_OPUS_PROJECTION_H)
inconsistent comapred to previous #ifdef
> +if (st->pr){
> +ret=opus_projection_decode(st->pr, data, len, pcm, frame_size,
> +decode_fec);
> +return ret;
> +}
> +#endif
> +ret=opus_multistream_decode(st->ms, data, len, pcm, frame_size,
> +decode_fec);
> +return ret;
> +}
> +
> +static int libopus_generic_decode_float(OpusGenericDecoder *st,
> +const unsigned char *data, opus_int32 len, float *pcm, int
> frame_size,
> +int decode_fec) {
> +int ret;
> +
> +#if defined(OPUS_HAVE_OPUS_PROJECTION_H)
> +if (st->pr){
> +ret=opus_projection_decode_float(st->pr, data, len, pcm, frame_size,
> +decode_fec);
> +return ret;
> +}
> +#endif
> +ret=opus_multistream_decode_float(st->ms, data, len, pcm, frame_size,
> +decode_fec);
> +return ret;
> +}
> +
> +#ifdef OPUS_HAVE_OPUS_PROJECTION_H
> +# define libopus_generic_decoder_ctl(st, request) \
> +((st)->pr != NULL ? \
> +opus_projection_decoder_ctl((st)->pr, request) : \
> +opus_multistream_decoder_ctl((st)->ms, request))
> +#else
> +# define libopus_generic_decoder_ctl(st, request) \
> +opus_multistream_decoder_ctl((st)->ms, request)
> +#endif
> +
> struct libopus_context {
> AVClass *class;
> -OpusMSDecoder *dec;
> +OpusGenericDecoder dec;
> int pre_skip;
> #ifndef OPUS_SET_GAIN
> union { int i; double d; } gain;
> @@ -46,12 +133,17 @@ struct libopus_context {
> };
>
> #define OPUS_HEAD_SIZE 19
> +#ifdef OPUS_HAVE_OPUS_PROJECTION_H
> +# define OPUS_MAX_CHANNELS 18
> +#else
> +# define OPUS_MAX_CHANNELS 8
> +#endif
>
> static av_cold int libopus_decode_init(AVCodecContext *avc)
> {
> struct libopus_context *opus = avc->priv_
Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.
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 wrote: > Friendly ping to allow this to push to the member list, please. > > On Wed, Mar 28, 2018 at 2:58 PM Drew Allen 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
Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.
Friendly ping to allow this to push to the member list, please. On Wed, Mar 28, 2018 at 2:58 PM Drew Allen 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
