search for: repacketizer

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 converter) and want to transmit them somewhere in one stream e.g. RTP or the like. (assuming, custom format if necessary) So could I merge 4 packets with the repacketizer, TX the merged packets, on the other side RX the...

...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 >> converter) and want to transmit them somewhere in one stream e.g. >> RTP or the like. (assuming, custom format if necessary) >> >> So could I merge 4 packets with the repacke...

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

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 > converter) and want to transmit them somewhere in one stream e.g. > RTP or the like. (assuming, custom format if necessary) > > So could I merge 4 packets with the repacketizer, TX the merged &gt...

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

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?

Hi folks I have a handset talking to Asterisk, which in turn puts the call through to an ITSP. The handsets likes to send audio in 40ms frames (even though Asterisk requests 20ms frames with a ptime header in the SDP). The ITSP doesn't request any particular frame length (with ptime) or state a maximum length (with maxptime), so when Asterisk receives the 40ms media frames from the handset,

Is there a reason why opus_repacketier_cat is limited to 120ms packets? It seems 120ms frames can only be combination frames, that is, only constructed by combining smaller frames of the same config. If this is true, then why stop at 120ms and not support longer packets? Regards, -- Daniel. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Daniel K wrote: > true, then why stop at 120ms and not support longer packets? https://tools.ietf.org/html/rfc6716#section-3.2.5 "...the audio duration contained within a packet MUST NOT exceed 120 ms..."

On Fri, Dec 19, 2014 at 9:03 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Daniel K wrote: >> true, then why stop at 120ms and not support longer packets? > > https://tools.ietf.org/html/rfc6716#section-3.2.5 > > "...the audio duration contained within a packet MUST NOT exceed 120 ms..." If you're wondering why the limit exists, there are a

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

...espectively. That > is based on concatenating 20ms frames, right? Right. > Is 60ms the largest packet opus_encode() can generate? Yes. > In order to > get packets of up to 120 ms by combining multiple frames as described > in RFC6716 clause 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 two > 60 ms packets generated by opus_encode(), extract out the compressed > frames from each packet, concatenate them and put on a new TOC with > frame count code "c" set to 1. Well, no need to extract...

On 06/01/2016 02:06 PM, Felicia Lim wrote: > That was my intention with refactoring out the subframe encoding and > repacketizing bit. Or do you mean I should merge the explicit check for > 120 ms frame and the existing checks for 40/60 ms wideband? What I mean is that this line in opus_encoder.c: if (frame_size > st->Fs/50 && (st->mode == MODE_CELT_ONLY ||

...id 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 two 60 ms packets generated by= opus_encode(), extract out the compressed frames from each packet, concate= nate them and put on a new TOC with frame count code "c" set to 1. Regards, Chris -----Original Message...

...le 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 formed outside the libopus encoder (e.g. the Repacketizer). If that's not the case and opus_encode() can produce multi-frame Opus packets, why is it limited to 60ms Opus packets? Kevin O'Connor Interacive Intelligence, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attac...

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 is done on the whole 120 ms frame. I believe that the logic and threshold values for making these decisions are still valid for 120 ms, but I might be missing something? Please find my updated patches attached. Thanks, Felicia On Tue, May

Hi, I wondered if are there any further thoughts on these patches? Thanks, Felicia On Thu, Jun 2, 2016 at 2:13 PM Felicia Lim <flim at google.com> wrote: > OK, I've amended the second patch and also added 80 and 100 ms. > > Thanks, > Felicia > > > On Thu, Jun 2, 2016 at 7:20 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > >> On 06/01/2016 02:06

Hi Felicia, A few comments: > - /* CELT can only support up to 20 ms */ > subframe_size = st->Fs/50; > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; > + nb_subframes = frame_size/subframe_size; This will use six 20ms frames to make a 120ms packet, even for SILK-only mode where frames can be up to 60ms. For SILK, two 60ms frames would be a more

Hi Jean-Marc, 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. > That was my intention with refactoring out the subframe encoding and repacketizing bit. Or do you mean I should merge the explicit check for 120 ms frame and the existing checks for 40/60 ms wideband? Thanks, Felicia

OK, I've amended the second patch and also added 80 and 100 ms. Thanks, Felicia On Thu, Jun 2, 2016 at 7:20 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 06/01/2016 02:06 PM, Felicia Lim wrote: > > That was my intention with refactoring out the subframe encoding and > > repacketizing bit. Or do you mean I should merge the explicit check for > > 120 ms