[FFmpeg-soc] libavfilter review

[Bobby Bingham]

On Sat, 18 Aug 2007 19:22:38 +0200
Michael Niedermayer <michaelni at gmx.at> wrote:

> Hi
> 
> On Sat, Aug 18, 2007 at 12:12:08PM -0400, Bobby Bingham wrote:
> > On Fri, 17 Aug 2007 21:10:15 +0200
> > Michael Niedermayer <michaelni at gmx.at> wrote:
> > 
> > > the query_formats system is very flexible, it takes a AVFilterLink
> > > so a filter could have a fixed list of supported input pix_fmts
> > > and make the output query_formats depend on the input pix_fmt or
> > > the other was around well i dont think the other way around would
> > > work but how should the user know that?
> > > and whats the sense of this overly flexible system if it doesnt
> > > work with anything but the obvious simple supported output
> > > pix_fmt depends upon input formats, it would be alot clearer if
> > > query_formats would take a list/array of input pix_fmts as
> > > argument (or a array or pix_fmt, flags pairs) where the flags
> > > could indicate if the pix_fmt can be provided without colorspace
> > > conversation, but maybe thats not really usefull and a simpler
> > > prefer first possible format in the list system would work
> > > equally well
> > > 
> > > 
> > > also what happens in the following case:
> > > src -> filter -> destination
> > > 
> > > src supports formats A and C
> > > destination supports formats B anc C
> > > and the filter supports A,B,C inputs and output=input
> > > 
> > > if i understood the code correctly this would fail
> > > 
> > 
> > I think I've got an idea which will be less absurdly flexible, and
> > will support graphs like your example without requiring
> > conversion.  The only thing is that I might need to set the
> > restriction that all the inputs of a filter must always be
> > operating on the same colorspace, and similar for outputs.
> > 
> > This of course doesn't affect all those filters with only simple
> > inputs and outputs.  And I expect most filter authors would only
> > support this case anyway.  But before I start coding it, I want to
> > check if such a restriction would be acceptable.
> 
> its probably ok (i cant think of a case where a filter would want 2
> inputs with differing colorspace)
> 

Unfortunately, I thought of a case.  The filtergraph filter, being
simply a composite of various subfilters, may legitimately have inputs
with multiple colorspaces.  And doing so may optimize the number of
conversions.

I'm afraid the more I look at the problem, the more I realize it's not
something I can come up with a good solution to by Monday.  I think
I'll add support for autoconversion to the current system so that it at
least works in all cases, and I'll have to work on a better system
after the end of summer of code, because there are enough other areas I
can actually make improvements on before the deadline if I don't get
hung up on this one thing.

Of course, I'm open to any ideas anybody has regarding a solution to
colorspace negotiation...

-- 
Bobby Bingham
Never trust atoms.  Or anything made of atoms.
このメールは再利用されたバイトでできている。