[FFmpeg-devel] [PATCH] AAC Decoder round 3

[Robert Swain]

2008/7/9 Michael Niedermayer <michaelni at gmx.at>:
> On Wed, Jul 09, 2008 at 09:09:39PM +0100, Robert Swain wrote:
>> 2008/7/9 Michael Niedermayer <michaelni at gmx.at>:
>> > On Wed, Jul 09, 2008 at 05:49:24PM +0100, Robert Swain wrote:
>> >> 2008/7/8 Michael Niedermayer <michaelni at gmx.at>:
>> >> > On Tue, Jul 08, 2008 at 01:28:07PM +0100, Robert Swain wrote:
>> >> >> 2008/7/8 Michael Niedermayer <michaelni at gmx.at>:
>> >> >> > On Tue, Jul 08, 2008 at 06:31:36AM +0100, Robert Swain wrote:
>> >> >> >> 2008/7/8 Michael Niedermayer <michaelni at gmx.at>:
>> >> >> >> > On Tue, Jul 08, 2008 at 01:25:52AM +0100, Robert Swain wrote:
>> >> >> [...]
>> >> >> >> >> > and what does the _data postfix say?
>> >> >> >> >> > could you explain what a decode_pulses() would do different?
>> >> >> >> >>
>> >> >> >> >> All the decode_*_data() are parsing functions I believe. They could be
>> >> >> >> >> renamed parse_*() but most are called *_data() in the spec so maybe
>> >> >> >> >> the decode_ could be dropped. What would you prefer?
>> >> >> >> >
>> >> >> >> > I think i prefer decode_pulses() at least untill someone comes up with
>> >> >> >> > a better name
>> >> >> >>
>> >> >> >> OK. Do you want them all renaming?
>> >> >> >
>> >> >> > yes, id like to see _data() disapear.
>> >> >>
>> >> >> OK. I'll do this. Are there any of the other *_tool() to which you
>> >> >> take particular distaste? Do you want all *_tool() renaming as well?
>> >> >
>> >> > i want a grep '_tool()' aac* to fail [except in comments refering to the spec]
>> >>
>> >> The attached patches remove the useless wrapper functions and rename
>> >> some functions and function pointers to what I think should be more
>> >> comprehensible. After their application, there are no more
>> >> decode_*_data or *_tool or *_trans.
>> >>
>> >> I don't think they break anything but I should test files with TNS and
>> >> channel coupling.
>> >
>> > patches probably ok, they are not overly easy to review ...
>>
>> I blame diff for the ugly looking first patch. If I remove the no
>> longer used code in a subsequent patch it looks better. See attached
>> for 0001 from the previous e-mail split into two separate patches.
>
> yes they look nicer now

I'm reasonably sure they won't have broken anything. If they have,
I'll fix it. Applied.

Rob