[FFmpeg-devel] [PATCH] G.729A (floating-point) decoder and ACT demuxer

Vladimir Voroshilov voroshil
Mon Feb 25 15:53:44 CET 2008


On Sun, Feb 24, 2008 at 11:48 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>
> On Sun, Feb 24, 2008 at 11:36:05PM +0600, Vladimir Voroshilov wrote:
>  > On Sun, Feb 24, 2008 at 11:18 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>  > > On Sun, Feb 24, 2008 at 09:39:21PM +0600, Vladimir Voroshilov wrote:
>  > >  > Hi, Reimar
>  > >  >
>  > >  > this is reply on g729a decoder related issues.
>  > >  >
>  > >  > On Sun, Feb 24, 2008 at 12:39 AM, Reimar D?ffinger
>  > >  > <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
>  > >  >
>  > >  > > [...]
>  > >  >
>  > >  > >  > +/**
>  > >  > >  > + * L1 codebook (10-dimensional, with 128 entries (3.2.4)
>  > >  > >  > + */
>  > >  > >  > +static const float cb_L1[128][10] = {
>  > >  > >
>  > >  > >  These constants btw. look very much like they were designed with a
>  > >  > >  16-bit fixed-point implementation in mind...
>  > >  >
>  > >  > L1 L2 L3 - are three different codebooks mentioned in specification.
>  > >  > Exact values are not described anywhere (or i was not searching carefully),
>  > >
>  > >  2.4      Speech coder description
>  > >  The description of the speech coding algorithm of this Recommendation is made in terms of
>  > >  bit-exact fixed-point mathematical operations. The ANSI C code indicated in clause 5, which
>  > >  constitutes an integral part of this Recommendation, reflects this bit-exact fixed-point descriptive
>  > >  approach. The mathematical descriptions of the encoder (clause 3), and decoder (clause 4), can be
>  > >  implemented in several other fashions, possibly leading to a codec implementation not complying
>  > >  with this Recommendation. Therefore, the algorithm description of the ANSI C code of clause 5
>  > >  shall take precedence over the mathematical descriptions of clauses 3 and 4 whenever discrepancies
>  > >  are found. A non-exhaustive set of test signals, which can be used with the ANSI C code, are
>  > >  available from the ITU.
>  > >
>  > >
>  > >
>  > >  > current values are got from floating-point reference code.
>  > >
>  > >  As written in the spec, the fixed point implementation conains the bit exact
>  > >  values.
>  > >
>  >
>  > C.5     ANSI C code
>  > [...] The algorithmic description given by the C code shall take
>  > precedence over the texts contained in the main body of the full
>  > version of G.729, Annex A or this annex. As of the approval of this
>  > text, the current version of this ANSI C code is Version 1.01 of 15
>  > September 1998. More recent versions may become available through
>  > corrigenda or amendments to G.729. Please ensure to use the latest
>  > available version from the ITU-T website. [...]
>  >
>  >
>  > So constants can be got from floating-point reference code too, right?
>
>
>  5 Bit-exact description of the CS-ACELP coder
>
>  ANSI C code simulating the CS-ACELP coder in 16 bit fixed-point is available from ITU-T. As of
>                                              ^^^^^^^^^^^^^^^^^^
>  the approval of this version of this Recommendation, the current version of this ANSI C code is
>  Version 3.3 of December 1995. More recent versions may become available through corrigenda or
>  amendments to this Recommendation. Please ensure to use the latest available version from the
>  ITU-T website. The following clauses summarize the use of this simulation code, and how the
>  software is organized.
>
>  --------------
>  C.3     Overview
>  The full version of G.729 provides bit-exact fixed-point specification of an algorithm for the coding
>                                    ^^^^^^^^^^^^^^^^^^^^^
>  of speech signals at 8 kbit/s. Annex A is a reduced complexity version interoperable with the full
>  version of G.729. Exact details of these specifications are given in bit-exact fixed-point C code
>  available from ITU-T. This annex describes and defines an alternative implementation of the full
>  version of G.729 and Annex A based on floating-point arithmetic.
>
>  --------------
>
>  Why would we choose the floating point approximation if we can have an
>  exact integer implementation ?

My skills are enough only for either cleanup current (working)
floating-point code or 'port' (remove globals, fix data types, write
interface to FFmpeg internals) reference code to ffmpeg.
Thus, in fixed-point case, code will be 95% the same as reference.

-- 
Regards,
Vladimir Voroshilov mailto:voroshil at gmail.com
JID: voroshil at gmail.com, voroshil at jabber.ru
ICQ: 95587719




More information about the ffmpeg-devel mailing list