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

Martin Storsjö martin
Thu May 6 17:35:04 CEST 2010


On Wed, 5 May 2010, Sebastian Vater wrote:

> Sebastian Vater a ?crit :
> > Because of backward compatibility I have changed it to append the
> > extradata struct after the palette (because in the original version, the
> > palette data was always at 0).
> >   
> 
> I just changed the minimum size of extradata to 256*3 (768 bytes). This
> will allow the new decoder to detect old libavformat/iff.c which doesn't
> set a large palette.
> 
> The palette data from old demuxer was never larger than 256*3 bytes (8
> bit palette, RGB each).

A few comments on this (not a full review):

Why do you include FF_INPUT_BUFFER_PADDING_SIZE in IFF_EXTRA_CONTEXT_SIZE, 
when you later compare extradata_size to IFF_EXTRA_CONTEXT_SIZE? The 
padding should never be included in extradata_size.

And you _still_ cast extradata pointers into a struct pointer, which 
_still_ relies on the struct layout. Even if all the struct members now 
are 8 bit variables, with a lower risk of getting weird padding/alignment, 
you're still relying on undefined behaviour.

So to put it clearly, never use a struct for reading or writing in 
anything that should have a fixed, well-specified format. You may store 
the parsed-out values in structs, but never memcpy/fread/fwrite or cast 
pointers to structs directly, do the reading of each individual value 
separately using constructs that have a well-defined, portable behaviour.

// Martin



More information about the ffmpeg-devel mailing list