[FFmpeg-devel] [PATCH] QCELP decoder

[Kenan Gillet]

On Dec 1, 2008, at 3:18 PM, Michael Niedermayer wrote:

> On Mon, Dec 01, 2008 at 03:00:49PM -0800, Kenan Gillet wrote:
>>
>> On Dec 1, 2008, at 2:05 PM, Michael Niedermayer wrote:
>>
>>> On Mon, Dec 01, 2008 at 12:45:09PM -0800, Kenan Gillet wrote:
>>>> Hi,
>>>> On Mon, Dec 1, 2008 at 8:24 AM, Michael Niedermayer
>>>> <michaelni at gmx.at> wrote:
>>>>> On Mon, Dec 01, 2008 at 08:17:52AM -0800, Kenan Gillet wrote:
>>>>>>
>>>>>> On Dec 1, 2008, at 4:52 AM, Michael Niedermayer wrote:
>>>>>>
>>>>>>> On Sun, Nov 30, 2008 at 05:04:07PM -0800, Kenan Gillet wrote:
>>>>>>>> Hi,
>>>>>>>> On Nov 30, 2008, at 7:50 AM, Michael Niedermayer wrote:
>>>>>>>>
>>>>>>>>> On Sat, Nov 29, 2008 at 10:39:58AM -0800, Kenan Gillet wrote:
>>>>> [...]
>>>>>>> [...]
>>>>>>>>>> +    /**
>>>>>>>>>> +     * reserved bits on all bitrate but bitrate 1/2 packets
>>>>>>>>>
>>>>>>>>> this is unclear, field that is on all but ... , vs. field that
>>>>>>>>> exists always but
>>>>>>>>> is reserved on all but .....
>>>>>>>>>
>>>>>>>>
>>>>>>>> is "reserved bits only set for bitrate 1, 1/4 and 1/8" better ?
>>>>>>>
>>>>>>> no, because setting them means error IIRC
>>>>>>> also IIRC there is no indication of the existence of other  
>>>>>>> fields
>>>>>>> for the
>>>>>>> other rates ...
>>>>>>>
>>>>>>
>>>>>> reserved bits only present in bitrate 1, 1/4 and 1/8 packets
>>>>>>
>>>>>> ?
>>>>>
>>>>> ok
>>>>>
>>>>> [...]
>>>>
>>>> here is an updated round 14 of the patches,
>>>> which is getting smaller and smaller :)
>>>>
>>>> Kenan
>>>
>>> [...]
>>>
>>>> +/**
>>>> + * initial coefficient to perform bandwidth expansion on LPC
>>>> + *
>>>> + * TIA/EIA/IS-733 2.4.3.3.6 6
>>>> + */
>>>
>>>> +#define QCELP_BANDWITH_EXPANSION_COEFF 0.9883
>>>
>>> i suspect that is supposed to be an approximation of 253/256
>>
>> probably but in specs and reference code it is 0.9883 not 0.98828125.
>> do you want to replace 0.9883 by 253/256 ?
>
> no, but it could be added in a comment

how about a note in the doxy?
@note: 0.9883 looks like an approximation of 253/256

I'll add it to the next round of patches if it is ok.


>
>
> [...]
>> also I am interested to know if u had any comments on the  
>> benchmarks [1]
>> between old double vs old float
>> and new double vs new float
>
> no comment :)

:)