similar to: repacketizing unrelated frames

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

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 >

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

Thanks Jean-Marc and Benjamin for the answers. One follow-up question. If I use a repacketizer as Jean-Marc suggested by combining two 60ms frames to form a 120ms frame, without extracting individual frames and using a new TOC, I would need to have a "de-packetizer" that does the exact opposite of repacketizer. De-packetizer would need to separate this 120ms frame into two 60ms frames

Hi Jean-Marc, On Jun 15, 2013, at 12:20 PMEDT, Jean-Marc Valin wrote: > > >> So I still wonder, if you set up a custom mode, but then had all the >> settings the same as a normal mode, would the codec perform worse, or >> the same? > > You'll have to try normal vs custom modes and choose. The only thing I'm > telling you is don't run a 48 kHz

All, Just a heads up that the IETF codec working group has issued a last call on the draft Opus specification. This means we think the draft adequately documents the format, and that we're willing to live with whatever bugs are present in the reference implementation, if they can't be fixed without breaking decodes. In turn, this means we could really use some feedback from implementers.

The libopus encoder's opus_encode() method is documented as "Encodes an Opus frame". Does that mean that it always produces a single Opus frame (i.e. the number of frames in the TOC byte will always be 0)? It's not clear from the documentation, but the fact that it cannot produce a 120ms Opus packet makes me wonder if that was the intention and any multi-frame Opus packets must

Hi Jean-Marc, On Jun 15, 2013, at 2:23 AMEDT, Jean-Marc Valin wrote: >> I'm looking at how to run Opus at 44.1K. I have flexibility in the >> frame sizes of the unencoded audio, and packet sizes on the RF link. > > You should probably consider resampling. It's not that expensive and it > would make things easy. But otherwise, see below. Yes, considering your and

Hi Felicia, I still don't quite understand why you need to make 120 ms a special case, rather than extend the code that already handles 40 ms and 60 ms. Cheers, Jean-Marc On 06/01/2016 12:58 PM, Felicia Lim wrote: > Hi all, > > I've just realized that there's a better and simpler way of doing this > which ensures that analysis and selection of the mode/bandwidth etc

Hi Jean-Marc, A simpler question. How does opus_encode() generate packets of 20ms (SILK-only or Hybrid)? Concatenating two 10ms frames or doing it straight with just one 20ms frame?

Attached is the amended second patch. It now extends the multistream API as well to 80/100/120 ms and incorporates changes based on Mark's comments. Thanks, Felicia On Mon, Jun 13, 2016 at 4:21 PM Felicia Lim <flim at google.com> wrote: > Hi Mark, Jean-Marc, > > Thanks for your comments. > > On Sun, Jun 12, 2016 at 6:34 AM Mark Harris <mark.hsj at gmail.com>

On 10/26/2013 01:11 PM, Wang, Chris wrote: > A simpler question. How does opus_encode() generate packets of 20ms > (SILK-only or Hybrid)? Concatenating two 10ms frames or doing it > straight with just one 20ms frame? Just one 20 ms frame. It always returns a single frame except when it just can't (e.g. 60 ms CELT). > From your explanations below, opus_encode() will concatenate

Am 03.12.2015 um 11:08 schrieb Greg Lindahl <lindahl at pbm.com>: > I wanted to help you by making sure that you were on the most recent > version, but, looking at the Centos.org website I was unable to figure > out if 7.2 was the tip. 7.1503? Is that 7.2? Beats me. CentOS 7.1511 (aka '7.2') not yet released ... > https://wiki.centos.org/Download appears to say that

Could someone explain to a non-US dummy the following phrases I have seen on the list. "I can provide you with tier 1 termination 6/6. I can blend or NPANXX breakout." "We provide US48 termination, blended rate for 1 MOU and above is .008 with 6/6." What is 6/6? What is US48? What is blended? What is MOU? What is NPANXX breakout? -------------- next part --------------

I've been losing patience with my current provider, a small company called Sellvoip. Their termination is good, and they are asterisk based, but they are understaffed and have no concept of customer service. So I'm shopping. I am interested in the opinions of others on the providers they work with. Here are my criteria, roughly in order a) Decent quality, low latency. In

ly or Hybrid frames for 40 or 60ms packet, respectively. That is based on = concatenating 20ms frames, right? Is 60ms the largest packet opus_encode() can generate? In order to get pac= kets of up to 120 ms by combining multiple frames as described in RFC6716 c= lause 2.1.4 one would need to use the "repacketizer". That is if I want to= have a 120 ms packet, I would need to take

Hi Ulrich, thanks for the suggestion. My concern is that one of the valid inputs is "2.5", which would require conversion to an int, e.g. x10, but doing something like this would start to affect the code readability. On Mon, Jun 27, 2016 at 3:02 PM Ulrich Windl < Ulrich.Windl at rz.uni-regensburg.de> wrote: > Hi! > > A note on style: Looking at this chunk of the patch

Am 03.12.2015 um 11:39 schrieb Greg Lindahl <lindahl at pbm.com>: > On Thu, Dec 03, 2015 at 11:28:10AM +0100, Leon Fauster wrote: >> Am 03.12.2015 um 11:08 schrieb Greg Lindahl <lindahl at pbm.com>: >>> I wanted to help you by making sure that you were on the most recent >>> version, but, looking at the Centos.org website I was unable to figure >>>

Am 03.12.2015 um 19:35 schrieb Greg Lindahl <lindahl at pbm.com>: > On Thu, Dec 03, 2015 at 12:26:08PM +0100, Leon Fauster wrote: >>> >>> And the way I'd figure this out from the centos website is? > > Note that I was asking about the release numbering, not the release > itself. And while you're suggesting where I could find out more or > take part

Sorry, I didn't read what you said carefully enough -- it's trying to create a system group. Still, looking inside of /etc/group to see what system groups already exist is probably a good idea. On Wed, Sep 02, 2015 at 02:19:51PM -0700, Greg Lindahl wrote: > The groupadd manpage gives this clue: > > The default is to use the smallest ID value greater than or equal to >