[FFmpeg-devel] lavfi state of affairs

[Baptiste Coudurier]

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

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

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 !

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

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

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

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org