search for: graczyk

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: <http://lists.xiph.org/pipermail/opus/attachments/20160506/5ba6a372/attachment.html> -------------- next part --------------

...xml/reference.RFC.6716.xml'> <!ENTITY rfc7845 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7845.xml'> ]> <?rfc toc="yes" symrefs="yes" ?> <rfc ipr="trust200902" category="std" docName="draft-graczyk-opus-ambisonics" updates="7845"> <front> <title abbrev="Opus Ambisonics">Ambisonics in an Ogg Opus Container</title> <author initials="M.G." surname="Graczyk" fullname="Michael Graczyk"> <organization>Google I...

...xperimental code there could be a difference, but I'm hoping that is not the case on any platform! Either way I changed them to #ifdef everywhere. On Tue, May 24, 2016 at 8:26 AM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Michael, > > On 05/24/2016 01:14 AM, Michael Graczyk wrote: > > Thanks for pointing out the make differences. Do you mind if I add an > > #ifndef, #define to the top of the file for the experiment flag? The > > code becomes significantly more nasty with #ifdefs everywhere and it > > would only get worse in subsequent patches....

...xml/reference.RFC.6716.xml'> <!ENTITY rfc7845 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7845.xml'> ]> <?rfc toc="yes" symrefs="yes" ?> <rfc ipr="trust200902" category="std" docName="draft-graczyk-opus-ambisonics" updates="7845"> <front> <title abbrev="Opus Ambisonics">Ambisonics in an Ogg Opus Container</title> <author initials="M.G." surname="Graczyk" fullname="Michael Graczyk"> <organization>Google I...

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>

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 w...

...#define to the top of the file for the experiment flag? The code becomes significantly more nasty with #ifdefs everywhere and it would only get worse in subsequent patches. On May 23, 2016 21:28, "Jean-Marc Valin" <jmvalin at jmvalin.ca> wrote: > On 05/23/2016 10:57 PM, Michael Graczyk wrote: > > Since they correspond to mapping family values, I figured it would be > > wise to make them match so that the correspondence would be clear. If > > you would rather that correspondence not be explicit I will remove the > > explicit assignments. > > I'd r...

...will actually set channel bitrate and other configuration. My main concern is that adding additional opus_multistream_*_encoder_create/init/get_size functions is unnecessary. Should we instead just add new channel mappings to opus_multistream_surround_encoder_*, despite the name? Thanks, Michael Graczyk -------------- next part --------------

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...

...the multistream API. We allocate 4 bits to the mono channel (channel index 0) for every 3 bits allocated to other channels. The allocation is static because it does not depend on the input audio. This patch also forces the underlying encoders to use CELT only for ambisonics. -- Thanks, Michael Graczyk -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20160609/eabf58d3/attachment.html> -------------- next part --------------

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

...apping? Would it require a new Opus version number? To summarize, should we add a new channel mapping for ambisonics? If not, what should we do? [1] https://en.wikipedia.org/wiki/Ambisonics [2] https://tools.ietf.org/html/draft-ietf-codec-oggopus-14#section-5.1.1 Thanks for your input, Michael Graczyk -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20160417/f70da8bc/attachment.html>

Hi Michael, Any particular reason you assign explicit values to your MappingType enum? If not, I'd rather not depend on the int values. Other than that, I think your patch is good to go. Cheers, Jean-Marc On 05/23/2016 01:27 PM, Michael Graczyk wrote: > Hi Jean-Marc, > > On Sat, May 21, 2016 at 1:58 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: >> 1) I think "allocation mode" should be renamed to "mapping type" or >> something similar that to make it less confusing. > Done > >...

...er.channels>8?255:chan>2; + if (channel_mapping >= 0) { + header.channel_mapping = channel_mapping; + } else { + header.channel_mapping = header.channels > 8 ? 255 : header.channels > 2; + } header.input_sample_rate=rate; header.gain=inopt.gain; -- Thanks, Michael Graczyk

...ng-families.xhtml>. > As long as there is a specification somewhere (this does not have to be an > IETF specification, though it could be), we can add it to this list. Great, I will use these as a guide to writing a more precise description of the ambisonic mapping. -- Thanks, Michael Graczyk

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 matr...

...s are good for 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 resu...

...eeded a more complex mapping and more data in the encoder. If it turns out you need this kind of thing too, then yes we would probably just want to extend the opus_multistream_surround_encoder_*() calls since they already take a family argument. Cheers, Jean-Marc On 05/04/2016 06:24 PM, Michael Graczyk wrote: > 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 s...

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

Hi Michael, On 05/24/2016 01:14 AM, Michael Graczyk wrote: > Thanks for pointing out the make differences. Do you mind if I add an > #ifndef, #define to the top of the file for the experiment flag? The > code becomes significantly more nasty with #ifdefs everywhere and it > would only get worse in subsequent patches. Unless it makes the...