[FFmpeg-devel] [PATCH 6/6] Add rotate90 filter.

Aurelien Jacobs aurel
Sat Oct 16 14:48:11 CEST 2010


On Fri, Oct 15, 2010 at 08:14:42PM +0200, Stefano Sabatini wrote:
> On date Friday 2010-10-15 17:54:35 +0200, Aurelien Jacobs encoded:
> > On Fri, Oct 15, 2010 at 04:54:57PM +0200, Stefano Sabatini wrote:
> > > On date Friday 2010-10-15 14:36:35 +0200, Aurelien Jacobs encoded:
> > > > On Fri, Oct 15, 2010 at 01:13:59AM +0200, Stefano Sabatini wrote:
> > > > > ---
> > > > >  doc/filters.texi           |    6 ++
> > > > >  libavfilter/Makefile       |    1 +
> > > > >  libavfilter/allfilters.c   |    1 +
> > > > >  libavfilter/vf_transpose.c |  173 ++++++++++++++++++++++++++++++++++++++++++++
> > > > >  4 files changed, 181 insertions(+), 0 deletions(-)
> > > > 
> > > > What about moving this code to its own vf_rotate90.c file (and move
> > > > shared code in a shared file) ?
> > > 
> > > Slightly against this, since it requires more complexity (internal
> > > function declarations) with no gain,
> > 
> > I feel that it is your current patch which require more complexity
> > (ifdefery) with no gain. (yes that's a loose argument...)
> > 
> > > also the invert() and transpose()
> > > functions require the same formats, and I cannot see a safe way to
> > > expose the query_formats() function.
> > 
> > Huh ? What's the problem with a ff_transpose_query_formats() in a common
> > transpose.c file used by both filters ?
> > 
> > My point is that we are currently splitting muxers and demuxers which
> > were written as a single file long ago, and I would like to avoid having
> > to do the same with libavfilter in a few years...
> > For now, as long as you only merge 2 filters, it's not much of a
> > problem. But if you start like this, we will end up with intermingled
> > mess of ifdef, many filters in the same files, loosely defined
> > dependencies, code which is always compiled even if it's not used,
> > etc...
> > 
> > I can't imagine why it would be more problematic to properly split
> > filters, than to properly split (de)muxers.
> 
> Well if you think that would simplify the build system feel free to
> suggest how to do. We could have a transpose.c and transpose.h
> internal header with the common functions shared by vf_transpose.c and
> vf_rotate90.c

That's exactly what I had in mind.

> Anyway let's wait for the transpose filter to be applied before.

OK.

Aurel



More information about the ffmpeg-devel mailing list