search for: mapping_famili

I've run into some issues using Opus with source files in channel layouts other than the default 8. For instance, 2.1 isn't supported, so I have to either downconvert to 2.0 or upconvert to 5.1 (which usually involves adding empty channels, which prevents the playback device from upconverting to the native layout). To address this, I've put together an initial draft of an I-D I'd

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

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

On 05/05/2016 06:29 PM, Michael Graczyk wrote: > Alright, that is simpler. I can modify the patch to simply add > "mapping_family == 2" to the allowed values in the surround encoder > functions. Sounds reasonable. I would also suggest putting ambisonics behind a #define ENABLE_EXPERIMENTAL_AMBISONICS (or similar) until the spec is final to avoid accidental deployment of

Hello, I am trying to encode an Opus file with Ambisonics including Head-Locked (non-diegetic) Stereo sound for a Virtual Reality 360° video. YouTube describes the spatial audio requirements here: https://support.google.com/youtube/answer/6395969 It's the last list item 5. > 5. Supported First Order Ambisonics (FOA) with Head-Locked Stereo format: > W, Y, Z, X, L, R as a 6-channel

Friendly ping for supporting ambisonics in opus-tools & opusfile Please LMK any ?s you might have. Cheers, Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20180410/fd4a3709/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name:

Drew Allen wrote: > Friendly ping for supporting ambisonics in opus-tools & opusfile > > Please LMK any ?s you might have. Sorry for the long delay on the review. The high-level design looks a lot better. I have a number of comments on the implementation details. I didn't really like the way that opus_head_projection_parse() turned out. I was originally thinking something