search for: repacketize

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

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

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

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

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?

...ptime) or state a maximum length (with maxptime), so when Asterisk receives the 40ms media frames from the handset, it simply relays it on to the ITSP. Unfortunately the ITSP doesn't support this, and the result is one-way audio. I would like to know whether there is a way to force Asterisk to repacketize the media stream, converting from 40ms frames to 20ms frames. I am aware of the allow=alaw:20 syntax but this doesn't seem to work. It is not clear from the docs whether that setting is for the SDP offer (in which case it would only affect incoming media) or whether it's used to to actually...

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

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

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

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

...an 60ms regardless of mode. Nevertheless you may still want to move up the lines that finalize st->mode if you want to use it to determine the size of each frame as mentioned above. That would also allow this if-condition to be further simplified. > +static opus_int32 encode_subframes_and_repacketize(OpusEncoder *st, > + const opus_val16 *pcm, > + int nb_frames, > + int frame_size, > + unsigned char *data, > + opus_int32 out_da...

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