Speex dev - Feb 2008 - Determine number of 20ms frames in packet - without decoding

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.
> 
> Waiting for your decision ;)
> I guess you stopped on the fact you need to check my statement
> about wb_skip_table?
Oh, your table looked fine. I think it's mine that was wrong for the
"null mode" (which nobody ever uses I guess!).
> It would be good to define - it is very misleading for newcomers
> as it is now. And I would like to say, that from user point of view
> "frame" meaning all "layers" is natural, because most
of users
> are not aware of any "layers" - they want to operate with encoded
> packet as a whole and do not think of internals. Actually, I've got
> some idea about "layers" only when was forced to write sample
> number calculation code.
Well, turns out I use frame size for both meanings -- which normally
isn't a problem because few people are directly aware of the
"layers" in
the first place.
> Sure. But in SDP you specify mode and not bitrate. ;) So I want
> to operate with the same things as in SDP.
I see. BTW, you can ask the full bit-rate to the encoder or decoder.
It's only the mode that give you the layer's bit-rate (which we might
want to change).

	Jean-Marc

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, let's first merge your code and then we'll see about
possible
> >> simplifications.
> >
> > Waiting for your decision ;)
> > I guess you stopped on the fact you need to check my statement
> > about wb_skip_table?
>
> 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.

So, what's the next step towards intergartion? I guess it should
be somehow made available from Speex API level, e.g. with
new speex_decoder_ctl() or speex_lib_ctl() request? I have
no idea about the best way here, and would appreciate your
advices.
> > It would be good to define - it is very misleading for newcomers
> > as it is now. And I would like to say, that from user point of view
> > "frame" meaning all "layers" is natural, because
most of users
> > are not aware of any "layers" - they want to operate with
encoded
> > packet as a whole and do not think of internals. Actually, I've
got
> > some idea about "layers" only when was forced to write
sample
> > number calculation code.
>
> Well, turns out I use frame size for both meanings -- which normally
> isn't a problem because few people are directly aware of the
"layers" in
> the first place.
Exactly.
> > Sure. But in SDP you specify mode and not bitrate. ;) So I want
> > to operate with the same things as in SDP.
>
> I see. BTW, you can ask the full bit-rate to the encoder or decoder.
> It's only the mode that give you the layer's bit-rate (which we
might
> want to change).
Sorry, not sure I follow you. What do you mean by "you can ask the full
bit-rate to the encoder or decoder"?


-- 
Regards,
Alexander Chemeris.

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000

>> 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 intergartion? I guess it should
> be somehow made available from Speex API level, e.g. with
> new speex_decoder_ctl() or speex_lib_ctl() request? I have
> no idea about the best way here, and would appreciate your
> advices.
I don't think it should be a _ctl() call because there's too much
potential for confusion. I would just keep it as a separate API call
like you have. I'd tend to put it in speex_bits.h, so I guess it should
be called speex_bits_get_number_of_frames() or something like that.
>>> Sure. But in SDP you specify mode and not bitrate. ;) So I want
>>> to operate with the same things as in SDP.
>> I see. BTW, you can ask the full bit-rate to the encoder or decoder.
>> It's only the mode that give you the layer's bit-rate (which we
might
>> want to change).
> 
> Sorry, not sure I follow you. What do you mean by "you can ask the
full
> bit-rate to the encoder or decoder"?
I mean that SPEEX_GET_BITRATE will actually return the total bit-rate in
bits per second.

Cheers,

	Jean-Marc