[FFmpeg-devel] lavfi state of affairs

Fri Feb 6 04:15:26 CET 2009

On Thu, Feb 05, 2009 at 05:26:33PM -0800, Baptiste Coudurier wrote:
> On 2/5/2009 4:54 PM, Michael Niedermayer wrote:
> > 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[1] (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.
> 
> WTF But according to avutil.h documentation, BGR8 does not mean an index 
> to a palette .......

the docs dont say that there is a palette for BGR8 but they also dont say
that there is no palette ...

the docs dont say that the 8bit values are an index into a palette, but
if there where a palette they could be an index into it.

You can see BGR8 as a 3bit red +3bit green +2bit blue truecolor format
or a 8bit paletted format, it is both.

> 
> >> 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
> 
> You said that libswscale supports PAL8 however it isSupportedOut does
> not accept PIX_FMT_PAL8.
> 
> Can we refer in terms of PIX_FMT_* please ?
> 
> I don't understand anything of what you explain, yet Im dev, how can you
> expect a user to understand ?

There is a 8 bit paletted format (PIX_FMT_PAL8) it can have an arbitrary
palette.
There is a 8 bit paletted format (PIX_FMT_BGR8) that has a single systematic
884 palette.
There is a 8 bit paletted format (PIX_FMT_XXX) that has a single systematic
666 palette.

imgconvert supports outputting PIX_FMT_XXX (while using the enum value of
    PIX_FMT_PAL8 for it incorrectly due to lack of a PIX_FMT_XXX)
swscale supports outputting PIX_FMT_BGR8
neither support arbitrary palettes nor the others systematic palette
if they support PIX_FMT_PAL8 is a matter of philosophy
you could say both do because each support a systematic paletted 8bit format
or you could say neither does because neither supports an arbitrary palette

> 
> Libav* user looks and see: "OH gif uses PAL8", then he setups libswscale
> and libswscale chokes saying PAL8 unsupported. What does he do ? He will
> use imgconvert !

iam not going to fix imgconvert which would mean
make it reject PAL8
add a RGB666 and make it accept that instead
and then add RGB666, PAL8, BGR8 and RGB8 to gif

i will simply ignore imgconvert and fix gif+swscale
i hope this will end this discussion because honestly iam sick of it.

> 
> >> I have too many things to do than extending gif encoder in the
> >> near future...
> >>
> >> 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
> 
> Nice, what would be the parameters ? Should I look at where params are
> defined in the source code ?

all the relevant params are listed in libswscale/swscale_avoption.c

> 
> > also if you want fast&crappy yuv422p ->  yuv420p theres a trick from
> > mplayer, chroma linesize*=2, this should be easy to do with lavfi
> 
> Well with neigbor scaling, I _barely_ see any difference of what you 
> call. I won't ever consider loosing 50% performance for something I 
> barely see.

thats fine, but there are people who do care and there is video material
(all interlaced material) on which its rather noticeable but then imgconvert
doesnt handle interlaced material correctly anyway when it comes to
convertion between chroma subsamplings. mplayer with swscale and manually
set options handles interlaced material correctly but we are still a little
away from that (lavfi is needed here first ...)

> 
> Well I'd like to acheive same performance with libswscale even if this 
> implies _same_ quality than imgconvert, otherwise I loose a feature.

you can tune the options as you like with swscale, if you are unable to
achive the same performance with that you can submit a full bugreport and
ill look into it.
Iam not going to exhautively test all modes of swscale and imgconvert to
see if out of 1000 that are faster there is one that is not.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090206/cbfc1493/attachment.pgp>