[FFmpeg-devel] [PATCH] WMA Voice decoder

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> On Wed, Feb 10, 2010 at 10:25:58PM -0500, Ronald S. Bultje wrote:
>> Hi,
>> 
>> On Mon, Feb 1, 2010 at 2:35 PM, Reimar D?ffinger
>> <Reimar.Doeffinger at gmx.de> wrote:
>> > On Sun, Jan 31, 2010 at 09:46:43PM -0500, Ronald S. Bultje wrote:
>> >> On Sat, Jan 30, 2010 at 6:48 PM, Reimar D?ffinger
>> >> <Reimar.Doeffinger at gmx.de> wrote:
>> >> > "short"? Also specifying the type only once is ugly.
>> >> > Also if you use frame_size with a shift they all can be uint8_t
>> >> > (though probably it's better to just "waste" those 34 bytes and
>> >> > leave frame_size 16 bits, but the others don't need to be.
>> >>
>> >> OK, so I changed this to be holdable in 32bits per frame type, maybe
>> >> that's a bit too much just let me know how far I should go.
>> >
>> > I'm generally in favour of the most readable, at least as long as we
>> > are talking about saving a few _bytes_, if it was a kB that'd be different.
>> 
>> As we discussed, this is nearing bikeshed-status. It's not
>> performance-relevant and small codec binary size would therefore be
>> worthy, so I'll leave it as is.
>
> did someone say bikeshed? :)
> anyway, when comparing bit vs 4byte dont forget that gcc might need
> 20+ bytes of code to access this bit so depending on how many of these
> bits are there it may or may not be smaller

There's rarely any reason for using less than 8 bits for a single
value.  Exceptions are when there are very many of them so the space
savings become really relevant and/or they can be efficiently accessed
using bit manipulations.  Bitfields are always out of the question.

-- 
M?ns Rullg?rd
mans at mansr.com