[FFmpeg-devel] [PATCH] libavfilter-soc: add query_formats callback to vf_hflip

Stefano Sabatini stefano.sabatini-lala
Thu Feb 19 00:03:26 CET 2009


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?

> Also, maybe defining a PIX_FMT_PLANAR_RGB32 would 
> avoid converting to YUV and back for such filters (but this would only 
> be useful if the colorspace negotiation is smarter then is ATM and avoid 
> lossy conversions when possible).

Regards.
-- 
FFmpeg = Frenzy and Fast Mortal Pitiful Extreme Geisha




More information about the ffmpeg-devel mailing list