search for: mgraczyk

Here is the modified patch. I added a flag to configure.ac which is set to 0 to disable ambisonics, and 1 to enable it. Right now the implementation simply creates a surround encoder with N uncoupled streams. Thanks, Michael Graczyk -------------- next part -------------- An HTML attachment was scrubbed... URL:

Here is a simple patch to fix a bug in opusenc's set-ctl-int code -- Thanks, Michael Graczyk -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-potential-uninitialized-access-for-set-ctl-int.patch Type: text/x-patch Size: 992 bytes Desc: not available URL: <http://lists.xiph.org/pipermail/opus/attachments/20160425/22994ffa/attachment.bin>

On Sat, 28 May 2016 16:21:33 -0700, Michael Graczyk <mgraczyk at google.com> wrote : > Hi Marc, Hi Micheal. > On Sat, May 28, 2016 at 10:44 AM, Marc Lavallée <marc at hacklava.net> > wrote: > > I subscribed because your discussion on the IETF draft ("Ambisonics > > in an Ogg Opus Container") was mentioned on the surs...

Tim, Would you mind giving me a more specific example of the sort of document that you think this should look like? I'd like to write up something that is somewhat final. On Mon, May 2, 2016 at 9:30 PM, Michael Graczyk <mgraczyk at google.com> wrote: > On Fri, Apr 29, 2016 at 4:32 PM, Timothy B. Terriberry > <tterribe at xiph.org> wrote: > > As a general point, it's too late to add anything to the soon-to-be RFC > > 7845. It's too far along in the publication process. This would have to...

...or the recording but what is about the playback? In addition to an Ambisonic channel mapping, isn't it worthwhile to think about some object based audio coding, too? But then again, that would be much more work than just adding a new channel mapping. Christian > Michael Graczyk <mgraczyk at google.com> hat am 18. April 2016 um 04:29 > geschrieben: > > > Hello, > > We (Google) have been experimenting with configuration and adjustments to > CELT-only Opus that give good results for compressing ambisonic audio > signals [1]. Based on our results so far, w...

Does anyone have more thoughts on this patch? I would like to get this in so I can send more involved patches related to ambisonics. Also, do you guys prefer to do code review using pull requests on github? It seems that both are used for Opus. On Fri, May 6, 2016 at 4:46 PM, Michael Graczyk <mgraczyk at google.com> wrote: > Here is the modified patch. I added a flag to configure.ac which is set > to 0 to disable ambisonics, and 1 to enable it. Right now the > implementation simply creates a surround encoder with N uncoupled streams. > > > Thanks, > Michael Graczyk >...

On Tue, 31 May 2016 09:41:37 -0700 Michael Graczyk <mgraczyk at google.com> wrote: > UHJ is an interesting way to preserve compatibility with non-ambisonic > playback systems. However, I have not seen it generalized to higher > orders. I expect that its popularity will decrease as HOA becomes more > and more common. If UHJ becomes popular in...

Change-Id: I16bd4cd990d8ad5888c9e30016218ac25242ecb5 --- src/opus_multistream_encoder.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/opus_multistream_encoder.c b/src/opus_multistream_encoder.c index 30cafe1..c07132f 100644 --- a/src/opus_multistream_encoder.c +++ b/src/opus_multistream_encoder.c @@ -747,7 +747,8 @@ static void ambisonics_rate_allocation( if

This patch adds a new option "channel-mapping" to opusenc which sets the channel mapping family used by the multistream encoder. Please let me know whether adding this option is worthwhile and whether the help string is okay. I tried to keep it short but accurate. The error message for an unimplemented channel mapping is "Error cannot create encoder: request not implemented".

...patch uses different coding conventions like "if(" and "if ("; like wise "){" and ") {". My personal taste is to have spaces after keywords, but that's just me. I'd prefer a consistent coding style. Regards, Ulrich >>> Michael Graczyk <mgraczyk at google.com> schrieb am 26.04.2016 um 06:31 in Nachricht <CABcu6-gnkPHY0d8rqDie8z5OZ+WH6eb0P+k6bPit2H8i5RrS1w at mail.gmail.com>: > This patch adds a new option "channel-mapping" to opusenc which sets > the channel mapping family used by the multistream encoder. Please le...

...rganization>Google Inc.</organization> <address> <postal> <street>1600 Amphitheatre Parkway</street> <city>Mountain View</city> <region>CA</region> <code>94043</code> <country>USA</country> </postal> <email>mgraczyk at google.com</email> </address> </author> <date day="24" month="May" year="2016"/> <area>RAI</area> <workgroup>codec</workgroup> <abstract> <t> This document defines an extension to the Ogg format to encaps...

Michael Graczyk wrote: > As for mixing matrices, we are not confident in any choices for setups > beyond stereo. Although there have been papers and studies on Okay, better to give no advice than bad advice. > provide only a stereo downmixing matrix. It looks like this would go > in 5.1.1.5? The matrix should be As a general point, it's too late to add anything to the soon-to-be

...rganization>Google Inc.</organization> <address> <postal> <street>1600 Amphitheatre Parkway</street> <city>Mountain View</city> <region>CA</region> <code>94043</code> <country>USA</country> </postal> <email>mgraczyk at google.com</email> </address> </author> <date day="24" month="May" year="2016"/> <area>RAI</area> <workgroup>codec</workgroup> <abstract> <t> This document defines an extension to the Ogg format to encaps...

Hi Opus list. I subscribed because your discussion on the IETF draft ("Ambisonics in an Ogg Opus Container") was mentioned on the sursound list. I tried Opus for ambisonics more than a year ago. It does works with uncoupled channels (I had to patch the encoder). I don't know what else could be done to optimize support for ambisonics, as I'm not a codec expert. So I think that

Hello, We (Google) have been experimenting with configuration and adjustments to CELT-only Opus that give good results for compressing ambisonic audio signals [1]. Based on our results so far, we would like to use Opus to encode spatial audio. We hope to make it easy/possible to use libopus with other common tools and software modules (ffmpeg/libav in particular). Based on my reading of the

Alright, here is a somewhat formal definition of the channel mapping I had in mind: ------ Channel Mapping Family 2 Allowed numbers of channels: (1 + l)^2 for l = 1...15. Explicitly 1, 4, 9, 16, 25, 36, 49, 64, 81, 100, 121, 144, 169, 196, 225. Ambisonics from first to fifteenth order. Each channel is assigned to an ambisonic component in Ambisonic Channel Number (ACN) order. The ambisonic

I've discussed hemispherical ambisonics and mixing matrices with a few people. The consensus is that there is no set of hemispherical basis functions common enough to warrant inclusion yet. We should force channel counts to be values (l + 1)^2 for simplicity and to keep the possibility open of including hemispherical bases should one ever become popular. As for mixing matrices, we are not

This patch adds top level functions to create an ambisonic multistream encoder. The implementation currently just calls the analogous surround sound functions with channel mapping 255 to create an encoder that bundles uncoupled streams. Forthcoming patches will actually set channel bitrate and other configuration. My main concern is that adding additional

Jean-Marc, > Is there any reason you can't just use the generic multi-stream API, > i.e. opus_multistream_encoder_init() and give it the mapping you need? I would like the encoder to make decisions based on the fact that the audio is Ambisonics. For example, the bitrate allocation should not be the same for every channel. The original multistream API does not provide a way to pass in

On Fri, Apr 29, 2016 at 4:32 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > As a general point, it's too late to add anything to the soon-to-be RFC > 7845. It's too far along in the publication process. This would have to go > in a separate document (which, other than having to add an abstract, brief > introduction, and some other boilerplate sections,