[FFmpeg-devel] lavfi state of affairs
Fri Feb 6 01:54:09 CET 2009
On Thu, Feb 05, 2009 at 04:40:50PM -0800, Baptiste Coudurier wrote:
> On 2/5/2009 3:52 PM, Michael Niedermayer wrote:
> > On Thu, Feb 05, 2009 at 03:35:24PM -0800, Baptiste Coudurier wrote:
> >> On 2/5/2009 3:18 PM, Michael Niedermayer wrote:
> > [...]
> >>>> >> [...]
> >>>> >>
> >>>>>> Also libswscale does not support palette output, this makes GIF encoder
> >>>>>> _useless_.
> >>>>> swscale supports 4bit and 8bit palette output with a fixed palette
> >>>> Huh ? PAL8 is not mentioned in isSupportedOut(). Is this a mistake ?
> >>> yes and no
> >>> PAL8 in sws means generic PAL8 with arbitrary palette or maybe optimized
> >>> by sws palette, neither we support.
> >>> fixed palette that imgconvert calls pal8 is bgr8/rgb8 but with a different
> >>> palette than imgconvert (swss is simpler to quantize to)
> >> And here I'm lost, according to avutil.h:
> >> PIX_FMT_PAL8, ///< 8 bit with PIX_FMT_RGB32 palette
> >> and
> >> PIX_FMT_BGR8, ///< packed RGB 3:3:2, 8bpp, (msb)2B 3G 3R(lsb)
> >> Btw, in cpu endianess ? ;)
> > yes, in cpu endianness, little endian and big endian, its 1 byte so all at
> > the same time :)
> >> So what should gif encoder _use_ ?
> > i would say PAL8 + BGR8 + RGB8, in principle PAL8 alone should work too
> > but then some code somewhere has to turn that into BGR8/RGB8.
> > supporting all 3 directly is slightly nicer i think, it would allow the
> > user to choose between PAL8 (custom palette) once this is supported and
> > RGB8 (fixed palette) via -pix_fmt
> Am I confused or we should stop using RGB8 name since it does not
> represent an index to palette ?
RGB8/BGR8 should also set a palette in data (maybe they dont currently
but that can be fixed if you confirm that it is not set ...)
thus RGB8/BGR8 also represent an index into a palette.
> Besides does this mean that gif encoder is right to use PAL8, and
> libswscale is supporting PAL8 but misuse BGR8 ?
i dont understand what you mean
> I have too many things to do than extending gif encoder in the near
> Also one thing I remember now, I have noticed that:
> yuv422p -> yuv420p with imgconvert is by default 50% faster than
> libswscale when not configuring anything:
imgconvert uses nearest neighbor scaling for chroma IIRC so no
surprise here, it should be compared to sws with similar parameters
also if you want fast&crappy yuv422p -> yuv420p theres a trick from mplayer,
chroma linesize*=2, this should be easy to do with lavfi
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Democracy is the form of government in which you can choose your dictator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel