[FFmpeg-devel] [PATCH 02/14] libavcodec: Implementation of AAC_fixed_decoder (LC-module) [2/5]

[Michael Niedermayer]

Hi

On Mon, Oct 06, 2014 at 10:40:51AM +0000, Nedeljko Babic wrote:
> Hi and sorry for such a late response.
> 
> It looks that I misplaced this mail...
> 
> > From: Djordje Pesut <djordje.pesut at imgtec.com>
> >> 
> >> Add float emulation
> >> 
> >> Signed-off-by: Nedeljko Babic <nedeljko.babic at imgtec.com>
> >> ---
> >>  libavcodec/float_emu.h     | 295 +++++++++++++++++++++++++++++++++++++++++++++
> >>  libavcodec/float_emu_tab.c | 293 ++++++++++++++++++++++++++++++++++++++++++++
> >>  2 files changed, 588 insertions(+)
> >>  create mode 100644 libavcodec/float_emu.h
> >>  create mode 100644 libavcodec/float_emu_tab.c
> >
> >theres libavutil/softfloat
> >
> >I dont see why this should be re implemented in each decoder
> >If you can improve softfloat, please do
> >
> >[...]
> >
> 
> If I am not mistaking, there is one (possibly two) more implementations of 
> float emulation besides softfloat in ffmpeg (dca encoder and lagarith decoder),

lagarith is a lossless codec, it needs a "bitexact to the reference"
implementation, so it cannot easily be shared



> but I do agree that it is more maintainable to have one float emulation and I
> am willing to integrate our emulation in softfloat.
> 
> However, there is a difference in some conventions used (for example is it more
> important to represent exactly 0.5 or 1, order of fields in struct that
> represents emulated float, etc.) and our aac implementation is tailored to use
> our float emulation.

i dont understand what you mean by 0.5 vs 1 ?
floats are base 2 so both 0.5 and 1 can be represented exactly


> 
> Could I assume that in such cases I can change convention that is used in
> softfloat with convection that we use, since I don't see that softfloat is used
> anywhere in ffmpeg currently?
> 
> That way we could integrate our code without need to change aac implementation
> and without need for changes in parts of float emulation that are not supported
> in softfloat currently (sqrt and sincos).
> 

> Also, there is a question that Reimar initiated in his review of whether it's
> more important to optimize the case where an operand is 0 or to reduce the
> number of branches.

this is hard to awnser without having code in place that uses the
softfloat stuff so that we are able to benchmark

but id say if the cost for a 0 check is very small and its gain are
very big then its likely a good idea
also theres the question why add/mul would be called with trivial
arguments, this is potentially a sign that the calling code is poorly
written and performs avoidable operations


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141007/5dc262c9/attachment.asc>