[FFmpeg-devel] [PATCH 3/4] Implement and use shareable ff_transpose function.

Stefano Sabatini stefano.sabatini-lala
Mon Oct 18 01:31:22 CEST 2010


On date Sunday 2010-10-17 23:54:28 +0200, Michael Niedermayer encoded:
> On Sun, Oct 17, 2010 at 10:22:30PM +0200, Stefano Sabatini wrote:
> > On date Sunday 2010-10-17 21:57:56 +0200, Michael Niedermayer encoded:
> > > On Sun, Oct 17, 2010 at 01:23:36PM +0200, Stefano Sabatini wrote:
> > > > ---
> > > >  libavfilter/Makefile       |    2 +-
> > > >  libavfilter/transpose.c    |  108 ++++++++++++++++++++++++++++++++++++++++++++
> > > >  libavfilter/transpose.h    |   37 +++++++++++++++
> > > >  libavfilter/vf_transpose.c |   88 +++---------------------------------
> > > >  4 files changed, 152 insertions(+), 83 deletions(-)
> > > >  create mode 100644 libavfilter/transpose.c
> > > >  create mode 100644 libavfilter/transpose.h
> > > 
> > > The only use i can see in spliting transpose out is to do SIMD optims and
> > > i dont see how this would fit in this design
> > 
> > See the rotate90 filter which uses ff_transpose.c, that was for
> > avoiding having two filters in the same vf_ file.
> 
> the filters do almost the same though.
> and one filter could support all cases and the other could call that filter
> for nice rotate=deg / transpose user API

I played with the idea of a filter inserting another filter in the
filterchain during init, unfortunately this can't be done during the
init stage since the single filter has no hint regarding the graph
context, and this can't be done during the configuration stage as well
as at that point the query_formats configuration already happened.

So the only way I figured out to use the functionality of another
filter is to simply use its code.

> I dont care strongly if its done with ff_transpose() or one filter calling the
> other but i would like to keep it simple and
> allow SIMD optims to be added because transpose can be done much faster with
> simd. and even with C doing it blockwise might be faster due to cache issues

Anyway please let's try to not stall this patch, optimizations can be
done later anyway.

Regards.
-- 
FFmpeg = Fantastic & Faithless Mere Power Exuberant Gymnast



More information about the ffmpeg-devel mailing list