[FFmpeg-soc] libavfilter review

[Michael Niedermayer]

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)

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- 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/20070818/328a6288/attachment.pgp>