[FFmpeg-devel] [PATCH] HAM6/HAM8 support for IFF demuxer/decoder

Ronald S. Bultje rsbultje
Sun May 9 22:28:46 CEST 2010


On Sun, May 9, 2010 at 3:02 PM, Sebastian Vater
<cdgs.basty at googlemail.com> wrote:
> This is a very bad idea, because the chunk length can be odd if the
> chunk contains only 31 entries (which is perfectly legal in
> IFF-ILBM)...since the data structure contains an uint16_t, this will
> slow down and even crash on any CPU which can't access such data on an
> odd address (like the original 68000, for example).

I don't think this is relevant at all, since FFmpeg doesn't run on 68k anyway.

Try to think in terms of modern archs/compilers/systems/OSes.
Alignment, padding is done all for you. Your task is to make
optimizations easy for the compiler, by not using any arch-dependent
hacks (such as "512-byte alignment", "16-byte alignment", etc.), using
arch-independent types (int, not int32_t), etcetera, unless there is a
specific reason that you can show to make a difference.


More information about the ffmpeg-devel mailing list