[FFmpeg-devel] [PATCH] QCELP decoder

Michael Niedermayer michaelni
Tue Dec 2 00:57:11 CET 2008


On Mon, Dec 01, 2008 at 03:32:00PM -0800, Kenan Gillet 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

perfect
(me wonders why noone suggested its an approximation of 169/171)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081202/7de147eb/attachment.pgp>



More information about the ffmpeg-devel mailing list