[FFmpeg-devel] lavfi state of affairs
Fri Feb 6 02:26:33 CET 2009
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
>>>> 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
>>>> PIX_FMT_BGR8, ///< packed RGB 3:3:2, 8bpp, (msb)2B 3G
>>>> 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 (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
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
More information about the ffmpeg-devel