similar to: Can decoder adapts to different mode per frame ?

if the new draft in the manual is used. I don't find how to tell the decoder which mode(NB/WB/UWB) is used in the encoder. The RTP header don't contain the mode field and I don't find the mode information in the coded frame either. Does this mean we have to use NB decoder in all cases? Lianghu On 11/22/06, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > >

On Wed, 6 Dec 2006, lianghu xu wrote: > Hi Jean-Marc, > > I remember you said that the SDP tells the mode information. Right. But a decoder like speex can always be configured from information contained in the incoming stream. That makes your application more interroperable. Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 -

In a word, I don't what's the standard of speex payload format. The file doc/rtp.txt is for what? Is it not for rtp payload? I find that rtp.txt is more detail that draft02.txt Which rtp docment should be followed? Anyone else has written the RTP wrapper already? Lianghu On 11/22/06, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > > > 1) First, I think there is

There's a field in the SDP description for narrowband/wideband/ultrawideband. Jean-Marc lianghu xu wrote: > if the new draft in the manual is used. I don't find how to tell the > decoder which mode(NB/WB/UWB) is used > in the encoder. The RTP header don't contain the mode field and I don't > find the mode information in the > coded frame either. > >

Hi Jean-Marc, > Can you confirm I'm understanding everything correctly? You encode > with > the same encoder and then decode with either A) blackfin assembly and > fixed-point or B) fixed-point only on Blackfin. Then A) sounds bad and > B) sounds good. If you do the same in narrowband, it sounds OK. Is > that > correct? If that's the case, it's *probably* some

In a "normal" frame that doesn't have in-band signalling (which nobody seems to use anyway), the frame starts with the narrowband information. If the frame is in wideband, then this will be followed by a bit of wideband information that starts with a bit set to 1 (narrowband starts with a bit set to 0). Have a look at what the Speex decoder does. You may actually want to have similar

> 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

Hi all, One question that I hope someone on the list just knows the answer to without having to delve too deeply into the code: How does UWB mode divvy up the bandwidth and pack it in the bitstream? I know from the documentation that WB mode codes the first 0-4K kHz band as a Narrowband packet, and then adds on the 4-8 kHz band coded separately (so that a NB decoder can decode a WB bitstream

Hi Marc, Thanks for your quick response. So if VAD is enabled then VBR will be enable although it's a special VBR. How about take out the VAD code from the VBR and remove the code else? Lianghu On 10/24/06, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > > > 1) there are VAD related codes in the source file preprocess.c. > > Will VAD still work If I

Hi all Speexers, I've done some optimization to current SVN fixed-point on ARM9E platform. If the RVDS simulator gives the MCPS(Million Cycle Per Second) value A, then actual MCPS on real CPU will be around 2*A. I don't know what cause the big gap between the simulator and real CPU. What do you think? BR, Lianghu -------------- next part -------------- An HTML attachment was

Hi, Can someone please tell me how should I go about changing the frame size which is hardcoded to 160 for NB and WB and 320 for UWB. For NB speech(8KHz) the framesize of 160 is 20ms frame but for WB and UWB its 10ms. What are the parameters being affected by simply changing the framesize and sub-frame size in "modes.c" How to change the buffer size and how its affected. can we have a

Hello, In the internet draft describing the SDP parameters for speex I find this: mode: Speex encoding mode. Can be {1,2,3,4,5,6,any} defaults to 3 in narrowband, 6 in wide and ultra-wide. In the documentation I can only find the following request: SPEEX_SET_MODE There is no description though what this request does. I think the mode somehow maps to the bitrate, but I

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: output.wav Type: audio/x-wav Size: 259244 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20061127/546b3a06/output-0001.wav -------------- next part -------------- A non-text attachment was scrubbed... Name: input.inp Type:

Speex tells me that the decoder is always 5 ms, but it says that the encoder is 5 ms for NB, 8.9375 ms for WB, and 10.90625 ms for UWB. Is there an extra frame of delay in the encoder that isn't otherwise accounted for? John Ridges Jean-Marc Valin wrote: > Quoting John Ridges <jridges at masque.com>: > >> I also need to know the precise delays from Speex but I used

JM, I also need to know the precise delays from Speex but I used the SPEEX_GET_LOOKAHEAD control requests to determine them (plus the "speex_resampler_get_output_latency" function from the resampler). The returned values from the Speex lookahead request don't seem to match with the values you gave Alexander. Am I doing this wrong? Thanks, John Ridges speex-dev-request at

> 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 Jean Marc and List, So I have started finally fiddling around with Ultra-wideband mode. It appears to be very similar in operation to Wide mode, except that when peering into the packet structure it looks like (and these are kind of questions as much as statements here): 1. update rate 0 is not used in UWB- only 1-4? 2. The total bits used for each UWB update rate seem to be as follows:

Hi, I am currently encoding 32 Khz/Qual-10/UWB encode mode, with MANUAL_ALLOC enabled ( similar to the c5x/c6x configuration). In file sb_celp.c, I noticed the scratch memory grow during recursive (UWB -> WB) calls to 'sb_encode'. 1. 'stack' was not tracked (with 'tmp_stack' as done at other palaces) after/before - auto-correlation/Levinson-Durbin scope (~line

Hello Jean-Marc, > Could you try mixing the encoders and decoders (encode with one > version, > decode with the other) to see whether the problem is in the > encoder, the > decoder or both. I tested that,and the results are: The fixedpoint+blackfin encoder used together with the fixedpoint-only decoder produces an bad sounding file (for all the combinations for quality

Hi list! There seem to be some oddities in using ABR. The first thing I notice is that because "abr_count" increases without bound, after a while the weight of the bitrate history will completely swamp any change in the current bitrate and the ABR adjustment will essentially stop happening. This seems to be true in any mode (not just UWB) and perhaps a solution is to cap