[FFmpeg-devel] [PATCH] Some ra144.c simplifications
Michael Niedermayer
michaelni
Wed May 21 20:07:25 CEST 2008
On Wed, May 21, 2008 at 06:52:13PM +0200, Vitor Sessak wrote:
> Michael Niedermayer wrote:
>> On Sat, May 17, 2008 at 04:38:51PM +0200, Vitor Sessak wrote:
>>> Michael Niedermayer wrote:
>>>> On Thu, May 15, 2008 at 08:55:35PM +0200, Vitor Sessak wrote:
>>>>> Hi
>>>>>
>>>>> Michael Niedermayer wrote:
>>>>>> On Thu, May 15, 2008 at 09:44:51AM +0200, Vitor Sessak wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> Michael Niedermayer wrote:
>>>>>>>> On Wed, May 14, 2008 at 09:12:07AM +0200, Vitor Sessak wrote:
>>>>>>>>> On Tue, May 13, 2008 at 2:13 PM, Michael Niedermayer
>>>>>>>>> <michaelni at gmx.at> wrote:
>>>>>>>>>> On Tue, May 13, 2008 at 11:05:45AM +0200, Vitor Sessak wrote:
>>>>>>>>>> > Michael Niedermayer wrote:
>>>>>>>>>> >> On Sun, May 11, 2008 at 05:45:29PM +0200, Vitor Sessak wrote:
>>>>>>>>>> >>> Michael Niedermayer wrote:
>>>>>>>>>> >>>> On Sat, May 10, 2008 at 04:50:03PM +0200, Vitor Sessak
>>>>>>>>>> wrote:
>>>>>>>>>> >>>>> Hi,
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>> libavcodec/ra144.c really needs some cleanup. I'll start
>>>>>>>>>> with the
>>>>>>>>>> >>>>> following:
>>>>>>>>>> >>>>>
>>> [...]
>>>
>>>>>>> ra144_uint8_tables.diff.gz: Declare as (u)int8_t tables that fit in
>>>>>>> one
>>>>>>> byte (yes, that makes the indentation of ra144.h inconsistent. I'll
>>>>>>> fix
>>>>>>> the rest of the file later)
>>>>>> ill look at that in a moment
>>>>> New patch attached, only changing _everything_ form hex to decimal.
>>>> ok
>>>>>> [...]
>>>>>>> --- ../ffmpeg.old2/libavcodec/ra144.c 2008-05-14 18:02:44.000000000
>>>>>>> +0200
>>>>>>> +++ libavcodec/ra144.c 2008-05-14 18:24:08.000000000 +0200
>>>>>>> @@ -105,7 +105,7 @@
>>>>>>> static void do_output_subblock(Real144_internal *glob, const
>>>>>>> unsigned short *gsp, unsigned int gval, signed short *output_buffer,
>>>>>>> GetBitContext *gb)
>>>>>>> {
>>>>>>> unsigned short int buffer_a[40];
>>>>>>> - unsigned short int buffer_d[40];
>>>>>>> + unsigned short int *block;
>>>>>>> int e, f, g;
>>>>>>> int a = get_bits(gb, 7);
>>>>>>> int d = get_bits(gb, 8);
>>>>>>> @@ -125,13 +125,13 @@
>>>>>>> else
>>>>>>> g = 0;
>>>>>>> + memmove(glob->buffer_2, glob->buffer_2 + BLOCKSIZE, (BUFFERSIZE
>>>>>>> - BLOCKSIZE) * 2);
>>>>>>> +
>>>>>>> + block = glob->buffer_2 + BUFFERSIZE - BLOCKSIZE;
>>>>>>> - add_wav(glob, d, a, g, e, f, buffer_a, etable1 + b*BLOCKSIZE,
>>>>>>> - etable2 + c*BLOCKSIZE, buffer_d);
>>>>>>> + add_wav(glob, d, a, g, e, f, buffer_a, etable1 + b*BLOCKSIZE,
>>>>>>> + etable2 + c*BLOCKSIZE, block);
>>>>>> ^^^^^
>>>>>>> -
>>>>>>> - memmove(glob->buffer_2, glob->buffer_2 + BLOCKSIZE, (BUFFERSIZE
>>>>>>> - BLOCKSIZE) * 2);
>>>>>>> - memcpy(glob->buffer_2 + BUFFERSIZE - BLOCKSIZE, buffer_d,
>>>>>>> BLOCKSIZE * 2);
>>>>>>>
>>>>>>> - final(glob, gsp, buffer_d, output_buffer, glob->buffer,
>>>>>>> BLOCKSIZE);
>>>>>>> + final(glob, gsp, block, output_buffer, glob->buffer, BLOCKSIZE);
>>>>>> ^^^^^
>>>>>> cosmetics, split!
>>>>> Attached.
>>>> ok
>>>
>>>>> Also,
>>>>> ra144_data_size.diff: Simplify a little ra144_decode_frame().
>>>> ok
>>> Commited a slightly different version to avoid a warning.
>>>
>>> Next batch:
>>>
>>> ra144_more_ctx_trim.diff: Remove two vars from context
>> see below
>>> ra144_gbuf1_half.diff: Only one value out of two of this buffer is used.
>>> Make it half the size
>> ok
>>> ra144_gbuf2.diff: gbuf2[120] -> gbuf2[4][30]
>> ok
>>> ra144_add_wav.diff: Simplify add_wav()
>> ok
>>> ra144_irms.diff: Simplify irms()
>> ok
>> [...]
>
> Everything applied but ra144_gbuf2.diff, which depends on the context
> trimming.
>
>>> @@ -269,13 +266,14 @@
>>> }
>>> static void dec1(Real144_internal *glob, const int *data, const int
>>> *inp,
>>> - int n, int f)
>>> + int n, int f, int l)
>> No single letter variables please, especially not if there are already
>> 2 meaningless ones.
>
> Updated patch attached.
ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- 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/20080521/ada58cb0/attachment.pgp>
More information about the ffmpeg-devel
mailing list