Speex dev - Jul 2009 - Determine number of 20ms frames in packet - without decoding

>> 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

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, Jean-Marc
Valin<jean-marc.valin at usherbrooke.ca> wrote:
>>> 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
>


-- 
Regards,
Alexander Chemeris.

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wb_skip_table-fix-and-move.diff
Type: text/x-diff
Size: 1317 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20090713/9f2ea6f5/attachment.diff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: speex_bits_get_num_frames.diff
Type: text/x-diff
Size: 4999 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20090713/9f2ea6f5/attachment-0001.diff

Follow up - patch to make this new function available
on Windows from DLL.

On Mon, Jul 13, 2009 at 12:41 AM, Alexander
Chemeris<Alexander.Chemeris at sipez.com> wrote:
> 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, Jean-Marc
> Valin<jean-marc.valin at usherbrooke.ca> wrote:
>>>> 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
>>
>
>
>
> --
> Regards,
> Alexander Chemeris.
>
> SIPez LLC.
> SIP VoIP, IM and Presence Consulting
> http://www.SIPez.com
> tel: +1 (617) 273-4000
>


-- 
Regards,
Alexander Chemeris.

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libspeex.def.diff
Type: text/x-diff
Size: 291 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20090713/559d7607/attachment.diff