search for: repacketization

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 them then split them with the

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

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 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 the multistream encoder as we...

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

...; Felicia > > > > On Tue, May 31, 2016 at 7:05 PM Felicia Lim <flim at google.com > <mailto:flim at google.com>> wrote: > > 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 lat...

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

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

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

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

...might be missing something? Please find my updated patches attached. Thanks, Felicia On Tue, May 31, 2016 at 7:05 PM Felicia Lim <flim at google.com> wrote: > 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 the multi...

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