[FFmpeg-devel] lavfi state of affairs

Baptiste Coudurier baptiste.coudurier
Fri Feb 6 20:45:38 CET 2009 

On 2/6/2009 1:37 AM, Michael Niedermayer wrote:
> 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.

I disagree about what you consider "bugs".

Documentation (avutil.h) was mentioning that PAL8 had a palette and gif
needs one, other formats were not mentioned to have a palette,
libswscale is more complete than imgconvert for sure, so it extended
features.

>> [...]
>>
>> 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!

IMHO issues were not random, now I reckon that I did not fully
understand BGR8/RGB8 because of lack of documentation, this is now
fixed, thanks to your efforts, so in the end I think this is a benefit
for everybody using pix_fmt API and libswscale.

[...]

-- 
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