[FFmpeg-cvslog] r25066 - trunk/libavcodec/imgconvert.c

[Reimar Döffinger]

On Tue, Sep 21, 2010 at 04:56:09PM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> 
> > On Tue, Sep 21, 2010 at 03:50:50PM +0100, M?ns Rullg?rd wrote:
> >> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> >> 
> >> > On Tue, Sep 21, 2010 at 03:05:08PM +0100, M?ns Rullg?rd wrote:
> >> >> Stefano Sabatini <stefano.sabatini-lala at poste.it> writes:
> >> >> > and I can barely remember the reason of the gray8=PAL thing.
> >> >> 
> >> >> It seems that if anyone is able to remember or understand this bizarre
> >> >> state of affairs, they are unwilling to explain it to the rest of us.
> >> >
> >> > I did my best, if anyone did not understand it it's beyond my abilities
> >> > to explain.
> >> 
> >> I got lost at the part about how doing a table lookup per pixel would
> >> somehow be easier than not doing it.
> >
> > You have to do it for PAL8 code. Thus it allows the PAL8 code to be used
> > for all formats (e.g. for conversion to BGR32), otherwise you'd have
> > to write a separate conversion function for each format.
> 
> Wouldn't a non-paletted code path be faster when the format doesn't
> actually use a palette?

Most likely yes. Which is one of the (if not actually the) reasons to
even have those pixfmts and not only PAL8. However those formats are
of so little relevance generally that favouring less code over fast
code seems reasonable to me.