[FFmpeg-devel] lavfi state of affairs

[Michael Niedermayer]

kOn Thu, Feb 05, 2009 at 07:55:24PM -0800, Baptiste Coudurier wrote:
> On 2/5/2009 7:15 PM, Michael Niedermayer wrote:
> > 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.
> 
> All this has perfectly its place in avutil.h.
> How can someone know all this ?

i will clarify it, i was unaware that it was so poorly documented / non
obvious


> 
> Besides, a format having a palette should ideally be named PAL* IMHO.

i disagree, the names are systematically choosen and they are clear.
PIX_FMT_PAL8_GRAY is not going to clarify anything and is ugly
compared to PIX_FMT_GRAY16


> 
> >>>> 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'm sad to hear that finally explaining non obvious parts makes you 
> being sick.

what makes me sick is that you talk about bugs in gif.c and utils.c as
if they where bugs in swscale.
it works with imgconvert because it has matching bugs that cancel the
effect of bugs in utils.c
but let us rather fix the issues instead of continuing this discussion


> 
> Problem is that I'm also even more getting sick of it now that I just 
> read that it is even more complicated and _undocumented_ that I thought.

its not complicated, and iam fixing the documentation issues you mention


> 
> I'm now even more relunctant to make libswscale the default with no 
> clear documentation. PIX_FMT_BGR8 must be documented also.

the PIX_FMT system is common to swscale and imgconvert
these kind of comments are just inflamatory, please stop or ill start
flaming too

please stop picking random issues unrelated to
swscale and construct them as anything affecting swscale more than
imgconvert!


[...]

> 
> No wonder why nobody is willing to drop imgconvert...

you are the only devel AFAIR who has an issue with swscale except the
GPL table generator. For the table generator yes there are many who
want it fixed first and iam not ignoring them.

but let us end this pointless bashing please, if you have constructive
comments about swscale they are welcome of course ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- 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/7a5a4711/attachment.pgp>