[FFmpeg-devel] [PATCH] QCELP decoder

[Michael Niedermayer]

On Sat, Oct 11, 2008 at 05:32:26PM -0700, Kenan Gillet wrote:
> 
> On Oct 11, 2008, at 9:26 AM, Michael Niedermayer wrote:
> 
> > On Sat, Oct 11, 2008 at 12:30:48PM +0200, Benjamin Larsson wrote:
> >> Hi.
> >>
> >>>
> >>> The patch using the reference code is at [2].
> >>> As a plan of action, I propose to work on the inclusion of this  
> >>> patch
> >>> as a first
> >>> step, and then continue on working the SoC decoder
> >>>
> >>> what do you think ?
> >>
> >> Well we removed the amr reference code support because of license
> >> issues, so I don't think we should add more code in. The best way  
> >> to do
> >> this is to add working reference glue code to the SoC qcelp tree.
> >
> > i agree
> 
> ok, i have starting to get familiar with the code.

just to clarify, my agreeing was mostly toward that the reference code
should not be added to ffmpeg svn or supported by ffmpeg svn.
i have no oppinion on doing somehing with it in the soc tree.


> 
> 
> 
> >> Then
> >> port the current decoder to fixed point. Then make sure the decoder  
> >> is
> >> bit exact compared to the reference source. This would remove any  
> >> doubt
> >> of compliance but it would be alot of work. There is lots of fixed  
> >> point
> >> code available in in the g729 patches that are aimed for speech  
> >> codecs.
> >> So are you up for all that work ? You could get svn commit access  
> >> to the
> >> qcelp soc tree if that would help out your work and the review  
> >> process.
> >
> > i think we should be aiming at a float+fixed point implementation
> > both have advantages. I do not think throwing the float away and  
> > replacing
> > it by fixed point is such a good idea. fixed point likely is slower on
> > modern cpus but then its very usefull for regression tests and fpu- 
> > less
> > cpus.
> > Also bit exactness and sharing code between g729, amr and qcelp may  
> > become
> > tricky though of course both should be attepted where its possible,  
> > where its
> > not some compromise has to be found.
> 
> It sounds much bigger of a project that I envision. But I am really  
> interested in
> getting it down the right way.
> 
> My only concern would be about the fixed point reference code, because  
> the
> code at [1] looks like a float implementation to me, and that the only  
> reference
> code I am aware of.
> I have been googling to get some fixed point reference but could not  
> find any
> so far.

ok, if theres no fixed point reference, then theres also no point in
writing one for regression/compliance tests.
That would leave fpuless cpus as primary use case, anyway, iam not
insisting on supporting both for the initial version of qcelp that
gets commited, better just one but otherwise fast and clean code.
fixed point support could be added later IMHO ...

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

> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- 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/20081012/61d0f086/attachment.pgp>