similar to: No subject

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

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

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, 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 Mark, Jean-Marc, Thanks for your comments. On Sun, Jun 12, 2016 at 6:34 AM Mark Harris <mark.hsj at gmail.com> wrote: > 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 =

Hi! A note on style: Looking at this chunk of the patch -- @@ -382,9 +382,15 @@ int main(int argc, char *argv[]) frame_size = sampling_rate/25; else if (strcmp(argv[ args + 1 ], "60")==0) frame_size = 3*sampling_rate/50; + else if (strcmp(argv[ args + 1 ], "80")==0) + frame_size = 4*sampling_rate/50; +

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

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>

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

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:

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 >

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 all, i try to set up something like a mixer and soundbridge. There are several sender clients which sends opus encoded audiostreams. One basestation is decoding the streams and mixing them all together. After that, the resulting stream is encoded with opus again and send to one or two receiving clients. Opus is set up to encode 10ms packets in stereo with 16bit per sample and 44kHz. So,

HI, I'm trying to simulate an audio conference where each leg can be with a different bit rate. This needs to encode the source PCM to to different bit rates back to back and store and send respective encoded frames/packet to the respective channel. For this I changed the opus_demo as below. But the output of the second encoded frames is completely garbled. Appreciate if anyone can suggest

If you encode with int iByteSizeEncoded = opus_encode(m_enc, m_ShortsInput, (1920/sizeof(short)), m_EncodedBytes, (960*6)); ... the byte size is 120. I thought that an odd value like 359 has to be a fault on my side. I thought it would be a multiple of something. So 359 is really correct??? Thank you for clearing this up. Am 06.10.2013 16:50, schrieb Jean-Marc Valin: > Why

Hi All, We are using libopus 1.0.2 lib version currently and observing one crash issue in opus_encode() function some times. ------------------------------------------- (gdb) bt #0 0x00007fcdf7c90ea2 in opus_encode () from /usr/lib64/libopus.so.0 -------------------------------------------- Anybody faced this problem earlier and have any idea whether its solved in the latest version libopus

Hello! I have been using int iByteSizeEncoded = opus_encode(m_enc, m_ShortRawInput,960,m_EncodedBytes, 4000); iByteSizeEncoded was 120 as expected. Now when I double the frame size... int iByteSizeEncoded = opus_encode(m_enc, m_ShortRawInput,960*2,m_EncodedBytes, 4000); ... iByteSizeEncoded is not 240 as expected, but 239. This seems really odd to me since 239 bytes could not even be