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

Michael Niedermayer michaelni
Thu Feb 19 18:52:23 CET 2009


On Thu, Feb 19, 2009 at 06:10:50PM +0100, Vitor Sessak wrote:
> 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?

because the call overhead exceeds the amount of code and i dont trust
the compiler


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

12 bytes per pix_fmt for roughly 2 byte of actual information


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090219/472d8701/attachment.pgp>



More information about the ffmpeg-devel mailing list