[FFmpeg-devel] lavfi state of affairs

Baptiste Coudurier baptiste.coudurier
Fri Feb 6 01:40:50 CET 2009


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 ?

Besides does this mean that gif encoder is right to use PAL8, and 
libswscale is supporting PAL8 but misuse BGR8 ?

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:

ffmpeg -i <file_422.m2v> -pix_fmt yuv420p <file_420.m2v>

Picture difference is barely noticeable.

I'll try to post more detailed benchmark.

[...]

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