similar to: Determine number of 20ms frames in packet - without decoding

Jean-Marc Valin wrote: > David Hogan wrote: > >> Does anyone know a practical way to determine the number of 20ms speex >> frames in a given speex packet without actually looping on speex_decode* ? >> > > There's no ready-made function for that. You'd have to write a function > that inspects the bits, determines what mode is involved, and jump the

David Hogan wrote: > Does anyone know a practical way to determine the number of 20ms speex > frames in a given speex packet without actually looping on speex_decode* ? There's no ready-made function for that. You'd have to write a function that inspects the bits, determines what mode is involved, and jump the right number of bits until a terminator is found or there's no more

Hi, On 2/9/08, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > Alexander Chemeris a ?crit : > > Hi Jean-Marc, > > Is your proposition that ever this code will be written in terms > > of internal Speex bits it will be included into libspeex still in force? > > yes. I'd like to include that if someone writes it using SpeexBits. Here is first attempt.

Hi, Ok, here is cleaned up and fixed version. * Function is named speex_get_num_frames() now and return number of frames, as you suggested. * WB layers sizes are taken from wb_skip_table[], while NB frame sizes are calculated with speex_mode_query(). I've tested it with testenc in NB, WB and UWB modes with VBR enabled to test in as many cases as possible. It seems to work fine. Though,

For clarity I attached modified testenc.c I used to test my code. On 2/14/08, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > > I also think that having rame_num.c in libspeex, code size could be > > reduced and simplified slightly by using speex_skip_wb_frame() in > > nb_decode() instead of duplicating code. > > Well, the code is a bit different (e.g.

On 2/16/08, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > > Oh, you're right, inband handling is different, but it's a matter of one > > flag, passed to functioin. Probably not that much to keep code DRY. > > Well, let's first merge your code and then we'll see about possible > simplifications. Waiting for your decision ;) I guess you stopped

On 2/20/08, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > Alexander Chemeris wrote: > > On 2/16/08, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > >>> Oh, you're right, inband handling is different, but it's a matter of one > >>> flag, passed to functioin. Probably not that much to keep code DRY. > >> Well,

Hi, Bringing up this unfinished old thread. Here are my patches: wb_skip_table-fix-and-move.diff - fixes the issue with wb_skip_table and makes it available for use outside of nb_celp.c (we need it for the second patch). speex_bits_get_num_frames.diff - adds speex_bits_get_num_frames() method as we discussed. Hope to see this incorporated into trunk ;) On Thu, Feb 21, 2008 at 12:10 PM,

Alexander Chemeris a ?crit : > Hi Jean-Marc, > Is your proposition that ever this code will be written in terms > of internal Speex bits it will be included into libspeex still in force? yes. I'd like to include that if someone writes it using SpeexBits. Cheers, Jean-Marc

> Ok, here is cleaned up and fixed version. > > * Function is named speex_get_num_frames() now and return > number of frames, as you suggested. > * WB layers sizes are taken from wb_skip_table[], while NB frame > sizes are calculated with speex_mode_query(). Looking better. Just make sure to remove the stuff that isn't C99-compatible (e.g. // comments). > I've

> Oh, you're right, inband handling is different, but it's a matter of one > flag, passed to functioin. Probably not that much to keep code DRY. Well, let's first merge your code and then we'll see about possible simplifications. >> frame: 20 ms encoding >> sub-frame: 5 ms encoding (internal) >> layer: one frame of nb or sb >> sb: sub-band >>

Hi Alexander, > Here is first attempt. I'm sending it here for review - am I understand > you correctly? If general approach is correct, I'll change code to use > modes from modes.c. I haven't tested, but it looks sane. Just a few comments: - printf("\tERROR not enough bits left after wb\n"); this is actually now an error. It just means you got to the end of the

Alexander Chemeris wrote: > On 2/16/08, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: >>> Oh, you're right, inband handling is different, but it's a matter of one >>> flag, passed to functioin. Probably not that much to keep code DRY. >> Well, let's first merge your code and then we'll see about possible >> simplifications. >

>> Oh, your table looked fine. I think it's mine that was wrong for the >> "null mode" (which nobody ever uses I guess!). > > I'm not sure, but I guess it may be used in VBR or DTX mode? > At least that's why I kept it. Of course it *can* be used (and needs fixing). It just seems few people did :-) > So, what's the next step towards

David, Here's the trick ... do this just before your speex_bits_write(): speex_bits_insert_terminator(&bits); Then, when decoding, keep calling speex_decode() until it returns -1 or speex_bits_remaining(&bits) returns 0. Works for me, anyway. Tom David Barrett (dbarrett@quinthar.com) wrote: > > Hi, I'm using Speex and I want to pack multiple frames into a single >

I've just started testing Speex, and it seems very good so far. In testing the Speex decoder and simulating packet loss, I noticed that simply not calling speex_decode(st, NULL, output) when a packet is dropped doesn't appear to degrade the quality of the audio later on. The reason for this test is that in a real-time situation, you may not know right away when a packet is dropped

Jean-Marc Valin wrote: >>I believe it is adaptive, but no, I haven't used it, because it's >>coupled only to the speex codec. We're working on a generic >>application and codec-independent jitter buffer algorithm, for use in >>asterisk and iaxclient (at least). Some information is available at

On Saturday 10 April 2010 21.51.55 Jean-Marc Valin wrote: > All version after 1.0 are compatible with each other and with 1.0. Hi Jean-Marc and thanks for the quick reply. I have now looked at this further and got the idea to hard code the number of frames in the decoder temporarily as a test and voil?, it works! The problem seem to be some incompatibility in the termination handling. After

I tried feeding in the 3 encoded frame in ONE BLOCK, and calling speex_decode() 3 times in a roll. Only the 1st frames came out perfectly. For the other 2, I got "corrupt" frame warning. I was supposed to get 38 bytes consumed each frame (narrow-band, VBR off). I tried speex_bits_remaining() to peek on the # of bits consumed, and got variable (clearly wrong)#s returned. But if I

Hi list, I'm trying to figure out how to do the most compatible implementation that will work with as many versions of Speex as possible. I am streaming multi frame Speex blocks over a TCP connection which works fine as long as the version of Speex is the same on both sides. When using a newer Speex (1.1.?) to encode and an older version to decode (1.0.5), it does not work. The encoder