search for: bytes_per_fram

...ls is there still a need for it to be split out into a separate function? If it had a simple and concise interface then it may make sense even with one call, but in this case the arguments that it requires are numerous and peculiar to the specific implementation in the calling function. > + bytes_per_frame = IMIN(1276,(out_data_bytes-3)/nb_frames); The current code uses this formula because with up to 3 frames per packet, in the worst case the combined packet will require nb_frames*bytes_per_frame + 3 bytes (where bytes_per_frame is the code 0 packet length, as it is here). However the worst case...

...rpose of this code more > explicit in opus_encode_native. I agree though that there are a lot of > input arguments (it could be reduced by 1 by moving the nr_subframes > calculation in here as well). I can also undo this split if this is > preferred? > > >> >> > + bytes_per_frame = IMIN(1276,(out_data_bytes-3)/nb_frames); >> >> The current code uses this formula because with up to 3 frames per >> packet, in the worst case the combined packet will require >> nb_frames*bytes_per_frame + 3 bytes (where bytes_per_frame is the code >> 0 packet leng...

...agree though that there are a lot of > >> input arguments (it could be reduced by 1 by moving the nr_subframes > >> calculation in here as well). I can also undo this split if this is > >> preferred? > >> > >> > >>> > >>> > + bytes_per_frame = IMIN(1276,(out_data_bytes-3)/nb_frames); > >>> > >>> The current code uses this formula because with up to 3 frames per > >>> packet, in the worst case the combined packet will require > >>> nb_frames*bytes_per_frame + 3 bytes (where bytes_per_fram...

...stand by itself and it makes the purpose of this code more explicit in opus_encode_native. I agree though that there are a lot of input arguments (it could be reduced by 1 by moving the nr_subframes calculation in here as well). I can also undo this split if this is preferred? > > > + bytes_per_frame = IMIN(1276,(out_data_bytes-3)/nb_frames); > > The current code uses this formula because with up to 3 frames per > packet, in the worst case the combined packet will require > nb_frames*bytes_per_frame + 3 bytes (where bytes_per_frame is the code > 0 packet length, as it is here)....

...explicit in opus_encode_native. I agree though that there are a lot of >> input arguments (it could be reduced by 1 by moving the nr_subframes >> calculation in here as well). I can also undo this split if this is >> preferred? >> >> >>> >>> > + bytes_per_frame = IMIN(1276,(out_data_bytes-3)/nb_frames); >>> >>> The current code uses this formula because with up to 3 frames per >>> packet, in the worst case the combined packet will require >>> nb_frames*bytes_per_frame + 3 bytes (where bytes_per_frame is the code >&g...

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

...any times. Something like > > ? ? ? ? ? ? ? ?speex_bits_reset( &bits ); > ? ? ? ? ? ? ? ?for( n = 0; n < num_frames; ++n ) > ? ? ? ? ? ? ? ?{ > ? ? ? ? ? ? ? ? ? ? ? ?speex_encode_int( enc_state, (int16_t*)input_tail, > &bits ); > ? ? ? ? ? ? ? ? ? ? ? ?input_tail += BYTES_PER_FRAME; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?speex_bits_insert_terminator( &bits ); > ? ? ? ? ? ? ? ?n = speex_bits_nbytes( &bits ) + RTP_HEADER_SIZE; > > Of course, I was sending RTP packets. > > On the decoding side, I was using the jitter buffer, but I never managed to >...

Alright noted, I changed me code so that the state is created in the constructor and destroyed in the destructor of the object. However I'm still getting the same issue although I'm sure that would have bit me sooner or later. The new code is as follows. virtual Enigma::u8* Encode(Enigma::u8* inputBuffer,size_t inputSize, size_t& outputSize) { short *in=(short*)inputBuffer;

...ex_encode_int() that many times. Something like speex_bits_reset( &bits ); for( n = 0; n < num_frames; ++n ) { speex_encode_int( enc_state, (int16_t*)input_tail, &bits ); input_tail += BYTES_PER_FRAME; } speex_bits_insert_terminator( &bits ); n = speex_bits_nbytes( &bits ) + RTP_HEADER_SIZE; Of course, I was sending RTP packets. On the decoding side, I was using the jitter buffer, but I never managed to figure out exactly how that w...

...rse=1,snr = 99.399426 nfft=480 inverse=0,snr = 111.250587 nfft=480 inverse=1,snr = 111.435401 PASS: mdct-test PASS: mathops-test Error: celt_decode returned unknown error Error: celt_decode returned unknown error Error: celt_decode returned unknown error Error: at 30 bytes_per_frame celt_decode returned unknown error CELT codec tests. Random seed: 1844038323 (DD39) Testing asynchronous tandeming (48000Hz, 1ch, 960 samples, 30 - 320 bytes). FAIL: tandem-test =================== 1 of 8 tests failed =================== make[2]: *** [check-TESTS] E...

Hi Josh, Here are all the patches that are currently applied to the Debian packages for flac. You may disagree with some of them but as the current maintainer, I'm submitting them all for your consideration. (I should've submitted them earlier, but I've been quite busy. Sorry!) Here is a listing of the patches that I'll be sending: Patch 1 fixes a simple typo in metaflac