[FFmpeg-devel] [PATCH] libavfilter-soc: add query_formats callback to vf_hflip
Vitor Sessak
vitor1001
Thu Feb 19 18:10:50 CET 2009
Michael Niedermayer wrote:
> On Thu, Feb 19, 2009 at 01:19:22AM +0100, Stefano Sabatini wrote:
>> On date Thursday 2009-02-19 00:20:23 +0100, Michael Niedermayer encoded:
>>> On Thu, Feb 19, 2009 at 12:03:26AM +0100, Stefano Sabatini wrote:
>>>> On date Sunday 2009-02-15 20:58:35 +0100, Vitor Sessak encoded:
>>>>> Stefano Sabatini wrote:
>>>>>> Hi,
>>>>>>
>>>>>> the algorithm implemented in draw_slice() only works with planar
>>>>>> formats, it may be extended and it will but for the moment this patch
>>>>>> fixes filtering for filter chains of the kind:
>>>>>> "format=rgb32, hflip"
>>>>> I think it shouldn't be too hard to extend it, but I'm fine with the patch.
>>>>>
>>>>>> Also what about a function like avfilter_all_planar_colorspaces()?
>>>>>
>>>>> Maybe something like
>>>>>
>>>>> avfilter_colorspaces(int flags);
>>>>>
>>>>> enum flags = {
>>>>> FMT_IS_PLANAR = 1;
>>>>> FMT_IS_YUV = 2;
>>>>> FMT_IS_RGB = 4;
>>>>> FMT_IS_REAL_PIXELS = 8; ///< Not a HW format
>>>>> FMT_IS_BW = 16; ///< Is it useful?
>>>>> }
>>>>> would be more useful?
>>>> I like your idea. Now I see there are many possibly useful macros
>>>> (isPlanarYUV, isYUV, isGray, isGray16, etc.) in swscale_internal.h,
>>>> the alternatives are to move them to lavu, or to duplicate the code in
>>>> lavfi.
>>>>
>>>> My idea was to move the macros to lavu, redefine them something like:
>>>> AV_PIX_FMT_IS_PLANAR_YUV()
>>>> AV_PIX_FMT_IS_YUV()
>>>> AV_PIX_FMT_IS_GRAY()
>>>> ...
>>>>
>>>> and redefine the current libsws macros like:
>>>> #define isPlanarYUV(x) AV_PIX_FMT_IS_PLANAR_YUV(x)
>>>>
>>>> swscale_internal.h already depends on libavutil/avutil.h.
>>>>
>>>> Would be this a acceptable?
>>> first the macros in sws are inefficiently implemented,
>>> an array so that
>>>
>>> AV_PIX_FMT_IS_YUV(x) (array[x]&0x01)
Why using macros at all and not inline functions?
>>> would be a good idea, also see pix_fmt_info
>> Yes, I'm thinking about to move PixFmtInfo to lavu too.
I like this idea. There are a lot of filters that could use data from
PixFmtInfo.
>>> if its well and clean implemenetd lavu is an option also sws should n that
>>> case use lavus variant directly and not use wraper macros
>> First step creates a pix_fmt.h header (PixFmtInfo would then be added
>> to libavutil/pix_fmt.c)
>
> PixFmtInfo as is is too bloated, it requires cleanup _first_
What is bloated/ugly about it? The only thing I see that could be
improved is putting all the FF_COLOR_XXX and FF_PIXEL_XXX in an enum each...
-Vitor
More information about the ffmpeg-devel
mailing list