Hi and sorry for such a late response.
It looks that I misplaced this mail...
> From: Djordje Pesut <djordje.pe...@imgtec.com>
>>
>> Add float emulation
>>
>> Signed-off-by: Nedeljko Babic <nedeljko.ba...@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),
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.
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.
We have optimized cases when operands are zero for some operations. Should
I include this in softfloat, or should this kind of optimizations be left for
architecture/codec specific optimizations?
>> +typedef struct aac_float_t {
>> + int mant;
>> + int expo;
>> +} aac_float_t;
>
>float "emulation" isnt aac specific and *_t are reserved in POSIX
>IIRC
>
This float emulation was sent as part of implementation of aac fixed point
decoder. It is currently used only here and we did not know if/when it will be
used in any other codec.
On the other hand, I do agree that it is not aac specific and it will be
renamed in the new patch (when we integrate it with softfloat).
>
>[...]
>> diff --git a/libavcodec/float_emu_tab.c b/libavcodec/float_emu_tab.c
>> new file mode 100644
>> index 0000000..396a7a3
>> --- /dev/null
>> +++ b/libavcodec/float_emu_tab.c
>> @@ -0,0 +1,293 @@
>> +/*
>> + * Copyright (c) 2012
>> + * MIPS Technologies, Inc., California.
>> + *
>> + * Redistribution and use in source and binary forms, with or without
>> + * modification, are permitted provided that the following conditions
>> + * are met:
>> + * 1. Redistributions of source code must retain the above copyright
>> + * notice, this list of conditions and the following disclaimer.
>> + * 2. Redistributions in binary form must reproduce the above copyright
>> + * notice, this list of conditions and the following disclaimer in the
>> + * documentation and/or other materials provided with the distribution.
>> + * 3. Neither the name of the MIPS Technologies, Inc., nor the names of is
>> + * contributors may be used to endorse or promote products derived from
>> + * this software without specific prior written permission.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY THE MIPS TECHNOLOGIES, INC. ``AS IS'' AND
>> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
>> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>> PURPOSE
>> + * ARE DISCLAIMED. IN NO EVENT SHALL THE MIPS TECHNOLOGIES, INC. BE LIABLE
>> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> CONSEQUENTIAL
>> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
>> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
>> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
>> STRICT
>> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
>> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
>> + * SUCH DAMAGE.
>> + *
>> + * Author: Stanislav Ocovaj (stanislav.ocovaj imgtec com)
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
>> USA
>> + */
>> +
>> +const int divTable[128] = {
>> + 0x3fffffff,0x3f80fe04,0x3f03f03f,0x3e88cb3d,
>> + 0x3e0f83e1,0x3d980f66,0x3d226358,0x3cae7592,
>> + 0x3c3c3c3c,0x3bcbadc8,0x3b5cc0ed,0x3aef6ca9,
>> + 0x3a83a83b,0x3a196b1f,0x39b0ad12,0x3949660b,
>
>tabs are forbidden in git, we would not be able to push this
Sorry, I will remove them.
Thanks,
Nedeljko
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
