similar to: Multistream Framing

I use the Opus multistream encoder for both mono and stereo encodings and after updating from 1.1.3 to 1.3 I noticed the size of the produced Opus files had doubled for 1-channel encodings whereas switching to the standand Opus encoder gave me roughly the same sizes as before. In these tests, I'm encoding an 8kHz mono stream containing only speech with the following options set: frame length

When encoding using the Opus multistream API, is it possible for opus_multistream_encode() to return 0? For example, what happens if multiple streams are being encoded, each with DTX enabled and all streams emit DTX packets at the same time? What about the case of a single stream with DTX enabled? Thanks Kevin O'Connor -------------- next part -------------- An HTML attachment was

I must apologize for my previous question. It seems that Opus Multistream uses self-delimiting packets for the purpose of concatenating multiple Opus packets into a single larger one at the transport layer. I was mistakenly under the impression that Multistream used multiple frames inside an Opus packet and was very confused about how to achieve 255 channels like that. -------------- next part

Hi Michael, 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? This is how surround was originally done (in 1.0) and only got changed when surround needed 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

Hi Jean-Marc, I looked at that but importantly these streams need to remain absolutely independent, Further they may have been encoded at some previous time. So my question stands. Thanks, Marc On Jul 26, 2013, at 9:10 PMEDT, Jean-Marc Valin wrote: > Hi Marc, > > I recommend you have a look at the multistream API and how we use it for > surround in the Ogg Opus draft. Sounds

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

Hello, I'm confused as to whether opus_multistream_encode creates a frame or a packet. The function summary says this: Encodes a multistream Opus *frame*. But later on it says: The length of the encoded *packet* (in bytes) on success or a negative > error code (see Error codes<http://www.opus-codec.org/docs/html_api-1.0.2/group__opus__errorcodes.html>) > on failure. I would

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 Marc, I recommend you have a look at the multistream API and how we use it for surround in the Ogg Opus draft. Sounds like the best way to solve your problem. Cheers, Jean-Marc On 07/26/2013 06:57 PM, Marc Lindahl wrote: > I can't quite figure this out from looking at the repacketizer code. > > Let's say I have 4 separate stereo streams (say from an 8 channel >

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

Hi, We have already pointed out multiple times in the HydrogenAudio thread ( http://www.hydrogenaudio.org/forums/index.php?showtopic=99653 ) why we think this is a bad idea. These include (off the top of my head): 1) The Opus decoder does not have a bit-exact definition 2) It would require a bit-exact resampler too (the one from opus-tools isn't bit-exact even in fixed-point) 3) Opus has

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. -------------- next part -------------- An HTML attachment was scrubbed... URL:

I have a project I'm investigating. The goal is to basically add lossless extensions to Opus. You have an Opus stream with standard packets, but interwoven in there are extension packets that contain the residuals. Ideally, compliant decoders play the stream back and ignore the extension packets. This (hopefully) makes the "lossless" stream compatible with existing players.

Hi folks, This patch will fix the issue. Thanks, Taihei Momma -------------- next part -------------- A non-text attachment was scrubbed... Name: opus_multistream_encoder.diff Type: application/octet-stream Size: 482 bytes Desc: not available Url : http://lists.xiph.org/pipermail/opus/attachments/20130309/5f8d3d1d/attachment.obj

On May 20, 2016 18:32, "Jean-Marc Valin" <jmvalin at jmvalin.ca> wrote: > > Is it intended that this patch never sets ALLOCATION_MODE_AMBISONICS? > I'm having a hard time figuring out what it does in its current state. That was intended. I wanted to "reserve" the number 2 in this enum to make it clear that 2 would mean ambisonics in the future. > Also, I

Hi! I haven't looked into the code yet, but the 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

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:

Sounds good, I'll make those changes. 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. On May 23, 2016 21:28, "Jean-Marc Valin" <jmvalin at jmvalin.ca> wrote: > On

Alright, I've made the changes to the enum and flag usage. I'm don't see the difference with respect to "disabling blocks of code", since the compiler should completely elide the blocks that are conditioned on a constant 0. If there were compiler errors in the experimental code there could be a difference, but I'm hoping that is not the case on any platform! Either way I

Hi all, We (WebRTC/Google) would like to extend Opus to natively support 120 ms encoding instead of relying on repacketization as a post processing step. This is to ensure that a valid 120 ms packet is always available. I've attached a couple of patches to add this to opus_encoder(), based on the internal repacketization process carried out by 60 ms CELT. We intend to extend this later for