[FFmpeg-devel] [PATCH] QCELP decoder

Kenan Gillet kenan.gillet
Tue Dec 2 02:45:26 CET 2008


Hi,
On Mon, Dec 1, 2008 at 3:32 PM, Kenan Gillet <kenan.gillet at gmail.com> wrote:
>
> 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 :)
>
> :)
>

here is an updated version of qcelp_lsp.c which had been already oked
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: qcelp-round16-lsp.patch.txt
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081201/623fb8a2/attachment.txt>



More information about the ffmpeg-devel mailing list