Am 19.07.16 um 15:42 schrieb Umair Khan:
> On Tue, Jul 19, 2016 at 5:20 PM, Thilo Borgmann <thilo.borgm...@mail.de>
> wrote:
>> Am 19.07.16 um 09:22 schrieb Umair Khan:
>>> On Tue, Jul 19, 2016 at 12:29 PM, Paul B Mahol <one...@gmail.com> wrote:
>>>>
>>>> On 7/19/16, Umair Khan <omerj...@gmail.com> wrote:
>>>>> On Tue, Jul 19, 2016 at 3:08 AM, Michael Niedermayer
>>>>> <mich...@niedermayer.cc> wrote:
>>>>>> On Mon, Jul 18, 2016 at 11:42:48PM +0530, Umair Khan wrote:
>>>>>>> On Sun, Jul 17, 2016 at 3:38 PM, Michael Niedermayer
>>>>>>> <mich...@niedermayer.cc> wrote:
>>>>>>>> On Sun, Jul 17, 2016 at 11:54:49AM +0200, Michael Niedermayer wrote:
>>>>>>>>> On Sun, Jul 17, 2016 at 09:00:48AM +0530, Umair Khan wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> On Sun, Jul 17, 2016 at 12:25 AM, Thilo Borgmann
>>>>>>>>>> <thilo.borgm...@mail.de> wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>> From 70e65b26cc3f84c9c664c30808b43a5e1cf16eaa Mon Sep 17 00:00:00
>>>>>>>>>>>> 2001
>>>>>>>>>>>> From: Umair Khan <omerj...@gmail.com>
>>>>>>>>>>>> Date: Sat, 16 Jul 2016 23:52:39 +0530
>>>>>>>>>>>> Subject: [PATCH 1/1] avcodec/alsdec: implement floating point
>>>>>>>>>>>> decoding
>>>>>>>>>>>>
>>>>>>>>>>>> It conforms to RM22 version of the reference codec.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Umair Khan <omerj...@gmail.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>> libavcodec/Makefile | 2 +-
>>>>>>>>>>>> libavcodec/alsdec.c | 284
>>>>>>>>>>>> +++++++++++++++++++++++++++++++++++++++++-
>>>>>>>>>>>> libavcodec/mlz.c | 171 +++++++++++++++++++++++++
>>>>>>>>>>>> libavcodec/mlz.h | 69 ++++++++++
>>>>>>>>>>>> libavutil/softfloat_ieee754.h | 115 +++++++++++++++++
>>>>>>>>>>>> 5 files changed, 638 insertions(+), 3 deletions(-)
>>>>>>>>>>>> create mode 100644 libavcodec/mlz.c
>>>>>>>>>>>> create mode 100644 libavcodec/mlz.h
>>>>>>>>>>>> create mode 100644 libavutil/softfloat_ieee754.h
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>>>>>>>>>>>> index abef19e..a03adf5 100644
>>>>>>>>>>>> --- a/libavcodec/Makefile
>>>>>>>>>>>> +++ b/libavcodec/Makefile
>>>>>>>>>>>> @@ -163,7 +163,7 @@ OBJS-$(CONFIG_ALAC_DECODER) +=
>>>>>>>>>>>> alac.o alac_data.o alacdsp.o
>>>>>>>>>>>> OBJS-$(CONFIG_ALAC_ENCODER) += alacenc.o alac_data.o
>>>>>>>>>>>> OBJS-$(CONFIG_ALIAS_PIX_DECODER) += aliaspixdec.o
>>>>>>>>>>>> OBJS-$(CONFIG_ALIAS_PIX_ENCODER) += aliaspixenc.o
>>>>>>>>>>>> -OBJS-$(CONFIG_ALS_DECODER) += alsdec.o bgmc.o
>>>>>>>>>>>> mpeg4audio.o
>>>>>>>>>>>> +OBJS-$(CONFIG_ALS_DECODER) += alsdec.o bgmc.o mlz.o
>>>>>>>>>>>> mpeg4audio.o
>>>>>>>>>>>> OBJS-$(CONFIG_AMRNB_DECODER) += amrnbdec.o
>>>>>>>>>>>> celp_filters.o \
>>>>>>>>>>>> celp_math.o
>>>>>>>>>>>> acelp_filters.o \
>>>>>>>>>>>> acelp_vectors.o
>>>>>>>>>>>> \
>>>>>>>>>>>> diff --git a/libavcodec/alsdec.c b/libavcodec/alsdec.c
>>>>>>>>>>>> index a7e58a2..c710fc3 100644
>>>>>>>>>>>> --- a/libavcodec/alsdec.c
>>>>>>>>>>>> +++ b/libavcodec/alsdec.c
>>>>>>>>>>>> @@ -35,8 +35,11 @@
>>>>>>>>>>>> [...]
>>>>>>>>>>>>
>>>>>>>>>>>> +/** multiply two softfloats and handle the rounding off
>>>>>>>>>>>> + */
>>>>>>>>>>>> +static SoftFloat_IEEE754 multiply(SoftFloat_IEEE754 a,
>>>>>>>>>>>> SoftFloat_IEEE754 b) {
>>>>>>>>>>>> [...]
>>>>>>>>>>>
>>>>>>>>>>> Why is this in alsdec.c?
>>>>>>>>>>
>>>>>>>>>> This is not the actual IEEE 754 multiplication. It is as is
>>>>>>>>>> mentioned
>>>>>>>>>> in the reference spec.
>>>>>>>>>> The typical one for 754 floats, I've implemented here separately -
>>>>>>>>>> https://github.com/omerjerk/FFmpeg/commit/d6cd4bf66b9da46dd87580d7d974ce44abdcfba2#diff-4dd4b2d8d523f336fbefa96e9252187cR93
>>>>>>>>>>
>>>>>>>>>>> [...]
>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/libavcodec/mlz.c b/libavcodec/mlz.c
>>>>>>>>>>>> new file mode 100644
>>>>>>>>>>>> index 0000000..cb2ed6a
>>>>>>>>>>>> --- /dev/null
>>>>>>>>>>>> +++ b/libavcodec/mlz.c
>>>>>>>>>>>> [...]
>>>>>>>>>>>
>>>>>>>>>>>> +static int input_code(GetBitContext* gb, int len) {
>>>>>>>>>>>> + int tmp_code = 0;
>>>>>>>>>>>> + int i;
>>>>>>>>>>>> + for (i = 0; i < len; ++i) {
>>>>>>>>>>>> + tmp_code += get_bits1(gb) << i;
>> |=
>> should be better.
>>
>>>>>>>>>>>> + }
>>>>>>>>>>>> + return tmp_code;
>>>>>>>>>>>> +}
>>
>> Also, you could revert it byte-wise using ff_revert[]... if len is often
>> bigger
>> than 8 that might be worth it.
>
> I didn't get you.
tmp_code |= get_bits1(gb) << i;
> I tried logging that variable and len is always greater than 8. So
> what should we go with?
> It was 9 or 10 for the file I ran. And going with the logic of lzw, it
> will hardly be greater than 11 ever.
I think it would not benefit enough from ff_reverse then. Keep the loop.
-Thilo
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
