[FFmpeg-devel] lavfi state of affairs
Baptiste Coudurier
baptiste.coudurier
Fri Feb 6 04:55:24 CET 2009
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 ?
Besides, a format having a palette should ideally be named PAL* IMHO.
>>>> 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.
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.
I'm now even more relunctant to make libswscale the default with no
clear documentation. PIX_FMT_BGR8 must be documented also.
You expect people to guess black magic, and to enhance something you are
almost the only one to understand. This is crazy.
No wonder why nobody is willing to drop imgconvert...
>>>> 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 _only_ deal with interlaced material in broadcast (1080i, NTSC,
PAL).
I repeat: I _barely_ see a difference when going from yuv422p to
yuv420p. DVCPRO 25 in yuv411p is almost acceptable.
[...]
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer http://www.ffmpeg.org
More information about the ffmpeg-devel
mailing list