[FFmpeg-soc] libavfilter review

[Michael Niedermayer]

Hi

On Sun, Aug 19, 2007 at 12:36:15PM -0400, Bobby Bingham wrote:
> 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...

ive thought about cs negotiation a little and ive come up with the following
possible solution

each filter link has 2 IDs (integers or  pointers or something)
one corresponding to the input into the link and one corresponding to the
output (alternatively we could have always 2 links with a dummy filter
between)

now if 2 IDs anywhere within the filter graph are equal that means that
the colorspace must be equal and each ID has a list of valid colorspaces

now to solve it you just merge the 2 IDs on each link
if both the corresponding lists have a common colorspace then merge is
possible if not conversation is needed

example: 
the case from above:
> > > > 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

src b-->c filter c-->d dst

b={A,C}
c={A,B,C}
d={B,C}

first we merger b and c leading to

src b-->b filter b-->d dst

b={A,C}
d={B,C}

and next: b and d

src b-->b filter b-->b dst

b={C}

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- 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-soc/attachments/20070829/9c3cb521/attachment.pgp>