[FFmpeg-devel] [PATCH] IFF: Make lavf/iff.c stop using ff_cmap_read_palette

Martin Storsjö martin
Sun May 9 21:35:48 CEST 2010

On Sun, 9 May 2010, Sebastian Vater wrote:

> Martin Storsj? a ?crit :
> > On Sun, 9 May 2010, Sebastian Vater wrote:
> >
> >   
> >> Martin recommeded to do these as a separate patch.
> >>
> >> It removes call to ff_cmap_read_palette in lavf/iff.c for preparation of
> >> the HAM patch.
> >>     
> >
> > Does an old lavc/iff.c handle a new demuxer behaving in this way, or why 
> > is the change to lavc/iff.c included here? In that case, this can lead to 
> > problems when mixing lavf/lavc versions.
> >   
> Removing ff_cmap_read_palette from lavf/iff.c requires that the decoder
> handles IFF-PBM uncompressed files by itself, since it can't be passed
> to CODEC_ID_RAWVIDEO anymore.
> But that isn't a problem, because old lavf/iff.c doesn't pass the data
> at all to lavc/iff.c in that case.
> However a new lavf/iff.c could pass to old lavc/iff.c in that case it
> won't decode uncompressed IFF-PBM files anymore. It would threat them as
> IFF-ILBM uncompressed and therefore call the decodeplane8 version which
> will result in corrupted image data.
> The only way I see to fix this is to increment the lavc version number
> or to add the new IFF_EXTRA_CONTEXT_SIZE stuff, also. What do you suggest?

Ok, so this is a general problem that you would have got even if you 
didn't split this out as a separate patch, but now it is much much easier 
to spot and discuss, instead of having it mixed up in the middle of 
discussions of fifty other things. See how splitting things into coherent 
pieces aid the review?

A third option would be to make a local copy of ff_cmap_read_palette in 
lavf, so that lavf/iff wouldn't depend on functions from lavc/iff, but 
that's a bit of code duplication, and probably not appreciated.

In this case, if a new version of lavf demuxes stuff to a new "format" 
which earlier lavc doesn't support, I find it acceptable, especially since 
it's a fringe format... If the old lavc still decodes it, but incorrectly, 
that's a problem with the earlier lavc version which is fixed by a newer 
version of lavc.

// Martin

More information about the ffmpeg-devel mailing list