search for: 60ms

...y mail will not disturb your daily routine. My issue is I am connecting two asterisk over IIAX2/SIP trunk. I have successfully connected multiple server and every client from one server to call any other server's client. But problem is I want to use Speex@ 2.15kbs and also packetization time is 60ms but I can not achieve desired results I have debugged the call procedure codec offered is speex and ptime=60 but when I check the communication between two servers then it gives me packetization time on 20ms (but codec is speex) i.e 50-55 packets per second kindly can you provide me little regardin...

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 and feed them individually to the decode...

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?

Is is possible to give a short hint about how the jitter buffer would "catch up" when network condition have been bad and then get better? I'm using the jitter buffer with success now, but sometimes I have a long delay that's caused by bad network conditions and then later when the conditions get better, I would think we would want the audio to gradually catch up with real-time

...s anyway moot, since with VBR it's just a target value? When I increase the encoding complexity to 10, this won't have any noticeable effect on the decoding complexity, right? Last but not least, since my purpose would be listening to music, is it best to set the framesize to its maximum (60ms)? And will this have any bad side effects, like on gapless playback or so? Thanks, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5313 bytes Desc: not available Url : http://lists.xiph.org/pipermail/op...

...alculates how far ahead or behind the "current" timestamp it is; this is called arrival_margin. The "current" timestamp is simply the last frame successfully decoded. It maintains a list of bins for margins, this is short and longterm margin. Think of the bins like this: -60ms -40ms -20ms 0ms +20ms +40ms +60ms when a packet arrives, the margin matching it's arrivel_margin is increased, so if this packet was 40ms after the current timestamp, the 40ms bin would be increased. If this packet arrived 60ms too late (and hence is useless), the -60ms bin would increase....

...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 efficient way to encode a 120ms packet. Also FEC, if enabled, would be 3 times as effective. Similarly, two 40ms SILK frames would be more efficient than four 20ms SILK frames. - /* Can't support higher than wideband for >20 ms frames */ -...

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". Tha...

...gt; The "current" timestamp is simply the last frame successfully decoded. Minor detail, it's the last played (whether it was successfully decoded or not). > It maintains a list of bins for margins, this is short and longterm > margin. > Think of the bins like this: > -60ms -40ms -20ms 0ms +20ms +40ms +60ms > when a packet arrives, the margin matching it's arrivel_margin is > increased, so if this packet was 40ms after the current timestamp, the > 40ms bin would be increased. If this packet arrived 60ms too late (and > hence is useless), the -60ms b...

...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 efficient way to encode a 120ms packet. Also >> FEC, if enabled, would be 3 times as effective. Similarly, two 40ms >> SILK frames would be more efficient than four 20ms SILK frames. >> > > That makes sense, I've cha...

...catenating 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 2 or 3 > CELT-only or Hybrid frames for 40 or 60ms packet, respectively. 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...

...r); ogg_packet op; th_encode_packetout((th_enc_ctx*)m_encoderHandler,0,&op)>0 int TIMER_t1 = GetTickCount(); printf( "Timer : %d \n",TIMER_t1 - TIMER_t0 ); On average: *80 ms*. Using XVID I've obtained between *20-25 ms* for an image. That's 60ms longer using Theora. I don't know if I am doing something wrong while initializing the encoder, or that's the way it supposed to be. The encoder initialization used by me can be found here: http://integrasoft.ro/~mgliga/theora/theora_init.cpp <http://integrasoft.ro/%7Emgliga/theor...

...gt; > - 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 efficient way to encode a 120ms packet. Also > >>> FEC, if enabled, would be 3 times as effective. Similarly, two 40ms > >>> SILK frames would be more efficient than four 20ms SILK frames. > >>> >...

...guration of lmbench3 I ran a script doing 10 times a "make rerun". All results seem to be OK somehow. But I cannot explain why Xen is faster than the native installation when creating and deleting files? Its 12ms (DomU) against 24ms (native) for creating a 0K file and 50ms (DomU) against 60ms (native) for creating a 10K file. Please find all the results attached. Is there any way this is possible? Maybe the communication methods used by the shared device drivers make the virtual machine think the operation has been finished successfully faster than the native way? Is there is anyone ou...

...guration of lmbench3 I ran a script doing 10 times a "make rerun". All results seem to be OK somehow. But I cannot explain why Xen is faster than the native installation when creating and deleting files? Its 12ms (DomU) against 24ms (native) for creating a 0K file and 50ms (DomU) against 60ms (native) for creating a 10K file. Please find all the results attached. Is there any way this is possible? Maybe the communication methods used by the shared device drivers make the virtual machine think the operation has been finished successfully faster than the native way? Is there is anyone ou...

...*/ > > 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 efficient way to encode a 120ms packet. Also > FEC, if enabled, would be 3 times as effective. Similarly, two 40ms > SILK frames would be more efficient than four 20ms SILK frames. > That makes sense, I've changed it so that SILK 120/...

...39;m not able to use correctly this scheduler: $TC qdisc add dev $dev root handle 1: hfsc default 40 $TC class add dev $dev parent 1: classid 1:1 hfsc sc rate 10mbit ul rate 10mbit ### VOIP $TC class add dev $dev parent 1:1 classid 1:10 hfsc rt umax 1500b dmax 5ms rate 200kbit ls umax 1500b dmax 60ms rate 200kbit ul rate 200kbits ### Video $TC class add dev $dev parent 1:1 classid 1:20 hfsc rt umax 1500b dmax 10ms rate 5mbit ls umax 1500b dmax 60ms rate 5Mbit ul rate 5Mbit ## Data $TC class add dev $dev parent 1:1 classid 1:30 hfsc sc rate 1mbit ul rate 10mbit $TC class add dev $dev parent 1:1...

...ut 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/attachments/20131024/c4c59518/attachment.htm

Hi all, Please guide me How to change frame_size of opus codec at run-time (20ms, 40ms, 60ms) I'm stucking in this case: 1. init codec width default config (frame_size =20ms, bandwidth=48KHz, bitrate = 48kbps...), then in runtime changing: - bitrate = 24, 16, 6kbps: sound is OK - frame_size = 40ms, 60ms: Not OK, sound is distort so bad 2. init codec with frame_size = 40ms , others...

..." timestamp it is; this > is called arrival_margin. > The "current" timestamp is simply the last frame > successfully decoded. > > It maintains a list of bins for margins, this is short and > longterm margin. > > Think of the bins like this: > > -60ms -40ms -20ms 0ms +20ms +40ms +60ms > > when a packet arrives, the margin matching it's > arrivel_margin is increased, so if this packet was 40ms after > the current timestamp, the 40ms bin would be increased. If > this packet arrived 60ms too late (and hence is useless), the...